<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - please do not register WOFF(2) fonts" href="https://bugs.freedesktop.org/show_bug.cgi?id=101270#c16">Comment # 16</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - please do not register WOFF(2) fonts" href="https://bugs.freedesktop.org/show_bug.cgi?id=101270">bug 101270</a> from <a class="email" href="mailto:keithp@keithp.com" title="Keith Packard <keithp@keithp.com>"> Keith Packard</a> <pre>(In reply to Behdad Esfahbod from <a href="show_bug.cgi?id=101270#c15">comment #15</a>) > I'm fine with adding a FC_CONTAINER or another way to differentiate WOFF / > WOFF2 / SFNT. But I like to thing through it a bit more before rushing to > implementing. In the case I saw, the font package installed *both* ttf and woff fonts. The intent being that the woff fonts would be served by the web server and the ttf fonts used by local applications. In this case, preferring the ttf format to the woff format would make applications not using freetype (and it's built-in woff support) to end up using the ttf font. It's slightly annoying that applications don't just support woff fonts natively; who knows, there may be fonts distributed in only that format. Hiding woff fonts from all fontconfig-using applications is clearly a bad idea. Telling applications about the container format so they can skip things they don't support seems like the best we can do. For font packages installing both ttf and woff files, it would probably be better if they found a different place to install the woff fonts to avoid this problem, but I'm not sure where that would be -- woff fonts that aren't duplicates clearly need to be in /usr/share/fonts so that applications can use them, after all.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>