From 2e397463757e7e14a3a7a8fae7f5fb84aa7b3dc8 Mon Sep 17 00:00:00 2001 From: Adrian Cochrane Date: Sat, 18 Feb 2023 18:55:44 +1300 Subject: [PATCH] Blog text rendering details. --- .../2023-02-18-text-rendering-corrections.md | 30 +++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 _posts/2023-02-18-text-rendering-corrections.md diff --git a/_posts/2023-02-18-text-rendering-corrections.md b/_posts/2023-02-18-text-rendering-corrections.md new file mode 100644 index 0000000..b0ae60b --- /dev/null +++ b/_posts/2023-02-18-text-rendering-corrections.md @@ -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. -- 2.30.2