Fallback fonts for certain unicode ranges

[forresto]

Is there a good strategy to accept any string of text, and if the chosen font doesn't have the requested characters, load a fallback font? Our fallbacks will be Noto fonts. unicode-range is a hint in the CSS that Google Fonts serves. But I haven't seen an example of code that splits an input string based on unicode ranges and maps to fallback font files.

[Connum]

You could use stringToGlyphs() to see which chars end up as the .undefined glyph and then add them to the the font using the path from the fallback font, before rendering the text using .draw()

[forresto]

When processing text, Typst tries all specified font families in order until it finds a font that has the necessary glyphs. In the example below, the font Inria Serif is preferred, but since it does not contain Arabic glyphs, the arabic text uses Noto Sans Arabic instead.

https://typst.app/docs/reference/text/text/#parameters-font

From another project, seems to mean that it doesn't know the supported ranges at the start, but just tries the fonts sequentially.

The disadvantage in a web context is that we would need to keep loading the fonts in the fallback list until we find one that supports the characters.

[forresto]

Here's where the magic happens (finding a font that supports the character) in Typst. https://github.com/typst/typst/blob/c4c53ab52ead548427d66963585b9fa596e85308/crates/typst/src/text/font/book.rs#L108

[forresto]

Diving into Opentype.js' forEachGlyph, I'm not sure how to take a run of .notdef glyphs and map them back to the original string. There isn't an index back to the original string.

[Connum]

That's true, you'd have to call it on the fallback font as well from the start, but of course there's no guarantee that indices of both results would be corresponding to each other, e.g. if one font supports ligatures that the other one doesn't.

This is tricky. So far I don't see a simple solution without having to add this as a library feature specifically.

[forresto]

What about returning the original string indeces for each glyph with stringToGlyphs and leaving the fallback rendering to userland?
A little tricky with the bidi replacements, but it seems like generally useful info.