Create hb-font-t out of multiple font faces?

[Mrazator]

Is it anyhow possible to load multiple hb-face-t font faces into a single hb-font-t font object, so that it can be subsequently passed into hb-shape for shaping?

Why am I asking that in the browser we have hundreds of registered woff2 font faces, while they describe just a couple of fonts (due to font splitting). In theory, we could detect which font faces are relevant and convert just those into ttf/otf, but it seems that hb-shape accepts only a single font, which is created out of a single (font) face.

I guess there might be workarounds by merging fonts on the fly or recursively performing shaping until we go through all font faces, but both seem hacky and too expensive to perform on the client side.

[behdad]

HarfBuzz only shapes with one font at a time. What you are describing is the process of font selection and font fallback, and HarfBuzz currently doesn't get involved in that.

[chearon]

I have used the hb_face_builder API to modify fonts in-memory. You can retrieve tables from existing fonts via hb_face_reference_table. Tables are binary blobs, though, you'll have to parse and merge them yourself, which will be a bit of work, and these APIs are not exposed by harfbuzzjs right now.

I've gotten great performance doing font fallback with Harfbuzz in the browser, and I wouldn't call it hacky! Especially if you order the fallback list by support for the given text run. I believe browsers do normal fallback when you have multiple subsetted unicode-range fonts under one font-family.

[Mrazator]

I have used the hb_face_builder API to modify fonts in-memory. You can retrieve tables from existing fonts via hb_face_reference_table. Tables are binary blobs, though, you'll have to parse and merge them yourself, which will be a bit of work, and these APIs are not exposed by harfbuzzjs right now.

Thanks, might try it at some point, though the merging of fonts (especially some advanced tables including kerning / ligarues) would IMO need to be pre-computed and cached in our case (especially when it's coupled with woff2 decoding). And pre-computation means pre-fetching all the font faces, which we probably can't afford right now, especially for large CJK fonts.

I've gotten great performance doing font fallback with Harfbuzz in the browser, and I wouldn't call it hacky! Especially if you order the fallback list by support for the given text run.

By fallback, do you mean not merging the font faces into one font, but splitting the text based on the unicode ranges per font face and shaping each text chunk separately? I guess that might end up being even better, though curious what to do with ligatures which would "subsitute" characters in two separate font faces (or similarly kerning pairs). In this case it might mean, that the font faces are actually incorrectly split, but aren't there some similar edge cases for which this does not apply?

[chearon]

By fallback, do you mean not merging the font faces into one font, but splitting the text based on the unicode ranges per font face and shaping each text chunk separately?

I'm pretty sure that would work well. What I did is based on what I pieced together that "real" text layout engines do, which starts with creating segments whenever the script property changes (and a lot else). Each unique (segment, style) pair gets its own fallback list which is ordered so that the fonts that support the script (and language) in the segment are first. Then you walk the fallback list for the segment until it is totally shaped. At each iteration any ranges that have missing glyphs will be processed next iteration, and the ranges can't break unicode clusters (code).

what to do with ligatures which would "subsitute" characters in two separate font faces (or similarly kerning pairs). In this case it might mean, that the font faces are actually incorrectly split, but aren't there some similar edge cases for which this does not apply?

I don't think that will be a real problem since if a font has kerning or ligatures for two characters, it should cover them in unicode-range and have glyphs for them. You wouldn't need to split inside to pick a different font. If it had a bad unicode-range and you were using unicode-range to determine where you should reshape, then yeah, you'd break kerning there and not get a ligature.

[behdad]

Merging fonts should never be considered in such scenarios if you ask me. A font split in two has already broken any ligature, kerning, or other interactions across the charactersets.

Good reading: https://raphlinus.github.io/text/2020/10/26/text-layout.html