zlacker

>>Harvey+(OP)
Anyone got any information on how the text rendering bug actually works (not just hand-waving it away as "oh it's UTF-8")?

I can see that the file alternates between segments of:

- Repetitions of the glyph "t̴́̍̒", which is a lowercase t with a combining tilde overlay, an acute accent, a vertical line above, and a turned comma above

- Random-looking ASCII characters with lots of apostrophes (spelled as ' in the HTML)

- Short sequences of spaces, non-breaking spaces, and zero-width joiners

- Occasional emoji

The "t̴́̍̒"s manage to slow down my terminal and glitch its rendering a bit. Is it that they're unexpectedly tall? But we've had zalgo-text for a while and it hasn't actually crashed devices.

>>rspeer+fy
Okay, I have at least a guess about the type of thing that's going on, after seeing what it did to Firefox (which it at least didn't crash).

Various GUI elements such as title bars, tooltips, and thumbnails of links to Web pages, will try to fit the text they're given in a certain amount of space. If the text is too wide, it'll show some amount of text followed by "...". (I wonder if they're prepared for the text to be too tall.)

I saw Firefox rendering the long sequence of t̴́̍̒ characters in the mailto: link. It was being kerned in a way that made it nearly a solid black smear of pixels.

My guess is that apps are trying to determine how much of this text to show to fit within a certain width (and height?), and this text messes with a kerning algorithm in a way that makes it computationally very difficult to decide. I still don't know what's going on with the rest of the text, and why it can read 20 MB of text without making a final decision.