Text Rendering Hates You, a random collection of weird problems you need to deal with when rendering text: https://gankra.github.io/blah/text-hates-you/ …
-
Show this thread
-
Replying to @Gankra_
FWIW Chrome 79-dev Linux renders partial ligatures the same way Firefox does. As the "someone" accused of being enthusiastic here: you need some kind of partial ligature rendering to render partially-selected ligatures, which I still maintain is worth doing.
3 replies 0 retweets 14 likes -
Replying to @rocallahan @Gankra_
"...partially-selected ligatures..." That makes sense. When it makes sense. Presumably you don't do it for partially selected emoji, but presumably there could be "ligatures" that are more emoji-like semantically and similarly wouldn't make sense, but the browser can't know?
1 reply 0 retweets 0 likes -
Replying to @nothings @rocallahan
Emoji are weird here because they only(?) ligaturize with zwj glue and are a single EGC, so the user has to explicitly request the ligature, and that's ~always with a keyboard/editor that does it automatically. So it's really hard to get a mid-emoji style change in your markup.
2 replies 0 retweets 2 likes -
Replying to @Gankra_ @rocallahan
Yeah, I don't mean the style change, I just mean the partial selection. And my point isn't about emoji but about ligatures... presumably you COULD have ligatures which don't have a simple left-right or top-down substructuring, much as emoji don't.
1 reply 0 retweets 0 likes -
Like, ideally ligature partial selection OUGHT to have been handled by info in the font from day one, but I guess truetype was originally just for printers and not screens, and then when it first hit screens nobody used ligatures. So the horse was out of the barn.
2 replies 0 retweets 1 like -
Replying to @nothings @rocallahan
Yeah we definitely mess it up in a few places. It would be good if fonts or unicode helped us make better decisions, but I think the benefits currently outweigh the problems. https://bugzilla.mozilla.org/show_bug.cgi?id=479829 …pic.twitter.com/aLg6WW1oEE
2 replies 0 retweets 2 likes -
That bug is fixable by reshaping to avoid ligatures crossing line boundaries. Tricky to do though. Selection, color styling, etc, can't be fixed that way, because they can't change layout.
1 reply 0 retweets 0 likes -
I guess what you really want is a model where each glyph is associated with a single character, so e.g. an ff ligature is drawn as two glyphs that fit together. I don't know if that's already expressible in OpenType.
2 replies 0 retweets 0 likes -
TrueType/OpenType have the notion of compound glyphs that are composed of stacks of other glyphs with affine transforms. But I think every renderer just macro-expands such glyphs in place right now instead of preserving that info for use by consumers.
1 reply 0 retweets 0 likes
In theory one could allow selecting e.g. individual jamo in Hangul inside a single glyph by looking at the compound glyph structure.
-
-
Replying to @pcwalton @rocallahan and
Also, compound glyphs are represented by glyph IDs, not cmap entries, so you’d have to reverse-index the cmap in order to work out that, say, the individual subglyphs that make up the ff glyph happen to represent the character f. Doable but feels hacky.
1 reply 0 retweets 0 likes -
The subglyphs wouldn't be normal fs, wouldn't they be f-like shapes that aren't in the cmap? I think you'd instead introduce a convention that if there are exactly n subglyphs for a ligature representing n characters, they're in the same order.
1 reply 0 retweets 0 likes - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.