[XeTeX] building and installing xetex on a debian(like) system with teTeX 3.0
Jonathan Kew
jonathan_kew at sil.org
Sat May 20 17:16:08 CEST 2006
Hi Ralf,
Thanks for your detailed message describing your experience; that's
really helpful.
Just a couple of comments at this point:
> Building and installing xdvipdfmx was straigtforward:
>
> $ cd xdvipdfmx
> $ dpkg-buildpackage -rfakeroot
> [time and lots of output passes]
> $ sudo dpkg --purge dvipdfmx
> $ sudo dpkg --install ../xdvipdfmx_0.1-1_i386.deb
>
> I had to remove (actually purge) the dvipdfmx package, since xdvipdfmx
> installs some files into the same location.
Aha, that's a good warning (and maybe we should try to adjust things
to avoid the conflict).
In theory, xdvipdfmx should be an upward-compatible replacement for
dvipdfmx, but of course there's a risk that something has been
broken, especially while the driver is at an early-experimental
stage. That's why it's a separate project at the moment; once things
are more complete and stable, I hope we can have a single merged
program.
> * debian/postinst and rebuild-formats patch fmtutil.cnf. At least for
> Debian with teTeX 3.0, fmtutil.cnf is generated from the files in
> /etc/texmf/fmt.d. So any changes to it could get lost. I therefore
> created an additional file in /etc/texmf/fmt.d:
>
> $ cat /etc/texmf/fmt.d/10xetex.cnf
> # XeTeX formats
> xetex xetex - *xetex.ini
> xelatex xetex language.dat *xelatex.ini
>
> Calling 'update-fmtutil' integrates these additions into
> fmtutil.cnf.
This is the sort of distro-dependent thing that I wish everyone could
agree on!
> * debian/postinst and rebuild-formats patch fmtutil itself. This is no
> longer necessary in teTeX 3.0. (There are no .efmt files and
> hence no
> need for that case statement.)
On a teTeX 3.0 system, I believe the patch will simply fail to be
applied, so it should be harmless.
> Now comes the interesting part: Where to place the files from the
> texmf
> subdirectory. AFAIK the contend of texmf/scripts is only necessary on
> OSX, hence I ignored that.
Correct. Maybe I should strip that out of the Linux packages.
> texmf/doc and texmf/fonts can go straight to
> /usr/local/share/texmf/ (make sure not to copy all the '.svn'
> directories). The content of texmf/tex is more interesting. First,
> there
> are hypenation files in texmf/tex/generic/hyphen. These are equally
> named as some allready installed hyphenation files. AFAIK they must
> not
> be used together with a normal tex, though. (Is this correct?)
They are *supposed* (unless I made a mistake) to still work with
standard TeX. But as a longer-term solution, I hope the standard
files will be made Unicode-compatible; the modified versions for
xetex are a temporary workaround.
> AFAICT the standard install has no provision to separate the
> hyphenation
> files. It tries to separate the other files by installing them in
> TEXMF/tex/xetex and TEXMF/tex/xelatex. I am not sure if the former
> is a
> good idea. The latter approach does not work with teTeX 3.0, since
> there
> texmf.cnf contains:
>
> % XeTeX
> TEXINPUTS.xelatex = .;$TEXMF/tex/{latex,generic,}//
> TEXINPUTS.xetex = .;$TEXMF/tex/{plain,generic,}//
That's a nuisance; I think these should be changed. Though exactly
what the best configuration would be is a little unclear to me. Maybe
something like:
TEXINPUTS.xelatex = .;$TEXMF/tex/{xelatex,latex,generic,}//
TEXINPUTS.xetex = .;$TEXMF/tex/{xetex,plain,generic,}//
This still doesn't give a solution for the hyphenation files, though.
> [...]
> % Earlier entries override later ones, so put this last.
> TEXINPUTS = .;$TEXMF/tex/{$progname,generic,}//
>
> Hence xetex and xelatex would not look first into TEXMF/tex/xetex and
> TEXMF/tex/xelatex. My solution here is a *really bad* one, since it is
> against the spirit of TDS 1.1: I created a directory
> /usr/local/share/texmf/xetex and put the things from generic,
> xetex, and
> xelatex into generic, tex and latex directories below that. To have
> these files found, I needed an addition to texmf.cnf, which is
> automatically created from the files in /etc/texmf/texmf.d:
>
> $ cat /etc/texmf/texmf.d/40XeTeX.cnf
> % this does not conform to TDS, but it helps to separate out
> % XeTeX spcific things
>
> % XeTeX
> TEXINPUTS.xelatex = .;$TEXMF/{xetex,tex}/{latex,generic,}//
> TEXINPUTS.xetex = .;$TEXMF/{xetex,tex}/{plain,generic,}//
This seems like a useful approach, though; guess I need to read some
TDS documentation.
What about a hybrid such as:
TEXINPUTS.xelatex = .;$TEXMF/{xetex,tex}/{xelatex,latex,generic,}//
TEXINPUTS.xetex = .;$TEXMF/{xetex,tex}/{xetex,plain,generic,}//
I expect this will fail the TDS test as well, though.
> I had some problems with the last step due to hungarian and serbian
> hyphenation files. Since I din't wanted to remove these entries from
> language.dat, I created the link
>
> /usr/local/share/texmf/xetex/generic/hyphen/huhyphn.tex -> huhyph.tex
>
> and created an empty file
>
> /usr/local/share/texmf/xetex/generic/hyphen/srhyphc.tex
>
> Not exactly clean solutions...
Right; huhyphn.tex and srhyphc.tex have not yet had the XeTeX Unicode-
compatibility treatment, so you need to avoid them in one way or
another.
> After that the formats could be created and now I am able to use
> xe(la)tex on Linux. :-)
>
> -----------------------
> This message has gotten way to long. I think what is needed is some
> sort
> of separation of the hyphenation files.
One solution would be to have a separate language.dat file, so that
differently-named hyphenation files can be used. But that just pushes
the issue to a different level-- co-ordinating the two language
configuration files (assuming users want the same set of languages in
both latex and xelatex). Up till now, I've tried to avoid that and
let xelatex transparently inherit the existing latex configuration
wherever possible.
I think the real answer is to get Unicode/XeTeX-compatible versions
of the hyphenation files into the main TeX distributions, but that
will of course take some time.
Thanks a bunch!
JK
More information about the XeTeX
mailing list