Cookie monster!

xmoji/src/bin/xmoji/svghooks.c at master · Zirias/xmoji

Contribute to Zirias/xmoji development by creating an account on GitHub.

fcft: use FT_Set_Char_Size() instead of FT_Set_Pixel_Sizes()

`FT_Set_Char_Size()` is more fine-grained, and lets us set the size more precisely, since it allows a fractional point size. Since the input size is already in pixels, use a DPI of 72 (meaning, a pixel has the same size as a point).

harfbuzz 5.0.0 and higher breaks terminus font · Issue #3755 · harfbuzz/harfbuzz

On Arch Linux and other distros, upgrading to harfbuzz 5.0.0 or higher (in testing repository on arch) breaks the terminus font (otb version) in foot terminal. Before After

fcft

A simple library for font loading and glyph rasterization using FontConfig, FreeType and pixman.

Support for SVG in Opentype fonts

Because support has recently been added to FreeType2 for the OpenType SVG specification, it would be a a nice addition to support this capability. This includes the color SVG support for glyphs. I am not sure how large of a lift this would be, but would be a nice addition for supporting SVG icon fonts in `yambar` See: https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/122 https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/68

Take emoji default presentation into account, mixed LTR/RTL

Emoji's have a "default presentation", that can either be "text" or "emoji". This is something we have completely ignored up until now; we've simply been searching the fallback list "as usual", using the first font in the list that has glyphs for the searched-for codepoint. With this patch, we now ignore emoji fonts when looking for an **emoji** codepoint whose default presentation is "text", and we ignore non-emoji fonts when looking for a codepoint whose default presentation is "emoji". On a side not: if one is to generalize, the emojis that have "text" as their default presentation are the same ones that `wcwidth()` returns 1 for. Some images: the text used here is `"$(echo -e '\u263a xyz \u263a\ufe0e abc \u263a\ufe0f') | اَلْعَرَبِيَّةُ | xyz | ויקיפדיה"` I.e. `WHITE SMILING FACE` (U+263a) using its default presentation (text), followed by the same emoji again, first with an explicit text presentation selector, and then with an emoji presentation selector. Thus, on each row we expect **two** text-emojis, and **one** graphical emoji. This is then followed by "arabic", "xyz", and "hebrew". There are three rows in the images: the first row is rendered one codepoint at a time, using `fcft_glyph_rasterize()`. The second row is rendered one **grapheme** at a time, using `fcft_grapheme_rasterize()`. The last row is rendered as a single run, using `fcft_text_run_rasterize()`. ## Before ### Limited primary font (non-ascii glyphs from fallback font):  Note how the emojis are wrong: the primary font doesn't have this codepoint, and we're falling back to a colored emoji font. Only `fcft_grapheme_rasterize()` pays any attention to presentation selectors, and only explicit ones. We're _almost_ rendering the arabic and hebrew correctly; the only issue is that the last emoji should come **before** the arabic text. ### Large/full primary font (primary font has most glyphs):  Emojis may appear to look better, but that's just because this primary font has the `WHITE SMILING FACE` emoji. Again, `fcft_grapheme_rasterize()` handles explicit presentation selectors, and thus the last emoji in the middle row is correct. The last row is pretty bad; since this primary font has **all** glyphs, it is shaped in a single go. This is the reason both the arabic and hebrew is rendered "reversed". ## After ### Limited primary font (non-ascii glyphs from fallback font):  ### Large/full primary font (primary font has most glyphs):  Both images are rendered as correct as one can expect. The ascii/latin characters look different in the two images since the primary font is different. But LTR/RTL is all correct, emojis are all correct (the last emoji in the first row is incorrect, but this is to be expected with `fcft_glyph_rasterize()`, since it only takes a single codepoint). ## Real usage Here's a real-world example; two yambar instances, top one using fcft from master, bottom one using fcft from this PR:  The three emojis are using the default presentation, explicit text presentation, and emoji presentation, respectively.