Hi Akira, Thank you for your feedback. On Sun, Sep 15, 2024 at 12:48 PM Akira TAGOH <akira@xxxxxxxxx> wrote: > > >> I am curious to hear your thoughts on accepting contributions to > > >> FontConfig that provide an alternative indexing code path and build > > >> configuration that does not require FreeType, but instead uses the > > >> Rust-based Fontations libraries [1] developed by Google Fonts. > > That sounds good to me. Great, I am happy to hear about your positive stance towards such contributions. I will work on the Fontations functions in parallel to my work on shipping Fontations in Chromium and completing the proposed change will take a bit of time, but if you're ready to have the existing bits as experimental code in the main branch, I can polish the existing code (as shown in the demo section of my original mail) and break it into reviewable PRs, behind the default-off buildflag. The changes contain an extra CI configuration to build them as well, so that breakage is avoided. > > However, to allow such kind of testing I strongly suggest that > > Fontation and FreeType can coexist in FontConfig, similar to HarfBuzz > > that also allows multiple backends AFAIK. > > To do that, it needs to make sure that data in a cache is compatible > no matter what backends are used to generate. Otherwise we may want to > have some identifier in a cache filename to avoid breakage. Yes, I agree with Behdad: I will try to produce patterns that match FreeType for font formats supported by Fontations, which are SFNT-based formats, OpenType/TrueType. Bitmaps fonts such as SBIX, CBDT/CBLC are supported. There's limited EBDT/EBLC support in Fontations - I can't say yet if there are metadata mismatches between FreeType and Fontations for those. I assume that any cache mismatch would mainly (only?) be a problem if in testing we would dynamically switch between backends. Dominik
