Glyph Sidebearings and Text Alignment

Yury Yarmola

Isn't it a good time to finally fix this very old bug?


Since the early typesetting programs, sidebearings (which are nothing more than a way to define default spacing between letters) have been used to align text.

For 30 years now, all text has been misaligned with respect to the optical edge of the glyph. The most interesting thing is that in most fonts this offset is known and corresponds to the margins of the letter 'H':


If corrected by the 'H' sidebearing, text alignment is magically fixed:

Some time ago, I discussed this problem (and solution) with Ilya Zherikov, who then created a plugin for Figma that implements optically correct text alignment: https://www.figma.com/community/plugin/1007645801320386272

Of course, the 'H' "hack" is only a very simplified way to solve this, there should be a way to properly define "default" optically-correct edge for all glyphs of the font and a way to specify it for individual glyphs.

There are OT features registered for this ("lfbd" and "rtbd"), but 1) nobody puts them into any font; 2) there are too many fonts already without these features, which takes us back to the "H hack".

What do you think? 

John Hudson

If corrected by the 'H' sidebearing

Deduct the distance of the H left sidebearing from the left side of every glyph at the beginning of a line, yes? Perhaps at tab settings too?

Yury Yarmola

Yes, it should be applied to tab lines as well, since it is basically an align line, similar to the text block edge. Very good point!

Yury Yarmola

Of course, in the ideal world we will have the "optical offset" value as a font parameter (with the ability to customize it per glyph, as a kerning with "null" glyph, or as "lfbd"/"rtbd" features), but in most cases sides of H provide the offset in a very natural way. 

In fact, one of the big owners of the text layout engines should stop ignoring this very obvious problem (so others will follow).

Funny is that every line of any text automatically formatted on a computer in any application in any operating system or browser from the very first time, is wrong! Simply because some engineer somewhere decided that the glyphs' origin point is where the text line starts and origin point + advance width is where the line ends. This is normal for an engineer who may not know how a typeface works, but how it has lasted so long is a mystery.

Mark Simonson

This problem predates early typesetting programs. It has existed in type since Gutenberg. With some post-metal typesetting methods, such as film headline setting and rubdown type, because of their manual nature, it wasn't an issue. But it was carried forward with machine photocomposition.

It does seem strange that this old physical limitation has not been addressed in digital type in some way.

John Hudson

Of course, what works for letters might not work for all characters, and what works for Latin might not work for other scripts.

Yury Yarmola

In my "hack" proposal 'H' serves as "some glyph with vertical sides on left and right", a way to decode the offset to optically-correct beginning of the glyph. While other glyphs may serve the same purpose in other languages, rule is the same.

Yury Yarmola

Mark Simonson said:

This problem predates early typesetting programs. It has existed in type since Gutenberg. 

Right, but the side-align problem is much less visible in the text size and pre-computer text layout mostly had centered headers, which had to be manually aligned anyway.

Manual alignment of the [side-aligned] headers is something that many better designers do now [more often on the web], which makes correct layout an exception while it should be the rule.

Cory Maylett

I seem to remember this subject coming up several months ago.

I mentioned Adobe InDesign's optical alignment, which brings the edges of columns of body text a bit more into visual alignment. Others said they would prefer the extreme edge point of every glyph to vertically align against the edge. This had never occurred to me as something anyone would want since I think some glyphs need to hang a big out beyond the edge for the same reason overshoots are used to optically balance the tops and bottoms of glyphs.

My takeaway, though, was that there was disagreement over what looked best. Even if there were ways to address the problem within the fonts rather than in a page layout application, people would complain that the alignment wasn't to their liking.

Jasper de Waard

Does anybody know which applications support lfbd and rtbd?

Yury Yarmola

Of course, "H hack" is just a very simplified way to solve it, working only with geometrically simple sans-serif fonts. 

In serif fonts things get more complicated and while some tricky calculations of sidebearings and kerning may produce some acceptable result, the better intermediate solution is to have font-wide parameters dealing with it in a way similar to how [hhea] caretOffset works. (We have plenty of "reserved" entries in [hhea], so adding alignOffsetLeft and alignOffsetRight there can be done easily).

I will try to make a simple table of the alignOffsetLeft values for some of the most popular Google fonts, so it can be used to check the fixed-offset solution with CSS. Will do it in a very simplified way: as a distance from LSB to the H glyph contour in the middle of the Caps Height.

Florian Pircher

You might be interested in EB Garamond which has optical compensation definitions for the microtype TeX package (microtype calls these adjustments protrusions). The left and right protrusion values for various glyphs are listed in the mt-EBGaramond.cfg file.

I believe these values are less about aligning type of different size and more about lines in a block of text. Still, it demonstrates the optical compensation that some of the worst offending glyphs might require.

Yury Yarmola

A single value is equivalent to a spacing without kerning. This is better than just random glyph overlay, but not enough, so there must be a way to define exceptions for certain glyphs like the "protrusions" described by Florian above.

