[tex-live] libertine wrongly packaged
George N. White III
gnwiii at gmail.com
Fri Dec 30 17:24:57 CET 2011
On Fri, Dec 30, 2011 at 5:44 AM, Ulrike Fischer <news3 at nililand.de> wrote:
> Am Thu, 29 Dec 2011 14:38:56 -0800 schrieb Karl Berry:
>> libertine-legacy installs/contains also the old fx***.otf-file and
>> By different filenames (there are no filename conflicts).
>> these conflict with the newer ones:
>> Another reason why lookups by system font name are inferior. Too bad
>> the engines and packages push toward that method.
Using font names helps with the mass of existing documents that refer to, e.g.,
"Times" or "Helvetica". Filenames tend to get adjusted by packagers and
There is a long tradition of mapping system font names to whatever default
happens to be installed, e.g.: from fontconfig 30=metric-aliases.conf, we have:
Alias similar/metric-compatible families from various sources:
Nimbus Sans L
Nimbus Roman No9 L
Nimbus Mono L
Times New Roman
Additional substitutions are given in 30-urw-aliases.conf. These
aliases mean that
many legacy documents can be viewed on current system using the default fonts,
rather than having to track down some old font files, but also mean
that many users
continue to select Times and Helvetica and have no idea of what actual
fonts are being
I think it is fine for a system to define default fonts to be used as
etc. but a) the defaults should not use names of "actual" fonts, and
b) there must
be a way to specify "actual <fontname> [<version>] [<type>]" when you
want to turn
off substitutions. Rather than directly alias Times to NimbusRoman
map legacy (e.g., Times, Helvetica, Courier) and "foreign" font names
(e.g., those used
by URW, Microsoft, Star Office, etc) to generic names and then look in
to find what system fonts were chosen for each generic name.
> Lookups by file names have they disadvantages too:
> In my backups I can find various libertine versions:
> LinLibertine_Re-4.4.1.otf, LinLibertine_Re-4.7.5.otf,
> LinLibertine_R.otf, fxlr.otf.
Filenames exist to keep track of particular sequences of
bytes, but are too easily manipulated -- to be robust, the
system has to rely on information that is provided in the
files, not the names.
> Documents which call this fonts by file name would have to been
> rewritten constantly. And if the versions had always used the same
> file names, then probably a version installed in the system would
> conflict in the same way as by font name lookup with another version
> in the texmf trees.
When fonts are given by fontname, the system will apply rules to
choose the actual font file to be used. There needs to be ways to
override the rules in specific cases as well as ways to examine the
choices being made by the system.
>> For the record, the general problem of xetex and xdvipdfmx finding
>> different fonts comes up repeatedly. There's a bug report here:
Add to that differences in document viewers (acrobat reader, xpdf, mupdf, etc.)
on different platforms. Xpdf uses a configuration file to supply filenames for
the base 13 fonts. There is nothing wrong with multiple programs using
different font choices in the absence of specific instructions -- the choices,
however, are mostly invisible and each system has difference arcane
mechanisms to adjust the choices.
There may be simple fixes to ensure that xetex and xdvipdfmx choose the
same fonts when run at the same time on the same system, but a robust font
system should handle cases when xdvipdfmx is run at some later date on
some different platform.
>> The bug is closed because the case at hand was about fontconfig library
>> versions, but it seems to me that is just papering over the problem.
>> Maybe I'm wrong, but that's how it looks. (See the latest comment,
>> from me.)
>> However, since xetex is effectively unmaintained for any meaningful
>> development now, presumably nothing will improve until a new capable
>> maintainer with time to devote to the program appears on the scene.
>> (Not holding my breath.)
Xetex has been very useful and has brought TeX to the attention of new
classes of users, but the technical problems relating to differences in
font systems across platforms and over time require a great deal of
> Well I don't think it is only a problem which should/can be handled
> only by xetex (or luatex/luaotfload). The TeX-systems should also
> (re)consider the way fonts are installed (miktex more than texlive).
> Until now (before XeTeX) TeX fonts and system fonts were two quite
> separated worlds and the place where to install a font was quite
> well defined: TeX fonts in the texmf tree, system fonts in the
> system font folder (with a small number of exceptions like the ttf
> used by the winfonts package).
Y&Y TeX was a early and very capable example supporting
use of "system" (actually ATM) fonts.
> But current ttf and otf fonts now are
> both: fonts used by a tex engine and fonts used by the system. And
> it is the question if such fonts should actually be in a texmf tree.
> At my opinion most users would prefer to install this fonts only
> once in their system. (And - even if it is confortable - I don't
> think that miktex should add by default the texmf-trees to its
> fontconfig pathes.)
Users have to learn to use their system font installer -- many
find it annoying that TeX requires different and arcane
configuration. There are also problems on windows with
ports of open source apps that use (private) fontconfig (gimp,
inkscape, etc.). Given that the development effort needed to
replace the existing font support in legacy programs with
machinery that uses system fonts would be large, I expect
users will remain unhappy until luatex or some later version
manages to provide robust support for system fonts.
George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia
More information about the tex-live