gfx/truetype.h
A TrueType and OpenType parser: glyph outlines out of a .ttf or an .otf, as ordinary Paths -- quadratic glyf outlines and cubic CFF ones alike.
#include <sonore/gfx/truetype.h>- 4types
- Guides: The native editor
On this page
Design notes
Why parse it here rather than use a library or the platform
Two alternatives were on the table and both cost more than they look.
Platform text -- DirectWrite, CoreText, Pango -- means three backends whose metrics disagree, so the same interface has different line breaks on different machines and I could never see two of the three. That is exactly the property the software rasteriser exists to avoid.
A third-party rasteriser (stb_truetype and friends) means a second rasteriser with its own antialiasing, sitting next to the one this SDK already has and has tested to a fifth of a pixel.
Parsing the outlines directly costs about five hundred lines and gives glyphs as Path objects, drawn by the SAME rasteriser as everything else. One antialiasing quality, one set of tests, identical output everywhere, and no dependency or licence to review.
What this does NOT do
No hinting, no OpenType layout (GSUB/GPOS), no bidi, no shaping. Those are what you need for Arabic, Devanagari or fine ligature control, and each is larger than everything here put together. What is covered is the text a plugin's interface is made of: a glyph per character, advance widths from hmtx, kerning from GPOS or the old kern table -- and a variable font moved along its axes (fvar, avar, gvar, HVAR).
A font this cannot read is REFUSED rather than half-drawn. A parser that guesses at a table it does not understand produces glyphs that are subtly the wrong shape, which nobody reports as a bug because it just looks bad.
Types 4
One axis a variable font moves along: weight ('wght'), width ('wdth'), slant ('slnt'), italic ('ital'), optical size ('opsz'), or one the designer named. Values are the font's own -- a weight of 300 to 700, a width of 75 to 100 per cent.
A layer of a colour glyph, from a font's COLR and CPAL tables (version 0, as Windows' Segoe UI Emoji has them): the outline of glyph, filled with this colour -- or, where foreground, with the colour the text is drawn in. A glyph's layers are drawn in order, the first at the bottom.
A colour glyph as a picture, from a font's sbix table (macOS's Apple Color Emoji) or its CBDT and CBLC (Linux's Noto Color Emoji): PNG bytes, read in place from the font, and where the picture goes -- its top-left corner from the glyph's origin on the baseline, x to the right and y DOWN, in pixels of the strike it was made for, ppem pixels to the em.
A parsed font file.
Holds the file bytes and reads out of them on demand. Glyph outlines are built when asked for, because a font has thousands and an interface uses eighty.