[BUG] Cannot proceed without the font: [...].woff2 problem

[Werner LEMBERG]

>> But as I say the real issue is a mis-configuration on the user
>> machine, what was intended to be achieved by installing a woff2
>> font in a directory indexed by fontconfig?
> 
> Although WOFF2 (and the original WOFF) was designed as a packaging
> format for webfonts, and not intended for installation in desktop
> systems, support for directly using them as desktop fonts then got
> added to FreeType, and hence a lot of software will actually work
> with them.

Exactly.  I don't see any mis-configuration *in general* – there might
be applications that actually want to use the WOFF and/or WOFF2
formats, and which rely on fontconfig.  Please remember that there are
more applications besides xetex that are served by fontconfig.

> In this case, I think what's happening is that fontconfig lists the
> WOFF2 font, and since xetex uses FreeType to access fonts, it is
> able to handle it (essentially, FreeType decodes the WOFF2 packaging
> and compression, so as far as xetex is concerned it's just an
> OpenType font). So there's no error reported by xetex itself. But
> xdvipdfmx doesn't use FreeType to read fonts; it has its own
> TrueType/OpenType-processing code. And it has not been extended to
> support WOFF2. So when it tries to process the xetex output that
> refers to a WOFF2 font resource, it fails (with this somewhat
> confusing error message).

Actually, you don't have to think of more exotic font formats; there
is a very similar problem if for a font `foo` there exists `foo.pfb`
(Type1), `foo.ttf` (TrueType with quadratic spline outlines),
`foo.otf` (OpenType with cubic spline outlines) – and probably also
`font.pcf` (which is an old bitmap font format common on GNU/Linux
machines that uses X11 as a windowing system) – simultaneously in
directories scanned by fontconfig, since by default it returns the
first font file that fits, which might not be the best one needed by
the application.

>> the systems could perhaps give better error messages but the bug is
>> the incorrect font installation.  Whatever error message is
>> generated, the fix is to move the font.
> 
> Yes, that'll be the simplest fix.

... until this fact is forgotten, and a new installation fills up the
directory again with various font formats for the same font...

> In the longer term, there are various possible ways the situation
> could be improved, but probably none are on the immediate horizon.

The proper, future-proof way to fix this for both `xetex` and
`xdvipdfmx`, besides improving the error message for the latter, is to
extend the programs with a fontconfig setup of its own.

[I answer this here as a generic solution for future reference; you
 might skip the technical details.]

Have a look at LilyPond, which has exactly the same problems.  For
example, it can't digest bitmap fonts; however, it is a user choice on
a given platform whether to make fontconfig return or not return
bitmap fonts in general (usually indicated by the presence or absence
of file `/etc/fonts/conf.d/70-reject.conf`).  The same holds for
OpenType Variation Fonts, which LilyPond can't digest either.

Here are the LilyPond-specific fontconfig configuration files:

  https://gitlab.com/lilypond/lilypond/-/blob/master/mf/00-lilypond-fonts.conf
  https://gitlab.com/lilypond/lilypond/-/blob/master/mf/99-lilypond-fonts.conf

And here is the code that sets up fontconfig accordingly:

  https://gitlab.com/lilypond/lilypond/-/blob/master/lily/font-config.cc


     Werner