"Glyph space" – I like it.

Ironically, I read Cyrus' post on glyph space almost immediately after sending a lengthy email to Frank Blokland on the subject of new approaches to spacing. While I think Cyrus is right that the attachment of spacing to glyphs was one of the characteristic distinctions between typography and writing, I don't think there is any reason at all why it needs to remain such. Glyph space was a necessary by-product of putting letters on little piece of metal. It seems increasingly bizarre to me that digital font spacing still follows a metal type paradigm and, hence, a two-stage spacing mechanism (advanced width default spacing followed by kerning adjustment).

I like the term. But I would really like to know about John’s ideas for new spacing paradigms!

One way to describe what I'm thinking about would be as a redefinition of glyph space. In some respects, one could say that the traditional typographic glyph space, whose paradigm is a piece of metal, isn't really glyph space at all, because it is independent of and ignorant of the shape of the glyph. It's a rectangle that butts up against other rectangles, and that may or may not result in an ideal spacing relationship between the glyph shapes that are carried on the rectangles. What if, instead of putting glyphs on rectangles, we put them on shapes that reflected the glyph shapes in such a way that when those shapes butted up against each other they resulted in ideal spacing for those glyphs?

This ‘bubble’ idea is something that Laurence Penney and I discussed way back in the mists of time on the comp.fonts newsgroup (c. 1995). It is also, as I understand it, one aspect of the spacing in Tom Milo's Arabic layout model, which really does dispense with metal type paradigms. Microsoft's math layout uses a related concept with its ‘cut-in’ kerning, which is necessary because adjacent glyphs in math layout may have different scaling and vertical alignment, making traditional kerning impossible.

Having looked at lots of different spacing models over the past fifteen years, this is the one I keep coming back to. The practical difficulty in terms of font development is the creation of the bubbles. If done manually, this is like a secondary kind of outline editing: you define the visible glyph and then the invisible bubble. But it should be automatable, i.e. it should be possible, by defining tolerances, to extrapolate the bubble from the glyph shape. The tricky aspect is that the bubble outline can't just sit at a fixed distance from the glyph outline because, obviously, in the case of a letter like T the bubble needs to be further from the vertical stem than it is from the ends of the crossbar.

To me, the concept of advance width is just archaic. We could change "kerning classes" to "spacing shape classes" and tidy up the whole mess.

The bubble system would certainly make life easier, and even if I had to shape the bubbles manually—which I would prefer anyway—it would be better than kerning.

James, in theory bubble spacing could be implemented in a font design tool such as FontLab and then translated to the most efficient combination of sidebearings and kerning data during font generation. Ideally, of course, I'd like to see the bubble spacing implemented within the font and layout format itself, but such a design tool implementation would be a good proof of concept.

I will probably post a new topic when I get around to formulating my thoughts on this one of these days, but I think there are a lot of things we can rethink about font formats that are relics of pre-digital Latin typography, from the "glyph" as the most basic unit of design onwards. I don't know how long it will be in the future, but I hope the font format that will eventually replace OpenType will dispense with these restrictions, including the notion of fixed side-bearings.

Ideally, I would like to see a font format powerful enough to handle something like Tom Milo's Arabic layout model internally. We can take a look at the demands of so-called complex scripts like Arabic, which are tricky to handle in the current formats because we are stuck in the paradigm of pieces of metal, and create the next-generation format to handle them in simpler, more logical ways. Working with a generalized notion of spacing, perhaps something like the bubble method described by others, could be a feature of this dream format.

And here I thought that "glyph space" was something that g and q were close to each other in (and G and 6 as well).

Compugraphic had an interesting spacing system that I remember seeing back in the mid-eighties on some of their advanced typesetting systems. Instead of normal spacing + kerning pairs, they divided the glyph into several zones--upper, middle, lower--I don't remember exactly. Each zone was basically like having different sidebearings going from top to bottom. So, the A would have a narrow zone at the top and a wider one at the bottom. The T would have a wide zone at the top and a narrow one at the bottom. Spacing would be determined by matching up the zones for adjacent characters. It's not unlike the way they used to cut notches into metal and wood type to facilitate tighter spacing for the AT combination, for example.

Anyway, I've played around with this idea and I don't think it would be hard to implement.

Oh so obvious and oh so boring. Didn't any of you ever set metal type?

What's obvious and boring?

Mark, the Compugraphic system is what I call unitised banded spacing. It was also discussed on the comp.fonts newsgroup when Laurence raised the idea of bubble spacing, and I made a test case to demonstrate its limitations. Essentially, it involves setting different sidebearings at different heights. Because it is unitised, though, it is not flexible enough for ideal spacing. Unitisation is another limitation of mechanical systems that need not apply to digital type. The MS math cut-in kerning is similar to the banded spacing idea, except the number and height of the bands is defined relative to the UPM by the font maker, so it is a lot more flexible. But a true bubble model, in which spacing is directly related to glyph shape seems to me greatly preferable.
____

James, yes I have set metal type. There was no kerning, and I wasn't allowed to take a file to the precious bits of metal.

"Didn't any of you ever set metal type?"

Yes, but Toto, we are not in Kansas any more.

Some time ago I was thinking that one can use different kind of shapes to space things. The sidebearings model in that model is like putting 'rectangles' between the 'letters' (in the image below, the left column), and you need to modify the with of these rectangles to have an even spacing. But you can also use circles, and in that case using the same* circle you automatically get difference between spacing (right side of the image below).

*but you have to find the 'right' circle and the 'right' position.

John: '[...] after sending a lengthy email to Frank Blokland on the subject of new approaches to spacing [...]'
 
