[XeTeX] where to put woff files

Post by Bobby de Vos
Greetings,
I have seen reports of problems on XeTeX on Ubuntu not handling woff
files, both told to me in person and also on the web [1]. I am now
taking over the Debian/Ubuntu packaging for some fonts (Scheherazade
included) and wondered where to put woff files, to avoid this problem. I
could put them in the documentation folder of the package, where some
sample html and css files could load the woff and display text using the
woff font.
I asked this question on the Debian pkg-fonts-devel mailing list, and
the response [2] contradicted what Khaled Hosny said in [1]. Khaled's
position (IIUC) was that the woff files should not be installed where
fontconfig can find them. Debian pkg-fonts-devel mailing list said to
file a bug against XeTeX for not validating the results of fontconfig.
Whose advice should I follow?

On the whole I would agree with the debian answer: applications like
xetex/xdvipdfmx shouldn't try to use fonts it can't handle.

On windows where fontconfig is used only by xetex I would try to
blacklist the faulty fonts with a <rejectfont>-pattern (I don't know
if it would work for the woff-problem) in the fontconfig
configuration but I don't think that there is an easy way to do
something like this on linux -- all configuration would affect other
application. So imho some other way to blacklist fonts/font types
for xetex/dvipdfmx is needed (luaotfload has a configuration file
for this).

That's the general answer. On the practical side: It can only help
if you can avoid to put the font somewhere where is disturb xetex.
And xetex users shold avoid "vage" font loading by adding the
extension if possible.

--
Ulrike Fischer
http://www.troubleshooting-tex.de/

--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex

Bobby de Vos

2017-04-06 13:10:06 UTC

Post by Ulrike Fischer
On the whole I would agree with the debian answer: applications like
xetex/xdvipdfmx shouldn't try to use fonts it can't handle.

Thank you for your response. I will file a bug with Debian at some point.

Post by Ulrike Fischer
On windows where fontconfig is used only by xetex I would try to
blacklist the faulty fonts with a <rejectfont>-pattern (I don't know
if it would work for the woff-problem) in the fontconfig
configuration but I don't think that there is an easy way to do
something like this on linux -- all configuration would affect other
application. So imho some other way to blacklist fonts/font types
for xetex/dvipdfmx is needed (luaotfload has a configuration file
for this).

AFAIK, Windows users don't have this problem. Unless a user or an
installer installed with WOFF files where fontconfig would find them,
there would not be a problem. The issue comes up when the Debian/Ubuntu
packages would place the WOFF files were fontconfig finds them.

Post by Ulrike Fischer
That's the general answer. On the practical side: It can only help
if you can avoid to put the font somewhere where is disturb xetex.
And xetex users shold avoid "vage" font loading by adding the
extension if possible.

How do I specify the extension? If I am using plain XeTeX and have a
line such as

\font\bodyfont="Andika New Basic/GR" at 12pt

where do I put the extension? I can place the font name in brackets [],
and include the extension, but then I need to supply the entire path to
the font file.

Thanks, Bobby

