Hacker News Reader

Comment by xg15 | Hacker News Reader

> Don’t ask about the code which line-breaks partial ligatures though.

Wondered about this. All the circular dependencies sound like you could feasibly get some style/layout combinations that lead to self-contradictory situations.

E.g. consider a ligature that's wider than the characters' individual glyphs. If the ligature is at the end of the box, it could trigger a line break. But that line break would also break up the ligature and cause the characters to be rendered as individual glyphs, reducing their width - which would undo the line break. But without the line break, the ligature would reconnect, increase the width and restore the line break, etc etc...

View on HN

Blink's (Chromium) text layout engine works the following way.

1. Layout the entire paragraph of text as a single line.

2. If this doesn't fit into the available width, bisect to the nearest line-break opportunity which might fit.

3. Reshape the text up until this line-break opportunity.

4. If it fits great! If not goto 2.

This converges as it always steps backwards, and avoids the contradictory situations.

Harfbuzz also provides points along the section of text which is safe to reuse, so reshaping typically involes only a small portion of text at the end of the line, if any. https://github.com/harfbuzz/harfbuzz/issues/224

This approach is different to how many text layout engines approach this problem e.g. by adding "one word at a time" to the line, and checking at each stage if it fits.

> This approach is different to how many text layout engines approach this problem e.g. by adding "one word at a time" to the line, and checking at each stage if it fits.

Do you know why Chrome does it this way?

We found it was roughly on par performance wise for simple text (latin), and faster for more complex scripts (thai, hindi, etc). It also is more correct when there is kerning across spaces, hyphenation, etc.

For the word-by-word approach to be performant you need a cache for each word you encounter. The shape-by-paragraph approach we found was faster for cold-start (e.g. the first time you visit a webpage). But this is also more difficult to show in standard benchmarks as benchmarks typically reuse the same renderer process.

Reply on news.ycombinator.com