Bug 101270

Please note that this already causes issues further downstream, e.g.
"XeTeX chokes if fontconfig returns a WOFF file to them"
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861938

Also FontConfig do not report WOFF as the font format and instead reports the underlying format inside the WOFF container, which means applications can’t even avoid WOFF fonts if they wanted to:

$ fc-query -f "%{fontformat}\n" amiri-regular.woff
TrueType

$ fc-query -f "%{fontformat}\n" Mada-Regular.woff 
CFF

The name of the font format and most of properties in cache is coming from freetype.

Looking at the attached config, is WOFF fonts supposed to be put under /usr/share/fonts/woff? is it documented somewhere such as FHS? if it is the distro-specific rule, it should goes there.

(In reply to Akira TAGOH from comment #3)
> The name of the font format and most of properties in cache is coming from
> freetype.

That makes sense for FreeType since the fact that the font is packaged in a WOFF container is transparent to its users, but not all FontConfig users are using FreeType. But I agree, this is really a Debian misconfiguration issue.

(In reply to Akira TAGOH from comment #4)
> Looking at the attached config, is WOFF fonts supposed to be put under
> /usr/share/fonts/woff? is it documented somewhere such as FHS? if it is the
> distro-specific rule, it should goes there.

It's a misconception. On the one hand, fonts are supposed to be installed into /usr/share/fonts; on the other hand, fonts in WOFF format are not supposed to get registered by fontconfig or in fact any other application at all.

Please consider the config snippet as a mere example. It might make sense to rely on the file name extension and match the reject against <glob>*.woff*</glob> here.

Or will <glob>*.[wW][oO][fF][fF]*</glob> work?

So, what are we going to do about this issue?

have you tested applications supporting WOFF like the web browsers etc? most of them uses fontconfig and I don't know if this change affects behaviors on them. if it works fine, I'll update config in git.

I'm strongly against this kind of changes.

(In reply to Fabian Greffrath from comment #0)
> Created attachment 131636 [details]
> We don't register WOFF(2) fonts with fontconfig because of the W3C spec
> 
> Forwarded from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863835
> 
> Dear fontconfig devs,
> 
> currently, fontconfig registers all fonts installed into the
> /usr/share/fonts

Only if it is configured so.

> directory hierarchy. This may, however, contain fonts
> that are not meant to be exposed to general applications

Then either the fonts should not be there, or fontconfig should be configured to not look there.

> and are only there to adhere to the FHS specs.

That's complete non-sense.  If they are not for general use, they should not be in /usr/share/fonts.  I don't care what the exact word of FHS says, but since it's not legally binding, IMO packages should deviate from it when it makes sense.  If Debian takes a strict approach to non-sensical requirements of FHS, it's Debian's problem, not fontconfig's.


> One example are fonts in the WOFF(2) file formats. From the official
> W3C WOFF specs (https://www.w3.org/TR/WOFF/):
> 
> "2. General Requirements
> 
> The primary purpose of the WOFF format is to package fonts linked to
> Web documents by means of CSS @font-face rules. User agents supporting
> the WOFF file format for linked fonts must respect the requirements of
> the CSS3 Fonts specification ([CSS3-Fonts] Section 4.1: The @font-face
> rule). In particular, such linked fonts are only available to the
> documents that reference them; they MUST NOT be made available to
> other applications or documents on the user's system.
> 
> NOTE: the WOFF format is intended for use with @font-face to provide
> fonts linked to specific Web documents. Therefore, WOFF files must not
> be treated as an installable font format in desktop operating systems
> or similar environments. The WOFF-packaged data will typically be
> decoded to sfnt format for use by existing font-rendering APIs that
> expect OpenType font data, but such decoded font must not be exposed
> to other documents or applications."

We are not legally bound by the WOFF specification either.  WOFF was written that way to appease to font foundries to convince them to release their fonts on the web.  It's stupid to think that such enforcement reduces font piracy.


> So, please refrain from registering fonts in WOFF(2) formats with
> fontconfig. This can be achieved by installing the attached fontconfig
> snippet, courtesy of Nicolas Spalinger <nicolas_spalinger@sil.org>,
> as /etc/fonts/conf.d/70-no-woffs.conf .
> 
> I'd prefer to reject these fonts based on the fontformat information,
> but fontconfig reports them to be in "TrueType" format on the systems
> that I currently have access to. Alternatively, the globbing could be
> changed to apply to the file name extension, if fontconfig supports that
> (the user docs state that "globs only apply to directories, not to
> individual fonts" although it provides "*.pcf.gz" among the examples).

I'm fine if we add a FC_CONTAINER element that exposes (and filters) based on container type.  But I'm not going to do the work.

All said, I'm not fontconfig maintainer.  I just added my personal take on this.

Cheers

> Thanks!
> 
> Cheers,
> 
>  - Fabian

I know I personally be pissed off if fontconfig ignored woff2 fonts I throw at it.

(In reply to Akira TAGOH from comment #8)
> have you tested applications supporting WOFF like the web browsers etc? most
> of them uses fontconfig and I don't know if this change affects behaviors on
> them. if it works fine, I'll update config in git.

IIUC, a web browser would not use fontconfig to read a WOFF file, the contents of the WOFF file would be sent to a web browser by a web server.

I have seen HTML/CSS files that refer to a local WOFF file on the local filesystem as a demonstration of the WOFF font. In that case, I did not think the web browser was using fontconfig to access the WOFF, the CSS file refers to the WOFF filename directly. An example of this is at

https://github.com/silnrsi/font-annapurna/tree/master/web

Could we probably agree upon adding a WOFF-disabling snippet to the source and leaving the decision to enable it to the distributors?

If the template doesn't have enough guarantees to work, that will makes another complaint on it. I'd recommend to have it as an own config or in the package on your distro.

I tend to agree with what Behdad said though, I'll keep this open until the accurate method is found.

(In reply to Akira TAGOH from comment #13)
> If the template doesn't have enough guarantees to work, that will makes
> another complaint on it. I'd recommend to have it as an own config or in the
> package on your distro.

Yeah.  The /usr/share/woff is undocumented distro convention...

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 reply to Behdad Esfahbod from comment #15)
> 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.

WOFF fonts have a much higher memory and CPU cost per process, so we shouldn't encourage distros shipping them for normal apps to use.

(In reply to Behdad Esfahbod from comment #15)
> I'm fine with adding a FC_CONTAINER or another way to differentiate WOFF /
> WOFF2 / SFNT.

I'd like to help out with this, but how are we going to actually detect the container format? I mean, freetype does not seem to offer a function for this. By file extension?

(In reply to Fabian Greffrath from comment #18)
> (In reply to Behdad Esfahbod from comment #15)
> > I'm fine with adding a FC_CONTAINER or another way to differentiate WOFF /
> > WOFF2 / SFNT.
> 
> I'd like to help out with this, but how are we going to actually detect the
> container format? I mean, freetype does not seem to offer a function for
> this. By file extension?

Then adding new FreeType API is one way.  Though, the first four bytes of the file determine it, so maybe we should just do that.

(In reply to Behdad Esfahbod from comment #19)
> Then adding new FreeType API is one way.  Though, the first four bytes of
> the file determine it, so maybe we should just do that.

Does fontconfig even open font files by itself or does it entirely rely on FreeType to provide such meta-data?

(In reply to Fabian Greffrath from comment #20)
> (In reply to Behdad Esfahbod from comment #19)
> > Then adding new FreeType API is one way.  Though, the first four bytes of
> > the file determine it, so maybe we should just do that.
> 
> Does fontconfig even open font files by itself or does it entirely rely on
> FreeType to provide such meta-data?

No, fontconfig doesn't deal with a font directly at this moment.

(In reply to Behdad Esfahbod from comment #19)
> Then adding new FreeType API is one way.  Though, the first four bytes of
> the file determine it, so maybe we should just do that.

Just a naive idea, but could we probably introduce e.g. a (private?)

    char file_header[4]

field into struct FT_Face and fill it with the first four bytes of a font file upon opening? We could then a add function that returns a pointer to this field to the FreeType API (or even a function that interprets this field and returns the font container format in clear text).

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/92.