On Tue, Sep 27, 2011 at 3:10 AM, rhin...@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.
(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.
--
dirg:/somedir/opentype/dir
dirg:/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.
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
OpenSolaris.
(4)
Run the commands
mktexlsr
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 aa...@chebucto.ns.ca
Head of St. Margarets Bay, Nova Scotia
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
