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/1007645801320386272Of 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?
Comments
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.
It does seem strange that this old physical limitation has not been addressed in digital type in some way.
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.
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.
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.
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.
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.
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?
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.
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.
Clearly, ink traps are a bug in display size typography, but who cares?
Different fonts for text and display—now there’s an idea!
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.
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.
html - Text in p tag not left aligned properly - Stack Overflow