Describing Handwriting, Part III: Hands and Graphs

Part I of this series focussed entirely on representing scripts, that is, the ideal in the scribe's mind. Part II introduced the idea of the idiograph and hinted at some issues not properly addressed in Part I, revealing (for instance) some problems with the proposed system for associating features with letters. In this post, that discussion is taken up and elaborated in more detail, refining the model proposed in Part I along the way.

Descriptions and Features (Again)

One point that was glossed over briefly in Part I was how to associate particular features with a scribal hand (or, even, a script). To do this in our model, I now think that we need to introduce a new entity, the FEATURE, which can be connected to allographs, idiographs, graphs and components via a relationship. We can then have things like the following:

  • ALLOGRAPH.Insular_h SHOWS_FEATURE FEATURE.Wedged_ascender

Note that this is not entirely consistent with the relationship names given in Part I. On the one hand it could be brought over, although they may be too proscriptive. Must an Insular h have a wedged ascender? In theory yes, but if not then does it suddenly become 'not Insular'? What does that mean, anyway? Perhaps NORMALLY_HAS is better, in which case we might as well use SHOWS.

This is a relatively minor question. More significant is a set of difficulties which arise when we want to identify aspects of style.


In principle, elements of style can be identified using this system by searches for particular descriptive elements. For example, if a scribe writes with a very angular script then 'angular' as a descriptive element would reflect this, and so we could search for 'angular' to find similar scribal hands. On the one hand this makes sense: the 'angular hook' of low s would normally be the same as Insular f, for example, and (potentially) the hook of e. However, this does not always hold. Consider flat-topped (i.e. Square) a, the top of which is very different from flat-topped g: for a, the top is part of the body of the letter, (often) round and more or less circular. For Insular g, though, the top is constructed like and functions like that of t, namely an approximately horizontal line.

To capture this, we want to be able to associate features at the level of several graphemes, and perhaps also at the level of the scribal hand and have this inherited by all specialisations of those forms (to use Object Oriented language) – although we must also be able to override this for any particular instance. [Edit, 17 October 2011: I now realise that the use of 'grapheme' is incorrect in this context and prefer 'character'. See the discussion under 'Terminology (again)' in Part IV of this series.] Thus a scribal hand could be associated with the feature 'angular', and this would be inherited by all idiographs and graphs of that scribe by default unless it were specified otherwise. Similarly, components could be associated by default: wedged minims and wedged ascenders would be an obvious one. Other sets of graphemes and allo/idiographs could then be built up with associated elements. Note, by the way, that only certain features are relevant to certain levels: flat tops are relevant to idiographs and graphs but not allographs or indeed to scribal hands, although that's arguable. Pen angle, on the other hand, applies certainly to scribal hands and can be inherited by idiographs and graphs. Wedges would apply to allograph level, and potentially to script and/or scribal hand. There's a lot to be worked out here still!

To take an example (and push this further), the top stroke of g and top stroke of t could be grouped as a set and both associated with FEATURE.wavy, for example. Here, however, an argument could be made for just one COMPONENT, top_stroke, which is associated both with GRAPHEME.g and GRAPHEME.t, but then it would be impossible to record a scribe whose idiographs included flat-topped t but wavy-topped g (for example). Better, then, to have COMPONENT.top_stroke_t and COMPONENT.top_stroke_g, both of which inherit from a super entity, COMPONENT.top_stroke, thereby allowing either possibility. A default could then be set for both forms, and either overridden in any given instance. This could then be expressed as follows at the script level:

  • ALLOGRAPH.Insular_t MUST_HAVE COMPONENT.top_stroke_g
  • ALLOGRAPH.Insular_g MUST_HAVE COMPONENT.top_stroke_t
  • And, perhaps also, SCRIPT.Insular HAS (ALLOGRAPH.Insular_g, ALLOGRAPH.Insular_t ...)

And therefore, to describe a scribal hand or graph:

  • HAND.G259-1 WROTE GRAPH.G259-1_g_#267

All of which is a very long-winded way of saying that a given scribal hand normally shows Insular g and t both with a flat top-stroke, but (at least) once wrote Insular g with a wavy top. The attentive reader will also notice some new entities and relationships which have quietly been slipped in here as well!

If a feature is specified by 'default' at this level then how should its absence be recorded at some level below it? For example, as we had above, if the allograph 'Insular t' normally has a flat top, then how do we record an idiograph or graph with a wavy top? One possibility is by specifying an EXCLUDEd feature, as suggested in Part I. If our model tells us that a flat top on t EXCLUDEs a wavy top for any given example, then simply adding 'wavy top' to a given graph as we did above should be sufficient to show that it does not have a flat top. But should it also be possible to specify the absence of a feature? Perhaps for a graph, yes, but I'm not sure about an idiograph, as this could be taken to mean that no graph anywhere in that scribe's repertoire shows the feature in question – an assertion I'd rarely be prepared to make. Perhaps that's not the case, though: if an idiograph is what the scribe habitually writes, then that's not to say that there aren't ever exceptions. I'm open to discussion.

One further point: it needs to be possible to record EXCLUDEd features at the level of scribal hands. A scribe can certainly write with both wedged and tapering ascenders – not on the same letter, of course, but in general yes.

This is beginning to become quite jumbled, but a structured model is beginning to appear. I will follow up with a fuller example in the next instalment both to illustrate the principles and to see how well they hold up in practice. First, though, we need a recapitulation and formal summary, and this can now be found in Part IV.


Posts by Date

Posts by Author


RSS / Atom