fontdb is unmaintained #862

Activity

1. LaurenzV commented on Dec 17, 2024

   

   LaurenzV

   on Dec 17, 2024

   Collaborator

   More actions

   I believe the plan is to replace the dependency with fontique (https://github.com/linebender/parley/tree/main/fontique) at some point.
2. si14 commented on Dec 17, 2024

   

   si14

   on Dec 17, 2024

   Author

   More actions

   Thank you! If I understand the API correctly, the original issue RazrFalcon/fontdb#76 would be resolved by matching the result of fontique's Collection::register_fonts. However, I believe that this issue is still relevant since the migration hasn't happened yet, or should I close it?
3. LaurenzV commented on Dec 17, 2024

   

   LaurenzV

   on Dec 17, 2024

   Last edited by LaurenzV

   Collaborator

   More actions

   Not sure, will have to wait for someone more knowledgeable to chime in, but my understanding was that there isn't much interest in taking over fontdb as well.
4. RazrFalcon commented on Dec 17, 2024

   

   RazrFalcon

   on Dec 17, 2024

   Collaborator

   More actions

   fontdb is abandoned and fontique isn't finished.
5. ZhaoZuohong commented on Oct 15, 2026

   

   ZhaoZuohong

   on Oct 15, 2026

   Last edited by ZhaoZuohong

   More actions

   Following up on @LaurenzV's note that the plan is to replace fontdb with fontique. I see fontdb got a maintenance release (0.24) in July. I have a concrete case where the current system fallback picks the wrong font, and I'd like to know which direction you'd accept before writing code.

   Problem

   When no font in the declared font-family list covers a character, FontResolver::default_fallback_selector returns the first face in fontdb.faces() that has the glyph. That order is just read_dir order. On Linux, fontdb reads fonts.conf only for directories and generic aliases, so fontconfig's actual matching (FcFontSort, lang) never runs.

   Concretely, on a Linux machine with the Noto CJK fonts plus some user-installed CJK fonts in ~/.local/share/fonts:

   • fc-match -s Inter puts Noto Sans CJK SC first among CJK fonts;
   • usvg falls back to FZFangSong-Z02, a user-installed font that happens to be the first face in fontdb's load order covering the characters;
   • even with only Noto CJK installed, the first .ttc face is JP, so Simplified Chinese text gets Japanese glyph forms. Neither xml:lang nor the script plays any part.

   (#1036 fixes the declared-list part. This issue is about what happens after that list is exhausted, for example with font-family="sans-serif".)

   Possible interim step

   FallbackSelectionFn already allows adding fonts to the database. A fontique-backed select_fallback could:

   1. ask fontique for the system fallback family for the character's script (and lang, when known); on Linux this goes through FcFontSort with FC_LANG;
   2. load the chosen face into fontdb via Arc::make_mut;
   3. return its ID.

   This would ship behind an opt-in cargo feature (or as an example or a separate crate if you'd rather keep it out of usvg). It would also be a small, reviewable first step toward the full migration.

   Questions

   • Is the fontique migration still the plan now that fontdb is back in maintenance? Is fontique ready to be used this way, or is there a better entry point today?
   • Would you accept this as an optional feature in usvg, or should it live outside the repo until the full migration?
   • Is anyone already working on the migration, so we can help rather than duplicate effort?

   Disclosure: I used an AI assistant to help investigate. I verified the observations above on my machine.