We already have 2 registered functions for this, but there is probably a better way: what if we used kerning with a space to align a text string? Then the rule is simple: when left-aligned, the layout should check if there is a space-glyph pair and use that offset. If there is no such pair, then [hhea] is used.

Georg Seifert

The lfbd and rtbd seem to be a better solution. As kerning with space messes up the spacing inside the line. So if someone implements this, it should be done properly. 

To test the correcting effect, one could build a contextual positioning feature that is only applied if there is nothing before it (of cause that would also be applied after any format change). 

I just added some code that if you add anchors named like the features, it would export those features (like it is already doing for PALT and such features).

Is there any app that supports lfbd/rtbd?

Yury Yarmola

Of course, dedicated features will work better, but it will take years to have fonts fixed that way. 

Btw, isn't kerning with a space the same (optically) as line alignment, even if it happens inside the line? In both cases, we'll be kerning the glyph with an empty space.

Florian Pircher

Kerning to a space cannot be used, since someone might want to kern a glyph to a space without also implying optical bounds. In the following discussion, the lfbd/rfbd features are considered almost “unimplementable”:

https://github.com/MicrosoftDocs/typography-issues/issues/578

Which also leads to a dedicated table from the TrueType spec: opbd. This table might make more sense since these effects would probably not be applied as part of the general shaping process. The table also allows for top and bottom compensation, which is nice for vertical layout.

John Hudson

Btw, isn't kerning with a space the same (optically) as line alignment, even if it happens inside the line? In both cases, we'll be kerning the glyph with an empty space.

No, because kerning to the space needs to consider what might be on the other side of the space, so should be used sparingly and with moderate kerning values. Kerning is about tightening and loosening; optical alignment is more absolute.

Nick Shinn

I would also point out that there is no logical explanation for the ink traps of the letter N, in Yury’s posted image.

Clearly, ink traps are a bug in display size typography, but who cares?

Different fonts for text and display—now there’s an idea!

Mike Wenzloff

Jasper de Waard said:

Does anybody know which applications support lfbd and rtbd?

I believe Serif's Affinity applications do.

Peter Constable

Florian Pircher said:

Which also leads to a dedicated table from the TrueType spec: opbd. This table might make more sense since these effects would probably not be applied as part of the general shaping process. The table also allows for top and bottom compensation, which is nice for vertical layout.

It sounds like what's being suggested is a single, font-wide left optical bound value (and, presumably, a corresponding value for the right, and perhaps top/bottom) that paragraph layout implementations could apply to the layout of entire paragraphs. Rather than adding a new, separate table for a few metric values, I think it would make more sense to add values to a new version of the OS/2 table, which most implementations already use for default line metrics.

Thomas Phinney

Do font-wide values work for multi-script fonts? Perhaps we do not need different optical bound values for Latin vs Greek vs Cyrillic, but what if we have, say, Latin and Arabic? Cyrillic and Chinese?

John Hudson

I think it would make more sense to add values to a new version of the OS/2 table, which most implementations already use for default line metrics.

As Thomas points out, even if applied as single left and right optical bounds values—rather than glyph-specific values—these might need to differ for particular scripts. Since we already have a proposal—partially implement by Apple already—for script-specific linespacing metrics in a new BASE table version, this looks like something that could be added there in a similar data model.

k.l.

we already have a proposal [...] for script-specific linespacing metrics in a new BASE table version

Link?

John Hudson

I can’t find the documentation that Apple provided for their implementation (which only addresses script-specific metrics, not language-specific ones). I originally proposed the idea to the OT ad hoc working group a long time ago, and there seemed to be general agreement that it would be useful. but has been stalled since that group stopped actively collaborating after Summer 2019.

I raised it as an issue in the W3C Font & Text community group, which briefly looked like it might be a more open collaborative standardisation forum. But it looks like we’re now back in a phase of independent implementations of competing ideas, and post-facto standardisation.

Simon Cozens

John Hudson said:

 But it looks like we’re now back in a phase of independent implementations of competing ideas, and post-facto standardisation.

Another way to say the same thing is that we're back in a phase where developers want to make progress but are frustrated at Microsoft's iron grip on the format.

chegr

In 2018 the same problem was raised at Illustrator Uservoice forums by Valerii Mamedov:
https://illustrator.uservoice.com/forums/333657-illustrator-feature-requests/suggestions/33610747-add-an-option-for-trimming-side-bearings

I wrote a script for Illustrator which uses the same approach Yury and Ilya utilized for the Figma plugin — a user can define an uppercase and a lowercase symbols (H and h by default), which later are used to calculate a kerning values for each first glyph in a line.

It works pretty solid, giving an tiniest error sometimes which is still sufficient for most cases.
This is of course a workaround still. The Illustrator team know about this problem, and perhaps more attention can be brought to the problem if enough votes get raised. They made Font Height options and Glyph Snapping after all.

But sure, the problem in general is not limited with Illustrator only.

Peter Constable

Question on this topic today in StackOverflow:

html - Text in p tag not left aligned properly - Stack Overflow