[XeTeX] Strange behaviour xelatex/fontspec/Windows

rhino64 at postmail.ch rhino64 at postmail.ch
Tue Sep 27 08:10:52 CEST 2011


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.
> 
> (1)
> 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.
> (2)
> Go to the directory shown by the command
> kpsewhich -var-value FONTCONFIG_PATH
> 
> (3)
> 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 -->
> <fontconfig>
> <!-- 
> Additional dirs for fontconfig. Subdirs are searched automatically.
> -->
> 
> <dir>g:/somedir/opentype</dir>
> <dir>g:/somedir/truetype</dir>
> 
> </fontconfig>
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.

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
OpenSolaris.
> 
> (4)
> Run the commands
> mktexlsr
> fc-cache -v

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).
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.


More information about the XeTeX mailing list