glacial citrus
I'm curious about the code that splits by unicode ranges and uses different fonts to render the different parts of the string. Where in the flow does that happen?
We're using Opentype.js in our web-based CAD app, and I'd like to have backup fonts to not show rectangles when a particular font doesn't support the language that people put into our template.
glacial citrus
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
Does this mean that it doesn't split the string on unicode ranges at the start, but just goes down the fallback list once it finds some unsupported characters?
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. Knowing “this range is covered by Noto Emoji” would make that process faster.
Interested in the code that does fallback font search.
woven cloak
Does this mean that it doesn't split the string on unicode ranges at the start, but just goes down the fallback list once it finds some unsupported characters?
I am relatively sure that this is the case. https://github.com/typst/typst/blob/main/crates/typst/src/text/font/book.rs may contain (some) of the code for it.
glacial citrus
Thanks for the pointer.
.filter(|(_, info)| info.coverage.contains(c as u32))
https://github.com/typst/typst/blob/c4c53ab52ead548427d66963585b9fa596e85308/crates/typst/src/text/font/book.rs#L108
I wonder how c as u32 works with multibyte characters / sequences.
fervent schooner
```
.filter(|(_, info)| info.coverage.contains(c as u32))
```
https://github.com...
All Unicode chars fit into 32-bit.
fervent schooner
I'm curious about the code that splits by unicode ranges and uses different font...
The way Typst does font fallback is inspired by Chromium. Basically, they found out that it's most reliable to just try and shape the text with the font and then do fallback when the shaper yields tofus glyphs instead of trying to guess upfront how you need to segment the text (which is error-prone because shaping is so complex.)
This is where it happens.
glacial citrus
All Unicode chars fit into 32-bit.
So text.chars() is different than I'm used to in JS. 🙈
fervent schooner
So `text.chars()` is different than I'm used to in JS. 🙈
Yeah, because JS uses UTF-16 and charCodeAt does direct indexing, you can get either a char from the Basic Multilingual Plane or you can get a Surrogate. The two in combination can encode things like emoji. Rust uses UTF-8, but chars() iterates over codepoints rather than bytes.