fun bug in chrome: codepen.io/jsscclr/pen/oN second character of ligature has same styles applied as whatever the first character has, despite being in a different dom node. can address by turning off ligatures
Conversation
firefox approach for comparison
2
I believe this was mentioned first in this post: robert.ocallahan.org/2006/10/partia I'm not sure if it relies on the ligature caret positions: docs.microsoft.com/en-us/typograp or if it still behaves as mentioned in the above post.
1
1
1
This seems like the spot where the partial ligatures are drawn: searchfox.org/mozilla-centra. It is then called here: searchfox.org/mozilla-centra
My code comprehension is pretty bad (especially with C++), but it doesn't seem to be using the caret positions.
At any rate, while I think Firefox's approach is kind of cute, my boss has kind of convinced me that a better solution is to force a ligature break when there's is a change to the inline style. So both Chrome and Firefox are probably doing it wrong. 😅
2
1
text rendering: no one's doing it correctly
1
Show replies
Replying to
amazing, I was just looking for this :P codepen.io/jsscclr/pen/OJ will have to find the chromium equivalent - this is ff vs chrome, since you linking to the ligature caret list table made me realise _surely_ this problem would be encountered heaps in other languages!
1
Yeah when you combine it with composite glyphs (vs. the ffi ligature which is comprised of a single glyph) things would get strannnge. I'm pretty sure you'd get more weirdness with Indic scripts, for example.
2
Show replies