<div dir="ltr"><div dir="ltr">On Sun, Sep 15, 2024 at 5:48 AM Akira TAGOH <<a href="mailto:akira@tagoh.org">akira@tagoh.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
(Replying here to follow up a concern)<br>
<br>
On Sat, Sep 7, 2024 at 2:36 AM Werner LEMBERG <<a href="mailto:wl@gnu.org" target="_blank">wl@gnu.org</a>> wrote:<br>
><br>
><br>
> >> I am curious to hear your thoughts on accepting contributions to<br>
> >> FontConfig that provide an alternative indexing code path and build<br>
> >> configuration that does not require FreeType, but instead uses the<br>
> >> Rust-based Fontations libraries [1] developed by Google Fonts.<br>
<br>
That sounds good to me.<br>
<br>
> > I believe this is an important and noble project to consider<br>
> > upstream.<br>
><br>
> I agree.  Using two different font backends could help improve<br>
> FontConfig by finding subtle bugs.  It might even help FreeType – and<br>
> Fontations – fixing bugs, too.<br>
><br>
> However, to allow such kind of testing I strongly suggest that<br>
> Fontation and FreeType can coexist in FontConfig, similar to HarfBuzz<br>
> that also allows multiple backends AFAIK.<br>
<br>
To do that, it needs to make sure that data in a cache is compatible<br>
no matter what backends are used to generate. Otherwise we may want to<br>
have some identifier in a cache filename to avoid breakage.</blockquote><div><br></div><div>I think the goal is to produce the same patterns, and the caching subsystem is not touched at all. The exception will be bitmap / Type1 / other non-SFNT fonts... </div></div></div>