Implement fallback font support to HarfBuzz sample #635
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds support for fallback fonts to the HarfBuzz text shaping sample. Resolves #634.
To implement this, I had to keep track of the original character codepoint alongside the glyph bitmaps (since the glyph index is always zero for unsupported glyphs, this is how they are able to be disambiguated). Each font now has a lookup table for fallback glyphs that maps each unsupported character to their respective bitmap, as well as functions to append and retrieve glyphs from fallback fonts.
For the font layers, the logic remained mostly the same. When generating a texture, they now iterate through both the regular and fallback glyphs of a font. The rectangle ID is now represented as a bit-shifted combination of the glyph index and character codepoint (using sixty-four bits). I found this to be the most elegant solution that supports mapping multiple glyph indices to character codepoints (and vice versa), and it only needs one texture layout. However, it did require me to copy all of the texture layout files to the sample just to change the type of the rectangle ID from a regular integer to a
uint64_t
. This won't really be an issue when integrating this into RmlUi proper, since the texture layout files can just be edited in situ.