actually looking up fonts on the filesystem #413
Comments
|
Thanks -- having an option to only search kpse would make sense in fontspec. I guess it would just look like or similar. That could then change the brackets interface to a |
|
That would be a good improvement. But I was thinking of something even stronger: make kpseonly the default behavior when filename lookups are requested. Why would I want system fonts involved at all when I explicitly asked for a filename lookup? (Answer: I don't.) There could be an option for the reverse, [CheckSystemToo], although that doesn't sound easy to implement given the need for different syntaxes in the \font call. However, if you think that is too incompatible a change at this point, please at least change the documentation to say that "filename lookups" aren't really -- system fonts are still found first, absent the potential new option. It was a great (and unwelcome) surprise to me. I just hope there are no ill effects from this new kpse:foo.otf call. I'll be impressed if it all "just works" ... |
|
Ah, I agree with you that Kpse only is more sensible (that’s the XeTeX approach) by default.
|
In my experience, it is quite common that people download some font, install it and then want to use it from TeX. Of course, the most obvious name is the name of the file they just downloaded (Finding the font name at the very least would involve opening the file, sometimes even finding the right tool to get such information...). So the requirement to find a system font by filename is not particularly uncommon. Actually I know multiple people who were confused by XeTeX finding different fonts when using fontnames or font filenames. So while I think that a
In which way aren't these really filename lookups? The fonts are looked up by filename, there are just more places in which we look for them.
The most important difference I can think of right now is that they support different characters. For obvious reasons, |
|
Marcel - As far as I know, the only way fontspec provides (documents) to
specify a filename lookup is by specifying a filename (foo.otf, Path=,
etc.). If that syntax also does a fontname lookup, as you are saying and
as you implemented in luaotfload, then there is no way to reliably do a
filename lookup. So you are proposing (and have implicitly made, in
luaotfload) a radical change in fontspec, it seems to me.
I fully understand that lots of people want to install and find their
system fonts. I understand it is convenient to use the filenames they
downloaded. Fine. But that does not obviate the need to be able to
reliably find fonts by filename, without system fonts being involved.
There would be no serious problem if luaotfload preferred filename
lookups to fontname lookups when a filename is requested by
fontspec. But it doesn't, as you know. It finds system fonts first, even
when the filename is requested. That is the crux of the problem, for me.
Furthermore, I think it is an excellent, and important, feature that
xetex and luatex find the same font given the same fontspec
command. This was another major point of confusion for me. I'm not sure
if it is feasible for fontspec to implement in xetex the same sort of
fallback to method#2 if method#1 fails that luaotfload has.
I agree that fontname vs. filename lookups have been a source of
confusion ever since day one of Jonathan implementing system font
lookups. And the way to improve that, it seems to me, is not to
heuristically guess which one is meant, or assume "most" people use
system fonts so let's use those first, but to provide clear ways to
specify each separately, or both. Unfortunately Jonathan failed to
provide that at the beginning (filename lookups were distinctly
second-class citizens), and we are still playing catch-up, 15 years
later.
I have no objection to fontspec providing a way to do
filename-then-fontname, or fontname-then-filename; indeed, it sounds
like a good idea. My objection is to having no way at all to do pure
filename lookups (the way just about every other file in the TeX system
is found).
As for what the default should be, for myself, I think the traditional
fontspec method (now broken by luaotfload, as I am just learning) was
reasonable: if a filename is provided, it does a filename lookup. If a
fontname is provided, it does a fontname lookup. I think it would be a
terrible incompatibility to change that, but if that's what Will
decides, that's what he decides. Given a [KpseOnly] or [SystemFontOnly]
or [TryBoth] options, it would be at least be possible for people to get
the behavior they want.
I didn't know kpse:name did not allow . That makes it less
valuable. That's another common thing people want to do: give an
absolute path to the exact file they want. Kpse itself certainly
supports absolute path lookups. Oh well. For "normal" filename lookups
controlled by the paths, it would still be a good improvement to be able
to access that with a TeX option, as discussed. -k
|
|
On Tue, 11 Feb 2020 at 23:44, kberry ***@***.***> wrote:
I have no objection to fontspec providing a way to do
filename-then-fontname, or fontname-then-filename; indeed, it sounds
like a good idea. My objection is to having no way at all to do pure
filename lookups (the way just about every other file in the TeX system
is found).
Karl I find your terminology confusing here,
A filename lookup uses the system filename of the font file
a fontname lookuop uses the internal font name as specified inside the font.
That distinction is separate from the distinction of whether the system
font path or the texlive font search path is used, isn't it?
David
|
|
Karl I find your terminology confusing here,
I find your confusion confusing!
A filename lookup uses the system filename of the font file
I don't know what the "system filename of the font file" is, but no,
that is not my understanding.
a fontname lookuop uses the internal font name as specified inside the font.
I guess. The reality, as far as I've seen, is that a "fontname" lookup
uses fontconfig (on Unix). No one seems to know what that really means
or how to control it precisely. I have tried pretty hard to understand
why fontconfig returns font x for request y, and failed. There is no
clear documentation. The source is unreadable. Etc.
That distinction is separate from the distinction of whether the system
font path
System fonts (on Unix anyway) do not exactly have a "path". They are in
some weird database with all kinds of tricky features.
or the texlive font search path is used, isn't it?
This is all news to me. My understanding of fontspec (and xetex) ever
since day one was that a filename request (foo.otf) meant looking it up
with kpse, as in "kpsewhich foo.otf", and did not involve system fonts
in any way whatsoever. That is certainly what the documentation
implies. It does not talk about the "system filename of the font file".
Hans implemented all kinds of crazy caching of system fonts in luatex
which obscured (and still obscures, I guess) the issue. I hated this but
have no influence over what hapens.
This is all so frustrating!!!
|
The "system filename of the font file" is the name of the file in which the font is stored.
You can find the logic used by luaotfload in luaotfload-database.lua.It is a bit chaotic but with some effort readable and tries to be mostly compatible with fontconfig. Basically what it does is: Every font has a fontname, a (preferred) familyname and additional metadata set (in the OpenType name table). When a name is given, it is matched against the familynames. If a familyname matches, a font from that family is used (The precise font depends on whether regular/italic/bold has been requested, optical sizes etc). Otherwise we match against the fontname. If a fontname matches, the matching font is used. (fontconfig allows some additional lookup variants which are mostly irrelevant in a TeX context)
??? If there are fonts on Unix stored in some weird database then luaotfload can't find them. As far as we are concerned, the fontconfig configuration files translate to a list of directories (mostly
What David describes is pretty much the model of luaotfload (XeTeX is a bit different): There are two distinctions:
All relevant caching happens in luaotfload, luatex (the engine) itself never deals with system font related stuff. This caching is pretty much necessary to get performant font name lookup because we can't use fontconfig directly and they don't have a documented (and there probably not stable) format for their cache files, so we can't reuse them either. |
|
On Wed, 12 Feb 2020 at 00:07, kberry ***@***.***> wrote:
Karl I find your terminology confusing here,
I find your confusion confusing!
A filename lookup uses the system filename of the font file
I don't know what the "system filename of the font file" is, but no,
that is not my understanding.
I meant just the filename of the file, as returned by ls (or dir or
whatever) not using any special properties of the file being a font.
As opposed to the internal name(s) set in the internal tables of the font
structure in the file.
David
|
|
Marcel - thanks for all the information. I forgot that luatex does not
use fontconfig, only xetex does, so all that was off the mark. Sorry.
dc> I meant just the filename of the file, as returned by ls (or dir or
whatever) not using any special properties of the file being a font.
Yes, right. But ... as found by kpse, using the standard TeX-world
paths, not involving system font paths (like /usr/share/fonts) or
fontconfig (xetex). That is what I had always understood "filename
lookup" to mean, as far as I understood it, and how the fontspec
documentation talks about it. Thus it was news to me that luaotfload
looks in the system font directories even when a filename is requested.
For myself, I think this difference between xetex and luatex is
undesirable. If it is kept as the default by fontspec, at least it
should be documented and the [KpseOnly] option come back into play, so
those of who need reproducible, system-independent documents can have
them. We'll see what Will thinks (who mentioned to me he's busy at work
so nothing will happen soon, anyway).
As opposed to the internal name(s) set in the internal tables of the font
structure in the file.
That's what I thought you meant. I'm glad you didn't :).
I was at my wit's end yesterday. --thanks, karl.
|
|
Thanks all for the discussion. I have to admit I’m leaning towards keeping the current behaviour simply for backwards compatibility, and allowing [OnlyKpse] to be a font option so you could write \defaultfontfeatures{OnlyKpse} in a fontspec.cfg file and change the behaviour globally for oneself. Anyone else like to weigh in on the relative merits of either approach?
|
Hi again Will - given a TeX source with (for example)
\setmonofont[Scale = .95]{zcoN-Regular.otf}
I was quite surprised to learn that my .fonts.conf was relevant in any way with that specification. But it is. luaotfload still prefers system fonts to filesystem fonts, if it can match the name. Argh! (I had an old version of zcoN in my fonts.conf, and it was being found instead of the current version as found with kpsewhich.)
luaotfload-tool has an option --prefer-texmf to undo this, but I don't think that helps at the fontspec level. I asked on luaotfload, and Marcel said (latex3/luaotfload#130) that it can be done with Lua:
wdyt? Could this be added to fontspec given the lookup-by-filename request?
He also mentioned omitting the brackets on the \font:
though I have a feeling that would impact other things. Though I guess I don't really know. --thanks, karl.
The text was updated successfully, but these errors were encountered: