3 ms·

> For monospace fonts, used by Warp for terminal input and output, glyph advance is a constant - a fixed amount of spacing is used between all pairs of glyphs.

> For monospace fonts, used by Warp for terminal input and output, glyph advance is a constant - a fixed amount of spacing is used between all pairs of glyphs. It's more complicated than that, too. (But just about every terminal I've ever used at one point or another has made that buggy assumption!) Emoji and wide CJK characters typically take two terminal cells. For example (and HN will corrupt the output of this command, as it will remove the emoji): » python3 -c 'print("1234567890\n\N{PILE OF POO}x\u4e09x")' 1234567890 x三x The second "x" should align under the 6. 4 glyphs, 6 cells. (I am a bit curious about the subpixel stuff. I've done font atlases, but IME Harfbuzz — the shaping engine I've used — only seems to emit integral advances? (Although I'm now wanting to re-test that assumption.) And I'm not entirely sure I know how to ask FreeType to render a glyph with an offset, either.)

vorporeal 4y ago
Good call-out - definitely a bit of a simplification there. We account for this in our terminal grid by allocating an empty cell following any double-width glyphs (e.g.: emoji and wide chars, as you mentioned). Tried out your example in Warp, and the alignment is as you described: https://i.ibb.co/Jcwcnwn/image.png https://i.ibb.co/Jcwcnwn/image.png Core Text supports rasterizing at sub-pixel offsets (though some configuration of the graphics context is necessary to do so properly) by applying a transformation to the graphics context before the rasterization call. I'll definitely have to figure out the FreeType angle when we start working on Linux support; if I uncover anything (and remember this comment thread), I'll report back with my findings. :)
kevin_thibedeau 4y ago
Unfortunately many of the grandfathered symbols in the emoji block have ambiguous width and there is little recourse for applications to determine the terminal display width of any particular codepoint. Gnome VTE gives you a setting to force them one way or another but that can interact badly with fonts that expect a different width.
- deathanatos 4y ago
  I think this is for the codepoints that have both an emoji form and a non-emoji form? (And yeah, that's admittedly confusing for the app.) I think Unicode does specify a way to force those codepoints to either the emoji form or the non-emoji form, but there is still an encoding that is ambiguous by spec, I think. E.g., the "TM" symbol falls into this; on macOS if you open the character selector and search "trade", you will get both variants. Edit: this: https://unicode.org/reports/tr51/#Presentation_Style https://unicode.org/reports/tr51/#Presentation_Style

vorporeal 4y ago

Good call-out - definitely a bit of a simplification there. We account for this in our terminal grid by allocating an empty cell following any double-width glyphs (e.g.: emoji and wide chars, as you mentioned). Tried out your example in Warp, and the alignment is as you described: https://i.ibb.co/Jcwcnwn/image.png https://i.ibb.co/Jcwcnwn/image.png Core Text supports rasterizing at sub-pixel offsets (though some configuration of the graphics context is necessary to do so properly) by applying a transformation to the graphics context before the rasterization call. I'll definitely have to figure out the FreeType angle when we start working on Linux support; if I uncover anything (and remember this comment thread), I'll report back with my findings. :)

kevin_thibedeau 4y ago

Unfortunately many of the grandfathered symbols in the emoji block have ambiguous width and there is little recourse for applications to determine the terminal display width of any particular codepoint. Gnome VTE gives you a setting to force them one way or another but that can interact badly with fonts that expect a different width.

deathanatos 4y ago
I think this is for the codepoints that have both an emoji form and a non-emoji form? (And yeah, that's admittedly confusing for the app.) I think Unicode does specify a way to force those codepoints to either the emoji form or the non-emoji form, but there is still an encoding that is ambiguous by spec, I think. E.g., the "TM" symbol falls into this; on macOS if you open the character selector and search "trade", you will get both variants. Edit: this: https://unicode.org/reports/tr51/#Presentation_Style https://unicode.org/reports/tr51/#Presentation_Style