[XeTeX] Strange behaviour xelatex/fontspec/Windows
George N. White III
gnwiii at gmail.com
Wed Sep 28 12:07:26 CEST 2011
On Tue, Sep 27, 2011 at 3:10 AM, <rhino64 at postmail.ch> wrote:
> Sorry for the late answer. Your message was put in the wrong thread
> by my mail program.
> On Mon, Sep 26, 2011 at 05:53:38PM +0900, Akira Kakuto wrote:
>> > It seems that the "fontconfig" package is running on Windows.
>> > I have seen that the binaries (fc-list, fc-cache etc)
>> > of fontconfig package are present.
>> Please confirm that the fc-cache.exe is the one provided by
>> TeX Live, that is, it is in the TeX Live binary directory .../bin/win32.
>> The other fc-cache.exe cannot be used for XeTeX in TL W32.
> Yes it is the program given with TeXlive.
>> Go to the directory shown by the command
>> kpsewhich -var-value FONTCONFIG_PATH
>> Make a file with the name "local.conf" in the directory, for example:
>> <?xml version="1.0"?>
>> <!DOCTYPE fontconfig SYSTEM "fonts.dtd">
>> <!-- local.conf file to configure local font access -->
>> Additional dirs for fontconfig. Subdirs are searched automatically.
> It's the way I plan to follow. Creating a "fonts.local"
> with all the letters usable by Windows. Fortunately,
> only the letters C-Z are used by Windows.
> Then I will create a small batch file which will
> call "fc-cache -v" to redo the font cache. This is
> not particularly elegant but at least should work
> whenever the USB key is plugged on different Windows machine.
Why not have the batch file write a local.conf with the
correct drive letter?
> By the way, with the last version of XeTeX they seems
> to be a bug when handling fonts. I have a similar
> problem on OpenSolaris (XeTeX from TL 2011 crashes as soon as
> a specific font should be located on disk).
> With XeTeX from TeXLive 2010, they seems not to be
> the same problems.
> I should still debug more deeply the problem under
>> Run the commands
>> fc-cache -v
You may be able to avoid the mktexlsr step, either by creating a
dummy local.conf and running mktexlsr once, then just updating
the local.conf file, or arranging to keep local.conf in a small tree
that doesn't use ls-R files.
> This seems to work when the "fonts.conf" is correct (during
> my first tests, the "fonts.conf" file does not contain the
> correct references to the fonts).
> What I should still check however is that if when the "fonts.conf"
> file is correct it is possible to load an non system font
> (the test which was successful, was when the desired
> font was considered as a system font since it was on the cache).
Loading TL supplied fonts without installing them as system fonts
certainly works for many users, but then you don't have then in
system tools, e.g., in font table viewers like BableMap. A number
of ports of linux tools (Gimp, Inkscape) also use fontconfig and
supply their own config files, so you don't install fonts as system
fonts each app has a different list of available fonts.
> This test is now from less importance since I have found
> a bypass but it could reveal a bug in the font handling
> of XeTeX.
> I haven't had the time to do this last check. I will probably do it
> that for the end of week.
George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia
More information about the XeTeX