--
Bobby de Vos
/***@gmail.com/

Ulrike Fischer

2017-04-06 13:31:54 UTC

Post by Ulrike Fischer
On the whole I would agree with the debian answer: applications like
xetex/xdvipdfmx shouldn't try to use fonts it can't handle.

Thank you for your response. I will file a bug with Debian at some point.

Why Debian? I meant it is more a xetex problem so I would add a bug
report there.

Post by Ulrike Fischer
And xetex users shold avoid "vage" font loading by adding the
extension if possible.

How do I specify the extension? If I am using plain XeTeX and have a
line such as
\font\bodyfont="Andika New Basic/GR" at 12pt
where do I put the extension? I can place the font name in brackets [],
and include the extension, but then I need to supply the entire path to
the font file.

You don't need the full path. This here works fine for me (arial is
a system font and the other is in the texmf tree):

\font\test="[arial.ttf]:color=FF0000;mapping=tex-text" at 20pt
\test
alblbl ---

\font\test="[texgyrecursor-regular.otf]:color=00FF00" at 20pt
\test
alblbl ---

But you won't be able to use font options like /GR (at least that's
what xetexref says).

--
Ulrike Fischer
http://www.troubleshooting-tex.de/

--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex

Zdenek Wagner

2017-04-06 14:53:41 UTC

Post by Ulrike Fischer
On the whole I would agree with the debian answer: applications like
xetex/xdvipdfmx shouldn't try to use fonts it can't handle.

Thank you for your response. I will file a bug with Debian at some point.

Why Debian? I meant it is more a xetex problem so I would add a bug
report there.

This is certainly not a Debian bug, the font is installed as it should be.
The problem is that it is not supported by XeTeX/xdvipdfmx and it is a question
what XeTeX should do if fontconfig offers an unsupported font

Post by Ulrike Fischer
And xetex users shold avoid "vage" font loading by adding the
extension if possible.

How do I specify the extension? If I am using plain XeTeX and have a
line such as
\font\bodyfont="Andika New Basic/GR" at 12pt
where do I put the extension? I can place the font name in brackets [],
and include the extension, but then I need to supply the entire path to
the font file.

You don't need the full path. This here works fine for me (arial is
\font\test="[arial.ttf]:color=FF0000;mapping=tex-text" at 20pt
\test
alblbl ---
\font\test="[texgyrecursor-regular.otf]:color=00FF00" at 20pt
\test
alblbl ---
But you won't be able to use font options like /GR (at least that's
what xetexref says).

Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz

Post by Ulrike Fischer
--
Ulrike Fischer
http://www.troubleshooting-tex.de/
--------------------------------------------------
http://tug.org/mailman/listinfo/xetex

--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/li

Ulrike Fischer

2017-04-06 15:22:24 UTC

I wished you would clean up the messages a bit before sending. It is
horribly hard to read if you burry a three liner in the middle of
all sorts of citations and signatures.

--
Ulrike Fischer
http://www.troubleshooting-tex.de/

--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex

Philip Taylor

2017-04-06 18:13:15 UTC

Post by Ulrike Fischer
I wished you would clean up the messages a bit before sending. It is
horribly hard to read if you burry a three liner in the middle of
all sorts of citations and signatures.

I am normally in favour of (extremely) heavy trimming, but in this case
it is not possible to unambiguously identify either the target of "you"
or the offending message.
Philip Tayloir

--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex

Jonathan Kew

2017-04-06 15:27:40 UTC

Post by Zdenek Wagner

Post by Ulrike Fischer
On the whole I would agree with the debian answer: applications like
xetex/xdvipdfmx shouldn't try to use fonts it can't handle.

Thank you for your response. I will file a bug with Debian at some point.

Why Debian? I meant it is more a xetex problem so I would add a bug
report there.

Well... while I agree that we should do something in XeTeX to handle
this, I also think it is a poor decision on Debian's side to mix .woff
files, which are explicitly intended for web deployment, alongside .otf
files that are expected to be available in the local GUI desktop
environment. These are two distinct categories of resource, and it would
be more appropriate to keep them separate.

More generally, I think it's a bad idea for a distro or package or
whatever to install multiple copies of the "same" font (e.g. both
TrueType and Type1 formats) with the same name where fontconfig will
find them both.

JK

--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex

Bobby de Vos

2017-08-07 01:38:38 UTC

Post by Jonathan Kew

Post by Zdenek Wagner

Post by Ulrike Fischer
On the whole I would agree with the debian answer: applications like
xetex/xdvipdfmx shouldn't try to use fonts it can't handle.

Thank you for your response. I will file a bug with Debian at some point.

Why Debian? I meant it is more a xetex problem so I would add a bug
report there.

Well... while I agree that we should do something in XeTeX to handle
this, I also think it is a poor decision on Debian's side to mix .woff
files, which are explicitly intended for web deployment, alongside
.otf files that are expected to be available in the local GUI desktop
environment. These are two distinct categories of resource, and it
would be more appropriate to keep them separate.
More generally, I think it's a bad idea for a distro or package or
whatever to install multiple copies of the "same" font (e.g. both
TrueType and Type1 formats) with the same name where fontconfig will
find them both.

I talked with Keith, the author of fontconfig while at DebConf, and he
agrees that multiple copies of the same font should not be installed
where fontconfig can find them.

He also thinks fontconfig/freetype should be enhanced so TrueType (and I
would add OpenType) fonts are prioritized before WOFF.

Either of these changes would solve the issue I have reported. He went
on to say that xdvipdfmx should handle WOFF. Maybe a font designed would
only release a WOFF, and a TrueType would not be available. A few more
details are at

https://sourceforge.net/p/xetex/bugs/139/

Bobby

--
Bobby de Vos
/***@gmail.com/

Mike "Pomax" Kamermans

2017-08-07 19:53:09 UTC

Post by Bobby de Vos
He also thinks fontconfig/freetype should be enhanced so TrueType (and
I would add OpenType) fonts are prioritized before WOFF.

The idea of "installing" a WOFF resource for serving by an OS font
manager is... bad? That's not what WOFF are for, they are explicitly
intended to NOT be system level fonts, and allow certain data to be
omitted because the deployment is known to not be DTP and applications
but web content through CSS instructions. Using WOFF anyway for
something like Xe(La)TeX makes no sense, and if Debian allows WOFF to be
installed at the OS level, that's worth notifying the team over because
that's not a thing your OS should be doing. Maybe Jonathan as one of the
WOFF spec authors has a more nuanced opinion here, but this problem
sounds like it stems directly from an OS treating WOFF resources as
something they are absolutely not, with the obvious and predictable
result of breaking expectations about font resource handling.

Also on a technical note, there is no "truetype vs. opentype" in the
context of font parsers. There are only OpenType fonts, all with the
same magic number, and the "truetype" part refers to one of several ways
in which any OpenType font organises the glyph data. In the context of
prioritising which font to load here, it's OpenType vs. WOFF. Which
tables the OpenType font uses makes no difference. The fact that
OpenType is a system installable font, and WOFF are not, is the real
difference. So hopefully the mess that the very notion of
"installing-WOFF-as-system-fonts" introduces can be looked at, thought
about, and then wisely removed again. It makes no sense at all.

- Pomax

--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex

Bobby de Vos

2017-08-07 20:38:50 UTC

Post by Mike "Pomax" Kamermans

Post by Bobby de Vos
He also thinks fontconfig/freetype should be enhanced so TrueType
(and I would add OpenType) fonts are prioritized before WOFF.

I tend to agree with you Mike (and thank you for your comments). FWIW,
one of the fontconfig maintainers feels differently [1]. Debian does not
have consensus on where to place WOFF files, other than under
/usr/share/fonts where fontconfig finds them. So for my needs, I will
just not put WOFF files in Debian packages, and the issue (for the
people I support) is solved (with no work needed from the XeTeX
community). What the right thing to do, and by whom, is getting beyond me.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=101270#c10

--
Bobby de Vos
/***@gmail.com/

Bobby de Vos

2017-04-07 13:21:32 UTC

Post by Ulrike Fischer
On the whole I would agree with the debian answer: applications like
xetex/xdvipdfmx shouldn't try to use fonts it can't handle.

Thank you for your response. I will file a bug with Debian at some point.

Why Debian? I meant it is more a xetex problem so I would add a bug
report there.

Sorry for the confusion. I asked about woff files on a Debian email
list, and the response [1] was I should file a bug report against the
package that was choking on the woff files. That package would be the
package containing XeTeX. So I agree, not a Debian bug, but Debian would
receive a bug against the XeTeX package, and presumably forward that bug
to the XeTeX maintainers (which I would imagine are on this xetex list
already).

[1]
https://lists.alioth.debian.org/pipermail/pkg-fonts-devel/2017-April/019338.html