[tex-live] xetex and language.def

[Jonathan Kew]

On 11 May 2008, at 9:08 pm, Staszek Wawrykiewicz wrote:

> On Sun, 11 May 2008, Jonathan Kew wrote:
>
>>> As for language.def, I'd like to add to it:
>>>
>>> %% == standard (pdf)eTeX
>>> %\addlanguage {german}        {dehypht.tex} {}{2}{3}
>>> %\addlanguage {ngerman}       {dehyphn.tex} {}{2}{3}
>>> ...
>>> %% == plain XeTeX
>>> %\addlanguage {german}        {xu-dehypht.tex} {}{2}{3}
>>> %\addlanguage {ngerman}       {xu-dehyphn.tex} {}{2}{3}
>>> ...etc.
>>> to make more easy manipulation for the user (all percented out).
>>
>> The xu-* files are supposed to load correctly under both xetex and 8-
>> bit (pdf)tex engines; at least that's how we use them in *latex
>> formats, and I assume they'd work the same in plain-based formats. So
>> it shouldn't be necessary to have two versions of these declarations.
>
> Thanks for explanation, but I have in mind to keep it more general at
> the moment, also when somebody does not install xetex (that means also
> xu-* files).

Hmmm. Yes, I see.

Maybe it would be better, though, to install the xu-* files (or this  
year's replacement, if we get a new system in place) in all cases,  
even if xetex is not installed. They're small, and they greatly  
simplify the maintenance of language.* files.

>
>> The idea was that a single language.{def,dat} file should support
>> both pdftex-based and xetex-based formats, avoiding the need to
>> maintain parallel lang files for the different engines, or modify the
>> file depending which format is about to be built.
>
> That would be great, but not for the upcoming TL2008, I think, as etex
> and latex still need different language.{def,dat}.

Sorry, I didn't express that clearly. I meant a single language.dat  
shared by both (pdf)latex and xelatex, and a single language.def  
shared by etex and xetex. That's why the xu-* files do an engine  
test, so they can be used as the standard loaders for the pattern  
files in all cases.

I didn't mean to suggest unifying the etex and latex language files  
(though I think that would also be a good thing!) .... that would  
certainly involve more intrusive changes to the macro packages, and I  
don't think we can attempt that at the moment.

JK