@@ 0,0 1,30 @@
+---
+layout: post
+title: Text Rendering Corrections
+author: Adrian Cochrane
+date: 2023-02-18 18:55:01+1300
+---
+
+Quick note today after having gone back & fixed Typograffiti to work for more text than my demo.
+
+## Font Sizes
+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](https://freetype.org/freetype2/docs/glyphs/index.html) 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!
+
+## Baselines
+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.