Quick note today after having gone back & fixed Typograffiti to work for more text than my demo.
The coordinates Harfbuzz gives us are not in pixels, so I found a working conversion factor to see my demo program working. Which on its own I find impressive how well I get things working without being able to see what I was doing!
But it turns out this conversion factor is specific to the font & to the font-size. So I needed to find the appropriate conversion factor. After a day’s worth of studying (I should have read FreeType’s documentation earlier) what I found works is in C notation:
f->size->metrics.x_ppem/f->units_per_em/2, f->size->metrics.y_ppem/f->units_per_em/2
(Where f is the FT_Face object)
That is Harfbuzz by default operates in terms of 2font-units (or is it 1 fontunit & I messed something up? I’ll investigate & correct this comment tomorrow).
Anyways this code proved much more resiliant!
Some letters raise further above the baseline, very few go under it. With this “baseline” being a straightline upon which each character’s “glyphs” sits. I assumed Harfbuzz would would’ve handled this issue itself, but when I see that it wasn’t I didn’t bother investigating how to fix it. Thankfully the first thing I attempted solved the problem: incorporating the f->glyph->metrics.horiBearingX & the corresponding y property into computing the glyph’s bounding box (alongside its size, the pen coordinate, & Harfbuzz positioning) made the sample text legible!
Incidentally the pen is kept on this baseline with the y bearing being high above it the top of the bounding box is drawn.
This is written in case anyone else working with FreeType & Harfbuzz finds this information useful.