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.
2
1
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
safari!
1
1
This is how you do it! 🙌
1
Ah yeah, seems like the same thing. The style change breaks the glyph substitution for myanmar, which you can read more about here here:
1
1
Although in linking that doc, Safari is probably using Core Text – which *might* use an alternate standard for shaping Myanmar. Can't remember the specifics though. Regardless, the relevant bit is that scripts like this do glyph substitutions, and Safari is breaking those.
In this case you are seeing the “dotted-circle placeholder” where the dependent vowels and combining marks are being rendered in isolation (search for those keywords in the opentype-shaping docs I linked for more information). This seems understandable to me!
Yeah. My colleagues had to implement shaping for scripts like it in Allsorts (see github.com/yeslogic/allso) and their brains hurt as well afterwards. Not sure if we do Myanmar yet, however.
2
Show replies