Highsmith on Glyph Space

[eliason]

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...

[quadibloc]

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.

[John Hudson]

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.

[blokland]

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.

[kentlew]

@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.

[John Hudson]

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’.

[blokland]

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

 

 

 

 

[k.l.]

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.]

[Jongseong]

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.

[John Hudson]

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.

[John Hudson]

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.

[Jongseong]

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.

[blokland]

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:
 

 

 

[JoergGustafs]

a constant mark shift to the right did the trick

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

[Jongseong]

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?

[k.l.]

[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.

[blokland]

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).

[Jongseong]

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.

[John Hudson]

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).

[John Hudson]

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.

[blokland]

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.

[Jongseong]

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.

[John Hudson]

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).

[John Hudson]

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.

[blokland]

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.