[XeTeX] building and installing xetex on a debian(like) system with teTeX 3.0

Ralf Stubner ralf.stubner at physik.uni-erlangen.de
Sat May 20 23:00:03 CEST 2006

Jonathan Kew <jonathan_kew at sil.org> writes:

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

I think the Ubuntu packages you provide explicitly conflict with
dvipdfmx. But somehow the 

Conflicts: dvipdfmx

line is missing from debian/control.

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

Merging the two programs again would definitly be ideal. Otherwise I
could imagine that the dvipdfmx package would install all these files
while the xdvipdfmx package would only provide the additional binary and
otherwise depend on the dvipdfmx package. But in general, getting
packages in Debian cooperating properly is mainly the task of their
maintainers (upstream can help, though). For xdvipdfmx Daniel Glassey
has intended his interest to package it. I don't know how he thinks
about these problems.

>>   Calling 'update-fmtutil' integrates these additions into  
>> fmtutil.cnf.
> This is the sort of distro-dependent thing that I wish everyone could  
> agree on!

That would be nice, but is difficult to achieve. Speaking as one of the
(lesser) members of the Debian TeX Task Force, bringing teTeX or TeX
Live into shape for a Linux distro is not easy. For example teTeX's
default 'everything below one directory' does not go to well with the
File Hierarchy Standard. Tools like update-fmtutil, update-texmf etc go
even deeper into the working of such distributions (TeX Live for Debian
uses the same). One does not want to do that, as long as one does not
have to. For Debian this is the case, and I have recently learned that
Gentoo uses similar (the same?) techniques meanwhile. AFAIK SuSE does
not use something like this. Maybe they don't offer packages that
would like to build additional formats?

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

Ah, this is interesting and chages a few things. 

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

Since the unicode hyphenation files should work with standard TeX, too,
I no longer think they ought to be separated from the rest. Some naming
convention like a 'uni'-prefix could be used instead. 

All the normal (La)TeX input and config files can be made save using
appropriate checks, as it is done in xunicode, fontspec or the graphics
config files. Then a separation would no longer be necessary.

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

It is a bad hack that I used to separate the hyphennation files and
because it is easier when installing witout package management to put as
much as possible below some directory. However, top-level engine
directories like the above 'xetex' should be avoided if possible. And I
think it will be possible here.

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

Yes, separate language.dat files would work but wouldn't be very
comfortable. Maybe it is possible to have something like the switches in
ruhyphen.tex also for this distinction. Just that they could be made
automatic by testing for \XeTeXversion. 

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

Yes, that would be the best solution. Probably it is best to discuss
this on the TeX Live list (haven't found the time to write an answer to
your message there :-(, since the density of people knowledgable about
these things is really high there.


More information about the XeTeX mailing list