Specifically, any new numbers I type show up using "standard" glyphs no matter how long the strings are. The underlines appear all at once, the digit grouping pops all the digits into place, bold glyphs get swapped in etc, only once I hit Enter.
And even then it's not consistent: typing a bunch of text into the bolding demo, nothing was emboldened even after hitting Enter, so I tried going back and inserting a newline in the middle of the string, which gave me a boldened top line and a plain bottom one, then when I backspaced the newline out I had a half-bold line and a half-plain one. Yay.
I get the feeling I'm tripping over some well-ossified glyph cache logic somewhere, and no wonder too; chances are the current status quo has produced "correct" results for decades because nobody thought to take advantage of this cool trick :D
The "good" news is that it should be reasonably straightforward to statically analyse fonts' OpenType tables to identify shenanigans like these and disable whatever optimizations are preventing glyphs from being fully round-tripped through (presumably) the shaping/positioning/glyph selection pipeline. Whoever now gets to do that won't be too impressed though.
This is with Chrome Dev 99.0.4818.0 on Linux. Can anyone using macOS or Windows comment on whether this happens elsewhere?
Specifically, any new numbers I type show up using "standard" glyphs no matter how long the strings are. The underlines appear all at once, the digit grouping pops all the digits into place, bold glyphs get swapped in etc, only once I hit Enter.
And even then it's not consistent: typing a bunch of text into the bolding demo, nothing was emboldened even after hitting Enter, so I tried going back and inserting a newline in the middle of the string, which gave me a boldened top line and a plain bottom one, then when I backspaced the newline out I had a half-bold line and a half-plain one. Yay.
I get the feeling I'm tripping over some well-ossified glyph cache logic somewhere, and no wonder too; chances are the current status quo has produced "correct" results for decades because nobody thought to take advantage of this cool trick :D
The "good" news is that it should be reasonably straightforward to statically analyse fonts' OpenType tables to identify shenanigans like these and disable whatever optimizations are preventing glyphs from being fully round-tripped through (presumably) the shaping/positioning/glyph selection pipeline. Whoever now gets to do that won't be too impressed though.
This is with Chrome Dev 99.0.4818.0 on Linux. Can anyone using macOS or Windows comment on whether this happens elsewhere?