RenderText Overview

RenderText’s purpose is to prepare text for text shaping, shape the text using the Harfbuzz text shaping engine, and then draw the text onto the screen using the Skia library. RenderText also has support for cursors and selections. This class is the level of abstraction for the complex world of unicode. Chrome developers should rely on it or improve it instead of developing their own solutions.

RenderTextHarfbuzz is the implementation of RenderText. We used to have platform specific implementations but have since consolidated this into RenderTextHarfbuzz.

A RenderText object can be created in a View that wants to display text. The View can set properties on the RenderText object such as the text to be displayed, whether or not the text is obscured (such as the case with passwords), word wrap behavior etc.

RenderText::Draw starts the process of drawing the text onto the screen.

We then do the following before passing the results of these steps off to Skia.

1. Apply Additional Layout Attributes to the Text.
2. Itemization (also known as segmentation)
3. Text Shaping
4. Eliding
5. Multiline Text Layout

Apply Additional Layout Attributes to the Text:

• Before we itemize and shape the text, we may need to apply some additional layout attributes.
• This includes:
  • Obscuring the text for passwords
  • Applying styles
  • Handling control characters
  • Applying underlines
• Note that currently some parts of the code will still try to rewrite codepoints which is incorrect because text can only be broken up by graphemes.

Itemization (also known as segmentation):

• This involves breaking up the text into separate runs (TextRunHarfBuzz objects). Runs represent sections of text that we can shape with a single font.
• We use the ICU library’s bidirectional iterator to break up runs and then further break up the runs by script, special characters, and style boundaries.

Text Shaping:

• We choose the appropriate font to shape the runs with.
• Then go through the list of runs and try to shape each of the runs by creating Harfbuzz structures from the input run.
• We call into the Harfbuzz API to shape the text (hb_shape) and populate the output with the glyph data.
• If any runs still have missing glyphs, we add them back to the list of runs that still need to be shaped.
• For these remaining runs, we have fallback code to attempt to shape them again, but it is possible that some fail to be shaped.
• Since fallback occurs on a per-run basis, we then re-itemize the runs, accounting for missing glyphs, and restart the shaping stage. This ensures that the number of missing glyphs are minimized, as each glyph will then attempt to locate an appropriate font.

Eliding:

• If the text exceeds its constrained dimensions we will need to elide the text.
• We elide based on the elide behavior set on the RenderText object and whether the text is multiline.

Multiline Text Layout:

• If the text is not multiline we create a single line. If the text is multiline we break up the text into lines. (see HarfBuzzLineBreaker)
• Set the shaped text based on these lines.
• Skia will use the lines of the shaped text to draw the text onto the screen.