[css-text][css-fonts] Optical bounds of a line

[fantasai]

@SashimiEthan forwarded a question about getting visual alignment at the start/end of the line see testcase and diagram:
:

Turns out there's an OpenType feature for this (at least, in horizontal text), which is expected to be on by default. Should we note this in the spec or something?

https://docs.microsoft.com/en-us/typography/opentype/spec/features_ko#tag-opbd

This feature should be active by default. It effectively changes the line length, so justification algorithms should account for this adjustment.

If we want control over it, I'd suggest adding to the font-kerning property: it's effectively kerning with respect to the start/end edge.

[svgeesus]

Agreeing in general that this needs to be a) allowed b) mentioned c) controllable.

However typographically, optical alignment is unrelated to kerning so putting it in there would be confusing. ( d see the argument, but think it is a weak analogy).

Rather, it is part of text alignment so should be a modifier on the effect of text-align, align-content and so on which align some part of the glyph (currently the left or right side bearing?) with some left or right geometric item like a content box.

[fantasai]

@svgeesus It definitely doesn't belong with the alignment properties. They're about how we align a thing within its container, not how we measure the thing we're aligning.

You're referring to this as "optical alignment" but really it's about using the optical “bounds” of the glyph: where is the line that, in a block of text of the same font/size, would optically coincide with the edge? This might not be considered "pairs kerning", but it is about kerning--about the glyph projecting beyond its allotted space.

(Also, I think true optical alignment would have to consider also the relative sizes of the actual text being aligned; I suspect optically left-aligning a “W” that's 3x the text above and below it would use different coordinates than if the text was all the same size.)

[chrisarmstrong]

Hi there, I asked the question on the Medium article, thanks so much for considering this!

My hacky solution to this has been to manually calculate the distance (in Ex units) between the Em box’s left edge and a straight-edged character (such as H or B), and create a font-offset variable. I then manually apply margin-left: $font-offset to any left-aligned text blocks. Because the offset is consistent for each font at a particular size, and ex units are proportionate to the font dimensions, it works. But it's nasty. Example here: https://codepen.io/chrisarmstrong/pen/eYZWqrw

Where the problem manifests itself most is when you have multiple text sizes, e.g. a heading, subhead and paragraph. If they're all using the same font you'd expect them to create a straight edge when aligned left or right, but currently they don't. In that sense, this feels like an alignment bug, though under the hood it may be a kerning-related calculation.

[svgeesus]

Hmm, I'm seeing a comment in email by @khaledhosny which is not showing up on the page here.

[svgeesus]

@khaledhosny wrote:

It should be noted that opdb feature is not implemented anywhere (and probably unimplementable without hacks) since OpenType shapers (that take care of applying font features) work on a much lower level than what is needed for this kind of features.
Also anything written in the OpenType feature registry should be taken with a big grain of salt since it is often outdated, confused, or contradicts actual implementations.

Apple also has opbd table (standalone font table not an OTL font feature), that might be more implementable (simple data structure, can be applied by applications after shaping without having to re0implenet considerable chunks of the OTL tables), but I don’t know if Core Text implements it, there are only two fonts that have it in an up to date macOS system: Apple Chancery and Hoefler Text.

See also harfbuzz/harfbuzz#1891

[Lorp]

Here’s a demo I made on the issue a few years ago, and referred to on the MPEG-OTSPEC list earlier this month. It seems reasonable to expect all of the H’s, both large and small, to be left-aligned by default.

https://www.axis-praxis.org/tests/sidebearings/test-20170316.html

Look at the third example, set in a special version of the Source Sans font with optically zeroed sidebearings and spaced with CSS letter-spacing.

My proposal was that fonts can be made with glyph sidebearings aligned to optical left and optical right bounds (just as glyphs are aligned to the font’s baseline and cap-height). In CSS terms it’s like removing horizontal padding. Then, spacing can be applied via one of:

• CSS letter-spacing
• the tracking feature in an app
• a variable spacing axis in the font

Back in 2013, Cameron Booth on his Transit Maps blog published a good tutorial on dealing with the issue in Illustrator:

• Tutorial: Working with Point Type Labels in Adobe Illustrator

you need to be aware that the text you type almost never aligns with the point that you’ve created. Because of the letter spacing that’s baked into each character, there’s a small – but noticeable – gap between the point and the adjacent character

BTW, making the above tests alerted me to be a bug or an underspecification, such that CSS letter-spacing is applied after every glyph including glyphs at the end of a line of justified text.