And, of course, John received a lengthy e-mail in return, which I partly recycle below. John and I discussed different approaches on spacing and he actually questioned mine for Latin script-representations, which is based on the systems and models I am developing as part of my attempt to come to a Treatise on the Harmonic Systems in the Latin script (PhD research at Leiden University with Gerard Unger as promotor). So far, this research for instance resulted in some preliminary versions of DTL LetterModeller. See also: http://www.typophile.com/node/48736
 
The thesis on which my research is based, is that one can only judge the different representations of characters within scripts on the rules defined by the (historical) bases of these representations themselves. A description of the underlying structures is essential to describe variants of the specific characteristics of style periods and for instance to map what type designers actually add and/or alter to the basic structures (idiom). A consequence of this approach is, that a certain script-representation related mechanism, like spacing –which is the subject of this topic– is not by definition automatically applicable to a representation of another script. In most cases it won’t, because the underlying structure is incomparable.
 
The LetterModeller is only focused on Latin and the current version is restricted to the Harmonic System which is traditionally named ‘Roman’ in the typographic field and ‘Textletter’ in the calligraphic world. The spacing mechanism I am working on is based on what I call the Rhythmic System. Basically this places ([variants of] a repetition of) a Harmonic System underneath the related characters to come to a spacing based on the rhythm within the letters (as for instance shows up in the stem interval). Although merely a simplification, one could state that in essence the round parts are treated as overshoots of the straights. However, to measure the distance between the letters mostly based on the straight strokes is only possible when the proportions are ‘ideal’, i.e., when (the widths of) all characters are based on the same underlying Proportional System. As soon as this is not the case, i.e., when multiple underlying Proportional Systems are used, the matter becomes more complex. This shows up for instance in the spacing of typefaces with relatively large deviations in counter sizes, which normally results in a ‘tight’ spacing to cover up the rhythmic irregularities (to glue the letters actually).
The Rhythmic System approach as basis for spacing works for ‘open’ letters also. In one of the PDF’s which are part of the LeMo download (http://www.fontmaster.nl/english/download.html), there are examples which contain an ‘a’ and an ‘e’. The idea of ‘open’ letters is in my opinion directly related to typography, i.e., to the side bearings which are the result of transition of a calligraphic system into movable type. A calligrapher will write for instance an ‘a’ or an ‘e’ in the rhythm of the other letters, without bothering where exactly the space within the letter stops or starts. To be able to split up the space in equal parts, one has to know the latter.
 
At the moment I am measuring the Proportional Systems of letters from the Renaissance (especially Jenson and Griffo) and of later periods, to map the different characteristics in proportions in the letters of the different style periods in general and of punch cutters specifically. If everything goes well, next month the development of the ‘LetterMeasurer’ application will start. The purpose of this app is to map the Proportional Systems automatically of (firstly digitized/auto traced) type designs and to generate a database of (style period and punch cutter related) values. It is especially interesting to see that Griffo makes the counters of the ‘round’ letters ‘b’, ‘d’, ‘p’ and ‘q’ somewhat smaller than Jenson, which could be interpreted as a starting point for the rotating counter axis, as can be found in typefaces from the Baroque (Griffo’s model being the most dominant over time). Of course, this affects also the ‘c’, ‘e’ and ‘o’.
Condensing the ‘round’ letters provides a way to make a typeface more economic. Jan van Krimpen applied this idea clearly to Spectrum, which was originally developed as a bible face. Transferring this to the current technology, one could imagine that for instance adding an alternative (stylistic) set for the ‘round’ letters to a typeface, would give the typographer some more options to control the space. A (more futuristic) step further would be the application of a model which could be tailored to a typeform on the fly and which the typographer could use to change the parameters of certain letters within a typeface. I am not referring to multiple masters here, but thinking of a typeface independent mechanism.
At the moment I am making attempts to automatically ‘tailor’ and ‘anchor’ the primary Harmonic Model in the current version of LeMo to existing regular weights of broad nib based typefaces to generate bold and condensed versions from there. Perhaps this turns out to be too abstract at the end, but wouldn’t it be nice to provide the typographer with the flexibility of the calligrapher?
 
The basic principle of an equally devided space between all letters is the result of the transition of a from origin calligraphic system to a typographic mechanism. Over the last 23 years as a lecturer at the Royal Academy I have been in the position to experiment with different approaches in educating rhythm and spacing. One of the things I noticed, is that explaining the fact, that the space between the letters should be equal to the space within the letters does not help students very much when they start writing with a broad nib. One needs to provide a mechanism which forces the students in this rhythm, and in case of the ‘Textletters’ the rhythm/spacing can be largely controlled by the length of the stroke-endings. i.e., feed. This convinced me also of the fact that the length of serifs is not an arbitrary thing, but a letter-width related factor (besides being a representation/indicator of the contrast, contrast sort and contrast flow). In other words, by defining the stem interval within the letters the lengths of the serifs are a natural result of this, because the stem interval between the letters is normally supposed to be (almost) equal. Short serifs will cover less space and will result in a tighter spacing, which is basically an obstruction of the rhythm –something which in my opinion makes for instance sans serifs by definition more irregular.
 
The spacing of the ‘diagonal’ letters is another thing. These letters have clearly another origin (capitals) than the round letters and are therefore part of a different Harmonic Model. We like to see the script-representations as consistent things (‘construction sorts’ [Noordzij]), but in many cases they are not. A calligrapher will tweak and bend these letters to make them fit in a ‘Textletter’ variant such as the Humanistic minuscule. In practice the type designer will make the width and weight/contrast/contrast flow characteristics of the ‘diagonal’ letters as equal as possible to the ‘round’ letters. The spacing in these cases is normally as tight as possible, even sometimes by reducing the length of the serifs. By definition kerning has to be applied to makes things as optimal as possible, something calligraphers will do automatically.
The fact that the ‘diagonal’ letters are relatively poorly represented in the current version of LeMo, does not automatically imply that spacing mechanisms coming from the dominant (primary) Harmonic Model can not be applied on the secondary Harmonic Model.
 
Even if spacing is script-representation specific, then one needs at the end a common way to describe the spacing of different script-representations in a font format still, I reckon. The translation of the spacing into distances between the optical (center/heart) lines of the letters, is at the moment the best method I can think of, if only because it can be used to translate the current side bearings system easily (the optical center line being the center between the side bearings). The problem of the legacy system of ‘hard’ side bearings is, that optimal spacing has to be accomplished by adding exceptions in the form of kerning. The lengthy kerning pairs and subsequent technical problems in OpenType fonts are a good example of this limited approach. If the user does not use the kerning, for instance because it is turned off by default in a word processor, the system does not make sense at all. In short: kerning is part of the spacing, not an exception.
In my research the translation of the spacing into distances results in line pieces (the length is identical, the angle not) which can be read as a graphical representation of the spacing. My theory is, that the more uneven the graph is, the more proportional variants the typeface in question contains. It also could be an indication that the spacing is awkward, of course, and therefore this has to be checked first against the Rhythmic System. One of my ideas behind the graphical representation is, that this could turn out to be useful for legibility research.
I don’t know if the translation into centerlines will work as a practical solution for Latin, let alone for any other script. I can imagine that such an approach leads to a sort of ‘class spacing’. The start point of the space (left side bearing) of a character would be half of the distance-line (center to center) to itself, I reckon.
 
In his lengthy e-mail John stated ‘[...] I do think the notion of rhythm is useful and important, but it neither refers to a universal phenomenon -- different writing systems and different styles display different kinds of rhythm [...]’
 
I would like to add to this statement ‘different kinds of harmony’. For my talk at Leiden University in May last year, I invited a Korean musician with a master degree from the Royal Conservatory to make a comparison of (the rules for) harmony as we know/use in the Western world and the equivalents in traditional Korean music. Basically the outcome of her highly interesting presentation (she sung beautifully) was, that there is no such thing as ‘our’ harmony in traditional Korean music. I also invited a Korean student of mine to try to compare Latin script-representations and Hangul to seek for similarities in harmony.
 
So, I would treat any script-representation as a result of its own rules and I would encourage a subsequent description of the harmonic and related rhythmic dynamics for this. Thomas Milo is doing this for Arabic and the different approach in DecoType is the result of this thoroughly based insight.

One missing piece of this conversation is that the drawing and vertical alignment of letters is not two processes is it? We chose heights and then use them as guides not walls.

Missing part two is performance.

And missing part three is the font in a bubble, (arabic), vs. the font in a bath tub, (latin).

I have not only thought about this, but I've watched certified geniuses pour millions into solutions that max out at 90% for simple ! Latin fonts.

Besides, 36.5% (arguably) of the type we are reading today is on screens, and the bozos in the 'composition department' are not interested in solving the simple problems we have today, with the simple solutions we brought yesterday.

>What's obvious and boring?

Don't ask, he's gone totally troll, IMHO.

Cheers!

Frank: Even if spacing is script-representation specific, then one needs at the end a common way to describe the spacing of different script-representations in a font format still, I reckon. The translation of the spacing into distances between the optical (center/heart) lines of the letters, is at the moment the best method I can think of....

I agree that a common font format description of spacing is desirable, but I don't think a distance measure suffices any more than flat sidebearings suffice.

How is the centre line defined? As an average height in a font? Or on a glyph-by-glyph basis? If the former, how do you handle punctuation and other glyphs that sit below or above an average centre line?

How does this spacing model relate to and account for combining diacritical marks, which is the problem prompting me to question the OpenType glyph positioning model? What's the point of spacing according to centre line distance if the result is collision of parts of adjacent typeforms that impair legibility?

So, I would treat any script-representation as a result of its own rules and I would encourage a subsequent description of the harmonic and related rhythmic dynamics for this. Thomas Milo is doing this for Arabic and the different approach in DecoType is the result of this thoroughly based insight.

There are strong arguments to be made for optimised, writing system specific layout technologies. On the other hand, it may be possible to come up with a general description of ‘adjacency’ -- bearing in mind that what we generally think of as spacing, i.e. separation, is only one kind of adjacency --, and hence a potential foundation for building a spacing model that can be easily adapted to various writing systems, i.e. one that is capable to taking into account different kinds of adjacency relationships. In my e-mail to Frank, I wrote, among other things:

One approach to developing new techniques is to start with a limited application, solve that, and then extrapolate to other applications. But the danger -- almost the certainty -- of such an approach is that you will eventually hit an application to which you cannot extrapolate the original solution, and you find that the limited scope of the initial application resulted in a poor foundation. In some respects, we could say that this is exactly the problem with OpenType: it has tried to extrapolate too far the spacing paradigm of metal type. My preferred approach is to try to build as big a picture as possible, taking into account all the problems that need to be solved, and then determine if it is possible to develop a technique that will satisfy. In the case of spacing type, I think such a picture needs to include all the world's writing systems in all their styles and all the variations of ways that adjacent 'typeforms' relate to each other.

Typeform is a term in use at Reading, and I think it is a very useful one. A typeform is the rendered representation of a unit of written language; the nature of the unit depends on the writing system and other factors, but in the case of the Latin writing system a common typeform might consist of a single letter or of a letter plus diacritic mark(s). The nice thing about the term typeform, because it refers to the rendered representation, is that it is technologically agnostic, in particular it doesn't presume anything about either the encoding of the typeform or its glyph composition: the same individual typeform may represent one or more characters and be built from one or more glyphs. So, for example, this typeform:

might represent 1-3 encoded characters rendered with 1-3 glyphs. The same typeform could represent different numbers of encoded characters, even in different parts of the same document, and different combinations of glyphs depending on the font used.

As I spoke about during the DTL conference, I consider the interaction of spacing adjustments and mark positioning to be the weakest aspect of OpenType. And in trying to think through the reasons for this I've come to the conclusion that spacing has to take into account typeforms, not glyphs. I don't think you can solve the spacing problem at the glyph level, which is why I think something like centreline distance is a non-starter. Spacing has to take into account the profiles of the whole typeform (leaving aside for now spacing for vertical scripts), not just the base letter.

Many of the world's writing systems employ what I call static typeforms with regard to spacing. This is the case with Latin. What I mean by this is that once a diacritic mark is applied to a letter in the Latin script, it forms a static unit that must be spaced relative to adjacent typeforms as a unit, i.e. the mark remains in a fixed relationship to the base letter regardless of adjacent shapes. There are other writing systems, of which Arabic is an obvious examples, in which typeforms remain dynamic relative to adjacent shapes and their spacing, i.e. the marks will move relative to the base letter in order to accommodate adjacent shapes. So this difference, too, needs to be taken into account in the full picture.

Because the formal typographic styles of the Latin writing system use mostly disconnected letters, we tend to think about spacing in terms of distance or separation. I think this is a poor basis for a full picture, because most of the world's writing system admit of connection as well as separation; indeed, the Latin writing system itself has some of the most fully articulated traditions of connected writing. And in some writing systems, of course, connected styles are the norm of virtually all writing; again, Arabic is an obvious example. So I would say that both separation and connection need to be taken into account in considering the relationships of adjacent typeforms.

So far, we have two kinds of typeforms:

static
dynamic

and two kinds of adjacency:

separation
connection

I doubt this constitutes a full picture, but it's a start.

Connections, of course, may be elongated or extended in some circumstances. The elongations of Arabic letters are traditionally not directly related to adjacency, i.e. one doesn't normally elongate in order to resolve a relationship of adjacent letters and their marks. In Devanagari, Bengali or Gurmukhi, though, one may extend the headline connection between letters/conjuncts in order to avoid collision of superscript vowel signs and other marks.
___

This kind of analysis suggests to me a properties-based approach to adjacency, whereby one would specify at the glyph level the kind of relationship(s) a glyph can have to adjacent glyphs. For some writing systems, Unicode attempts this at the character level, which is the basis of e.g. Unicode Arabic layout, but as font developers we know that adjacency really needs to be resolved at the glyph level, not least because there are styles of lettering that contravene character property models, e.g. Arabic styles in which a nominally ‘isolated’ alif may connect, at the top, to a following lam. This is connectivity as a typeform adjacency property.

Why not just eliminate the left sidebearing (talking about western systems), or better: use a kind of marker on both (or even four) sides that represents a balance of mass protruding and inherent. One could then define a space between glyphs which would essentially be an optical optimum. Or am I being deranged here?

Centerlines only help in symmetrical glyphs, there has to be something that accounts for shape and weight--perhaps a grid system of space units based on UPM which build the space according to shape?

Bert, can you explain what you mean by ‘balance of mass protruding and inherent’?

David Kindersley's spacing model was based on a notion similar to balance of mass, as I understand it. One would locate the vertical optical centre of a letter -- which Kindersley tried to automate based on analysis of mass and form --, and then make this the mathematical centre for spacing purposes. The idea of spacing outwards from an optical centre is an alluring one. My analysis says that this system works best for all-caps display settings, though.

Further to my point above, though, one would need to be able to apply such a method to typeforms, not just to glyphs. Otherwise one will run into exactly the same spacing and mark interaction problems that we're hitting with OpenType. This is why I keep coming back to the bubble model, because in theory glyph order needn't be an issue: the bubbles of multiple glyphs forming a single typeform -- e.g. a letter plus one or more combining marks -- form a composite bubble that has the same spacing behaviour relative to adjacent bubbles as a single glyph bubble would.

Chris: ...perhaps a grid system of space units based on UPM which build the space according to shape?

I think this concept of building the space according to shape is something worth hanging onto.

A grid system would be similar to the Compugraphic unitised banded spacing. It's certainly possible, but why unitise? The UPM represents the glyph shape grid, so why not use the same grid for spacing shape, i.e. allow the spacing shape to be as flexible as the glyph shape?

[Some aspects of Microsoft's math layout actually measures ‘ink’ during layout, i.e. records the position of outline edges and calculates optimal (or tolerance based variation) of position of other elements of layout. Effectively, this is defining bubbles during layout.]

"The UPM represents the glyph shape grid, so why not use the same grid for spacing shape,"

That is what I meant, John. Sorry I was unclear.

An illustration of the problem of kerning and mark positioning interaction might be helpful at this stage. This is a relatively simple example, involving a single combining mark.

What happens during glyph substitution is that the regular i glyph is replaced by a dotless i when followed by a combining mark above (in this case a combining candrabindu). So the character sequence

0054 0069 0310

is displayed using the glyph sequence

/T/dotlessi/candrabinducomb/

The problem is that there is a pair kern between /T/ and /dotlessi/ of -70 units, and this kerning will be applied because these two glyphs are next to each other. This causes the following combining mark to collide with the crossbar of the T.

In a font using old-fashioned kern table pair kerning, this is a shіt-out-of-options situation: other than disabling kerning completely there's no way to prevent this from happening.

In a font using GPOS kerning, one has the option to contextually adjust or replace the kerning between the /T/ and /dotlessi/ to account for combining marks on the latter. I can speak from experience in saying that this is no fun: even if you try to group marks by similar widths, you end up requiring loads of separate lookups, one for each width of mark as context.

What's missing is a way to define the adjacency relationships of multiple glyphs combined in typeforms such as /dotlessi/candrabinducomb/ as units.

Now, if we imagine a bubble around each of the glyphs, defining a minimum distance at each point around the outline to which another bubble may intrude, we can see how combination of the bubbles of glyphs forming typeforms into a single bubble for spacing purposes has the potential to enable correct spacing in all situations.

This isn't an easy shift to make in any respect. I've tried making bubble outlines manually, and trying to wrap my mind around where the bubble outline should go in order to get the desired relationship to a variety of different adjacent glyphs does my head in. [The bubbles in the image above are very crude, and designed only to demonstrate the potential for solving this particular illustration.] What I can imagine from a tool perspective is an interface that allows one to drag or cursor glyph outlines into ideal spacing relationships with a variety of other glyph outlines and then to automatically calculate bubble shapes based on these relationships.

John, would you kern the bottom of an /A/ under that /T/ further than what it looks like your bubble allows?

Did you think of other alternatives to having the bubbles be "hard" limits defining a minimum distance? (In a sense this is not a different paradigm from metal type bodies, just a version that allows for unprecedented amounts of filing down the sorts!)

Another option would be larger bubbles that define a maximum distance (that is, that would overlap and wouldn't allow the gap between the /T/ and /i/ in your example). Or maybe the answer lies in in-between-size bubbles that are allowed to overlap and to have gaps, and which are positioned so that their total deviation from each other along their common height is mathematically minimized.

I'm just throwing ideas out; I haven't thought through the feasibility nor preferability of them...

The problem seems to be that kerning is done between glyphs instead of between typeforms in the example of the i with a candrabindu. This is an implementation flaw in the typesetting system.

The original article seems to have been intended as a "think piece", though. Moveable type is made possible by it being possible to assume glyphs have a usual amount of white space around them - white space in a nice convenient rectangular shape, at that, so that metal type, without kerning, works properly most of the time.

This reminds me of a claim I recently read that the spacing around capital letters has to be designed in favor of the more common case of a capital letter preceding the rest of a word in small letters - so that text in all capitals does not look quite right, and needs a slight amount of letterspacing. This discussion has inspired me to think of a very simple solution to that which doesn't even involve kerning.

A capital letter should be surrounded by X space on each side for all-capital use, but only by Y space on each side when surrounded by small letters? All right, give it 2X-Y space on the left, and Y space on the right, and both cases look just fine. The kerning tables can then be reserved for the special cases, without a need to clutter them with every combination of two capital letters or a capital letter and a small letter.

Craig, as I wrote, the bubbles in that illustration are crude and only designed to make the general point about bubble relationships. I suspect the ‘correct’ bubble shape for T would involve diagonals under the crossbar coming in towards the baseline. It's because of the difficulty of conceiving of the necessary bubble shape that I think a tool that automatically creates bubbles based on designer-defined adjacency relationships would be necessary.

Now, it is certainly possible that there might be situations in which the bubble shapes necessary to obtain optimal spacing between glyph shapes (a) and (b) prevent optimal spacing between shapes (a) and (c). Again, I can't say for sure because I find it to hard to wrap my head around the implications of all the different combinations. The bubble shapes may be far from intuitive in some cases.

Since we do have a store of well made fonts with good sidebearing settings and kerning, one way to test the bubble theory would be to try to convert the spacing and kerning of an existing font into bubble spacing.

John: How is the centre line defined?

The distance line I have in mind is connecting the center lines of the characters. These center lines mark the center of the 'traditional’ width in between the side bearings, which is also the optical center of the character when it is centered in the width. The distance line is the ‘traditional’ space plus the kerning and basically it can be applied from any vertical position on the center line, except when there are exceptions. The center line is the (range of) point(s) of measurement then for all other stuff, such as the stacking of diacritics and subsequent prevention of collisions.

Please note that I am not using the distance line to come to the ‘basic’ spacing; it initially converts this. In one of the next versions of LeMo for the auto-spacing the Rhythmic System (structure) will be combined with KernMaster algorithms (area) and the result translated into distance lines.

By the way, for those who want to export the data LeMo generates to FontLab Studio, the Ikarus format will do because the IK glyph database will be directly converted by FLS.

@quadibloc: > The kerning tables can then be reserved for the special cases, without a need to clutter them with every combination of two capital letters or a capital letter and a small letter.

But you will need to clutter the kern table with every combination of space and capital letter. And, if one cares to accommodate contemporary interCaps usage, every combination of small letter and capital letter. And every combination of [opening member of paired punctuation] and capital letter. Etcetera.

Frank,

Ah, you're talking about a vertical centre line. I didn't clue into that before, and thought you were talking about an horizontal centre line.

Can you provide some visuals to help explain the idea? I'm especially keen to understand how ‘the center line is the (range of) point(s) of measurement then for all other stuff, such as the stacking of diacritics and subsequent prevention of collisions’.

John: Can you provide some visuals to help explain the idea?
 
I just made a few (somewhat simplyfied) illustrations to explain my ideas:
 

Jongseong -- Ideally, I would like to see a font format powerful enough to handle something like Tom Milo's Arabic layout model internally.

I do not understand the recent desire, emerging here and there, to invent ACE once again. Why a font format like ACE? There is ACE. It may or may not need some kind of adjustment to deal with non-Arabic scripts,* but it is a toolbox prepared for the aspects of layout behavior which I have come across so far.

terminaldesign -- Oh so obvious and oh so boring. Didn't any of you ever set metal type?

Metal type is exactly what contributors to this discussion want to be overcome. Looking at metal type is helpful only to see where limitations of current font technology have their origin, and then going back pre-metal-type.

quadibloc -- A capital letter should be surrounded by X space on each side for all-capital use, but only by Y space on each side when surrounded by small letters? All right, give it 2X-Y space on the left, and Y space on the right, and both cases look just fine.

I use such a method since about 2006. It is briefly sketched in a PDF which you can download here.

* And now I notice a certain irony, given the usual notion of non-Latin scripts.

[I must apologize for copying/pasting user names rather than real names.]

Karsten, I developed my ideas more fully in this thread. There, you can see my motivation comes from wanting to overcome limitations on the design of hangul, the Korean alphabet. ACE by itself is insufficient for what I'm thinking of for hangul; I'm using ACE more as an example of what is possible by breaking out of the OpenType paradigm.

I'll try to go back to that thread when I have time and explain what is needed for hangul design, because I know this topic is unfamiliar to most people here.

Brian: ...breaking out of the OpenType paradigm.

Dynamically composeable Hangul is possible within the OpenType glyph processing model, I reckon. It's just a bit different from how Hangul is typically handled in OpenType fonts.

Frank,

Okay, so I see how you arrive at the centre line, but I don't see the relationship of centre line to distance. Distance seems to be arbitrary and not significantly different from a typical sidebearing approach to spacing. Your adjustment to clear the mark above the i in the 'collision zone' looks like a kern. It seems to me that you still need something like my concept of typeform to know that the i plus mark needs to be spaced as a unit and not as individual glyphs.

John: Dynamically composeable Hangul is possible within the OpenType glyph processing model, I reckon.

Yes, the composition itself is possible, and I've seen some attempts to exploit that possibility, I believe.

But for even a remotely acceptable text design, the components have to vary in shape, size, and position according to context. I'll reuse the image from a previous thread to illustrate:

And this is just showing the possible variations on the initial consonant when the vowel is fixed and the final consonant is the only variable.

In the current model, the best we can do is individually design the 2,350 or so most-used syllables for modern Korean, and extract the hundreds to thousands of individual components from them to be used for composing less common syllables. But this still isn't adequate for all theoretical hangul syllables. What I had in mind is a way of generating the appropriately shaped and sized component from the contextual information, and I don't see how that is possible within the OpenType paradigm of ready-made glyphs.

John: [...] I don't see the relationship of centre line to distance. Distance seems to be arbitrary [...]

John, there is nothing arbitrary in the shown model and also there is no kerning, as you implied. I will give a summary of the elements involved below. The model makes simply use of the traditional ‘side bearings’ structure and converts this into a more flexible and in my opinion as calligrapher, also in a more organic one. The conversion of the current system into mine should not be to complex and also it should be possible to reverse it. This is important for those who don’t want to change their font production workflow –I am one of them. It is also important that existing fonts can be converted to the new system without problems.

— center line: The center in between the side bearings; normally (preferably) the optical center of the glyph. This is the point of reference for the positioning and stacking of glyphs, the distance, and the glyph boundary.

— distance: The distance from the center line to the center line including the kerning (which, of course can be positive or negative). This value is the result of the spacing of characters (which traditionally is translated into side bearings plus kerning).

— glyph boundary: Theoretically an arbitrary distance measured from the center line, which can be an extreme of the glyph on the x-axis or this extreme plus some extra space (to prevent collisions) or the ‘classical’ width (side bearing to side bearing). The glyph itself has no width, i.e., this is zero, which makes the stacking of glyphs possible.
The glyph boundary is used to prevent collisions of glyph parts. In defined areas (collisions zones) the boundaries are compared. A unit of stacked glyphs has multiple boundaries, but always a common base: the center line. If one of the boundaries collides with one of the boundaries of the previous (stack of) glyph(s), the complete unit, i.e., the center line will be shifted. If multiple boundaries collide, the largest glyph boundary will be used for calculating shifting.

— collision zone: Area which is scanned for collisions of glyph boundaries.
 
 
Nicolaus Jenson clearly had a more simple solution to prevent collisions with accents; actually a constant mark shift to the right did the trick:
 

a constant mark shift to the right did the trick

and what did say a ‘ſũb’ or a ſũt look like? :)

Thanks, Frank, for that explanation. If I understand correctly, this is a solution that simplifies stacking of glyphs. I'm confused about one thing though: does distance need to be specified between every pair of glyphs?

[Briefly, since this leads off the track of this discussion:]

jongseong -- thank you for the link. Yes, what you say about CJK fonts and OTF sounds right. The currently most promising approach for CJK fonts might be Mitsubishi's Stylized Stroke Font. Actually I would like to see this combined with ACE to provide an even more powerful toolbox. My assumption is that even scripts which at first glance are very different still have some things in common -- and that in an ideal world, each script would choose the pieces which it needs from a layout behavior toolbox that transcends the requirements of any individual script.

Brian: [...] this is a solution that simplifies stacking of glyphs [...]
[...] does distance need to be specified between every pair of glyphs? [...]

I think of it as one way to circumvent a couple of limitations inherited from movable type, such as spacing which is at the moment defined by ‘rectangle to rectangle’ still plus corrections (kerning). The distance value is spacing plus kerning, so no kerning pairs are needed anymore. The center line approach also helps to overcome problems like John sketched above. Surely this system will have its own limitations too, but it solves a couple and I reckon that conversion from and to the current description should not be too complex.

The distance has to be indeed specified between every pair of glyphs, but as I mentioned this can be calculated from the current (side bearings based) system plus the kerning pairs. No additional work has to be done basically, although any other possible method to calculate the space/distance and the center line would be fine (and interesting) too (see my notes on the Rhythmic System).

I see what you mean. This proposal has the practical advantage that you can keep using side bearings and kerning pairs just like now, only they will be used to define the centre line and distance values so that any stacking problems are solved automatically.

So this is a simple solution to a specific problem, compared to the other proposals above like using bubbles which are complex ways of attacking the more general problem of spacing. It may be possible to synthesize several of these ideas, but there is indeed a lot to wrap your head around.

Frank, when I wrote that the relationship of centre-line and distance was arbitrary, I meant only that it was freely variable, being defined relative to some third factor, which you now identify as ‘glyph boundary’. Hence, the distance between the centre line of adjacent letters will vary depending on what those glyphs are, and hence is as arbitrary as the shape and width of those glyphs.

It seems to me that what you are describing is something very close to what we already have, with the addition of a centre line between the two sidebearings. I'm still don't understand what is the purpose of the centre line that distinguishes centre line distances and adjustments from sidebearing distances and adjustments.

The glyph boundary is used to prevent collisions of glyph parts. In defined areas (collisions zones) the boundaries are compared. A unit of stacked glyphs has multiple boundaries, but always a common base: the center line. If one of the boundaries collides with one of the boundaries of the previous (stack of) glyph(s), the complete unit, i.e., the center line will be shifted. If multiple boundaries collide, the largest glyph boundary will be used for calculating shifting.

How is the unit of stacked glyphs -- the typeform -- identified? As I wrote above, it seems to me that the model needs some kind of mechanism to identify typeforms. [Note that this can't necessarily be done via character-level analysis -- e.g. grouping combining mark characters with preceding base characters --, since typeform composition may be a glyph-level operation that doesn't directly reflect the underlying character string and may involve glyphs that are not categorised as marks.]

Can you clarify this statement: ‘A unit of stacked glyphs has multiple boundaries, but always a common base: the center line.’? Are you implying that the centre lines of the different stacked glyphs are aligned, or that a new centre line is somehow defined for the whole unit? If the former, note that you cannot presume that mark positioning involves aligning centre lines, since there are lots of cases, especially when one gets beyond the Latin script, where this is not the case, where the correct position of a mark on a given base will be offset to the left or right of the centre, sometimes even being placed mostly outside the sidebearings of the base glyph (e.g. Hebrew prepositional accent marks).

Brian: What I had in mind is a way of generating the appropriately shaped and sized component from the contextual information, and I don't see how that is possible within the OpenType paradigm of ready-made glyphs.

OpenType doesn't have a paradigm of ready-made glyphs. OpenType has numerous mechanisms by which to create typeforms, one of which is ready-made glyphs. As I wrote above, I think composeable Hangul is possible within the OpenType model, even though it is different from how Hangul is typically handled in that model, i.e. different from how Hangul fonts have been made so far. It is these fonts that have a read-made glyph paradigm, not OpenType.

What we have in Hangul syllables are arrangements of components whose shape and size is determined by their context. So long as the context can be defined, the selection of appropriate shapes and sizes is quite easy. In most styles of Hangul, it seems to me, the variety of shapes and sizes is reasonably limited. You have full size, top-half, bottom-half, bottom-left and bottom-right variants to consider, yes? With perhaps some additional refinements based on adjacency in the bottom half? Indeed, it seems to me that most of the Hangul fonts I have looked at, even though they use read-made, precomposed syllable glyphs, do so using modular outlines for these different shapes, sizes and positions. So composability is really a question not of designing and putting shapes together, but the stage in display where this putting-together takes place: in the design of ready-made syllable glyphs in a font, or dynamically during layout.

A Hangul syllable composed of three components, can be composed dynamically from a single spacing glyph and two zero-width glyphs treated as if they were ‘marks’ for GPOS handling. Note that for something to be handled as a mark in GPOS does not require that it represent a mark character: a mark glyph is simply one that may be positioned using an anchor attachment. [That said, I do want to see the OpenType GDEF categories expanded, because there are instances in which one wants to be able to do things to anchor-attached glyphs that do represent mark characters independently of other anchor-attached glyphs. The pressing example of this is the distinction between dots and vowels in sub-character decomposed Arabic.]

Because the formation of Hangul syllables is so regular, I'm guessing that the anchor attachment positioning data would be pretty easy to implement.

John: It seems to me that what you are describing is something very close to what we already have, with the addition of a centre line between the two sidebearings

The center line approach is in my opinion quite different from and more versatile than the side bearings based one, as I tried to explain above (but obviously without convincing you). The side bearings can be used to calculate the center line, distance and the glyph boundary, but I can imagine other ways to come to this data also. At least the option to convert the side bearings (and kerning) should make the system backwards compatible, which is a requirement for possible implementation, I reckon –especially when one takes the historical development of type and typesetting systems into account.

Are you implying that the centre lines of the different stacked glyphs are aligned [...]

Yes, that is actually the basic idea. Any offset of marks in reference to the center line should be possible too, of course.

I have asked the FM programmers at URW++ to have a look at the practical side, i.e., the technical (implementation) consequences and also the possible limitations of my ideas, to prevent things from becoming purely theoretical.

John, you make designing hangul sound too easy. With 19 consonants (5 of them 'double consonants') and 21 vowels each having around 5 variants each, around 200 or so components would be enough to be composed to give all the required syllables for a hangul font.

Such an approach is of course possible. Modular design goes all the way back to the hangul typewriter faces, and since the 1980s with the work of Ahn Sang-soo and others there has been a bit of revival in that style of design.

But such work results in idiosyncratic display faces with a mechanical flavour and is judged utterly unsuitable for text faces. Designing hangul text faces is much, much more than designing modules and composing them.

I've heard non-Koreans who have examined hangul say that designing a hangul face seems straightforward enough with a modular approach, and I suspect Koreans who have not tried type design think the same thing. But once you see what results from this approach, it is crystal clear that it simply is not acceptable for a text design.

There is something I have noticed from time to time in older Korean books. When the Korean text calls for a rare syllable (for the transcription of foreign names, for example) that is not provided by the typeface, the compositor puts together the syllable manually from existing elements of the typeface. And the result invariably jumps out as ugly and malformed, not because the compositor isn't skilled, but because you can't just use the modules without modification.

Hangul has always been written in syllabic blocks, and when writing by hand we automatically refine the proportions and harmonize the different elements. And in existing text faces, we have become used to seeing each syllable be designed with careful consideration for the balance of size, balance of weight, and balance of the white space. So when we see a design that uses cut-and-paste modules without modification, resulting in unsightly gaps and clashes and uneven density, the disunity jumps out at us.

A modular approach of course is necessary for designing hangul, but it only really is the first step. The hard work is modifying the modules for all the different syllables. This isn't just about stretching into different sizes. The centre stroke of ㅏ will vary in height according to the consonant it is next to (quite high for ㅂ, quite low for ㅎ, as these shapes have different centres of gravity). The centre stroke of ㅜ will be shifted right if there is a ㄴ below, to distribute space more evenly. For a more subtle example, here is a sample image of an intermediate stage in the design of a text face called Cheonggiwa (청기와) before and after modifications of the raw composed syllable (taken from here):

Unicode has code points for 11,172 precomposed syllables of hangul, corresponding to all possible combinations of the initial and final consonants and vowels used in modern Korean. It is of course too time-consuming to fine-tune every single one of these by hand. But once you fine-tune enough syllables, you will have produced many repeating elements that could be reused for different syllables. It's just that instead of the 200 or so of the naive modular approach, you have thousands of them.

As an example, I examined Nanum Myeongjo (나눔명조), a font that supports all 11,172 possible modern Korean syllables. Of these, the 2,350 or so most-used characters are designed individually and do not use components. The rest are assembled with components. I counted 2,813 of these components.

So yes, hangul fonts with extensive syllable support use modular outlines. Just too many of them for the layout model you are talking about to make economic sense.

Brian: Just too many of them for the layout model you are talking about to make economic sense.

I'm not convinced. It seems to me that if the goal were the best possible Korean typography, then such an approach would be the most economically efficient if, as you say, it is ‘too time consuming to fine-tune’ all the possible syllable combinations. As you say, fine-tuning the most common 2,350 already gives you a huge number of potentially modular elements. I'm suggesting a way in which these could be utilised intelligently to produce the best results for the remaining syllables, based on contextual rules.

I'm also confused, because earlier in this thread and in the other one you started you cited technology like ACE as a possible inspiration for new approaches to typography of Hangul and writing systems. But what I described -- contextual use of sub-typeform modular components -- is how ACE works. I'm just pointing out that the same thing can be achieved in OpenType (there are other aspects of ACE layout that cannot be achieved in OpenType).

Frank: The center line approach is in my opinion quite different from and more versatile than the side bearings based one, as I tried to explain above (but obviously without convincing you)

It isn't that you have not convinced me, but that I still do not understand the practical difference between measurement of distance from a centre line that is derivable from sidebearings and a measurement of distance from sidebearings. If the centre line were based on a principle of optical weight, as in Kindersley's model, then I would see the difference, because the optical centre of a glyph is not necessarily the mathematical centre line between sidebearings.

Let's consider the ‘Tia’ glyph sequence in your illustrations above. You have a centre line on each glyph, and a distance between the centre lines: T to i and i to a. Where are those distances defined and stored? It seems to me that part of each distance belongs to the left glyph and part to the right glyph, and that's why it doesn't seem to me practically different from sidebearing spacing.

John: [...] If the centre line were based on a principle of optical weight, as in Kindersley's model, then I would see the difference [...]

When I wrote: [...] The side bearings can be used to calculate the center line, distance and the glyph boundary, but I can imagine other ways to come to this data also [...], Kindersley’s model is one of the first other ways that come into one’s mind, of course.

Where are those distances defined and stored?

The ‘where and how’ storage question, the interaction with the current system and the related consequences for support by applications are amongst the things I asked the FM programmers to have a look at and which I will discuss with them in Hamburg midst of February.

John: As you say, fine-tuning the most common 2,350 already gives you a huge number of potentially modular elements.

Yes, and maybe even all the elements needed for the syllables possible with modern Korean jamo (the individual consonant and vowel letters).

But this model is not extensible to additional jamo, such as those used in old Korean, in obsolete transcription systems for foreign sounds (such as 1953's Deuronmal Jeokgibeop of the Ministry of Culture and Education), in the system for writing Sino-Korean used in the Dongguk Jeong-un (1448), and the vowels ᆞ and ᆢ used for writing the modern Jeju dialect. These are particularly ill-served by typography, as everyone understandably balks at the prospect of having to design thousands of more syllables. Only a few hangul fonts support all the 11,172 syllable combinations of modern jamo as it is.

Digital technology and the encoding of hangul jamos separately in Unicode was supposed to make supporting these additional jamos easier, but fonts have not caught up at all. Even the very few fonts that support old Korean only support attested syllables and encode them using the Private User Area. Not surprising since, if I'm counting correctly, there are 124 × 94 × 138 = 1,608,528 possible syllables that can be encoded by Unicode.

The following image was taken from this Microsoft typography page on developing OpenType fonts for Korean.

The individual jamo elements all exist in modern Korean, but none of the particular combinations (initial consonant, vowel, final consonant) is in use in modern Korean. For the composition described on the Microsoft page to be correctly implemented using the ccmp, ljmo, vjmo, and tjmo OpenType features, each of these combinations ㅂㅅㅌ, ㅗㅒ, and ㄹㅁㅎ have to be designed for their appropriate context. You couldn't use any elements from the 2,350 most common syllables or even the 11,172 syllables of modern jamo for this, because these are some of the most obscure combinations, not in use in modern Korean. You could probably count on one hand the number of fonts in existence that can display this syllable. I'm not even sure that New Gulim, the font which I think is used for the above illustration, actually supports this syllable; the sample could have been put together for illustrative purposes, for all I know.

If we had parametrizable jamo, then it should be easy to compose the above syllable using existing elements for modern jamo. This is not something that can be done with the current model.

I realize that the applications I am talking about are very specialized. Maybe extended Korean is the only writing system for which the model I am talking about makes sense. But there are many writing systems and styles in existence, and there is a chance the model could be beneficial if not necessary for some of them as well. It could be just my mathematical background speaking in terms of finding a general solution, even if the existing limited solution suffices for 99% of our needs.