Wow. I didn't think this would have such a huge effect.
Reading this,
In these two systems, ConTEXt first attempts to find the font using
the official font name. If that doesn't work, then it tries to use the
font by file name as a fallback. Since this is not very efficient and
also because it may generate —harmless, but alarming looking— warnings
it is possible to force ConTEXt into one or the other mode by using a
prefix, so you will most often see synonym definitions like this:
\definefontsynonym [MSTimes] [name:TimesNewRoman] [features=default]
\definefontsynonym [Iwona-Regular] [file:Iwona-Regular] [features=default]
I decided to try [name:GentiumBookBasic ...]
instead of just [GentiumBookBasic ...]
. (As shown in my edited question, I had already tried [file:GenBkBasR ...]
, with no success.) I didn't think using name:
would make much difference, if any, since according to the above, the official font name is tried first anyway.
But it made all the difference in the world.
All the warning messages I had seen disappeared. I searched the output in vain for any mention of mktexnam, mktextmf, etc.
And more importantly, the render time went from 9 minutes down to 13.5 seconds!
I'm still puzzled as to why I was having the "not very efficient" (i.e. 40 to 60x slowdown!) problem before I started using name:
. I suppose ConTEXt was searching for the font by filename first instead of by official font name first, contrary to the documentation (which might refer to a different version). Still, should it have taken that long?
Lessons learned:
The warnings I was seeing were apparently due to the fact that ConTeXt was first trying to look up the font by filename--and trying to create auxiliary files for a font with that filename, which didn't exist--before looking for a font with that official font name. The latter worked as a fallback, but the former took a huge amount of time.
Always (or at least when these warnings appear) specify, in font definitions, whether you're trying to describe the font by font name or by file name.
Yes, XeTeX really does work with fonts that are just installed in the OS, if you reference the font by official name, but apparently not if you try to reference the font by filename.
If you need to add attributes like 'italic' to the name of a font in \definefont
, you can do it like this: \definefont[SerifLI][name:GentiumBookBasic-Italic at \largefontsize]
, even though there is no font whose name is "GentiumBookBasic-Italic". This corresponds to a font face that fc-list
lists as Gentium Book Basic:style=Italic
. This syntax is not unexpected, but the draft fonts chapter didn't seem to explain whether Palatino-Italic
was more than just a monolithic font name. So the question of whether I had it right or not was an additional dimension of uncertainty during debugging.
Best Answer
An approach without external packages can be as follows:
I've used
\jobname.dat
as the file name just not to clobber my existing files.If the data file is named
foo.xyz
you'll useand then the data will be available in the form
The data file is read line by line and each line is split at the
=
token to get the key and the value. So if the line iswe essentially do
(globally, as we use
\endlinechar=-1
to avoid spurious spaces and get rid of empty lines).