[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  

> * 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  

> 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!


More information about the XeTeX mailing list