[XeTeX] How to use EC font encoding in XeTeX?

Jonathan Kew jonathan_kew at sil.org
Sat Jun 10 10:35:41 CEST 2006


On 9 Jun 2006, at 11:25 pm, Mojca Miklavec wrote:

> Hello,
>
> Just wondering: how does XeTeX deal with hyphenation when working with
> EC-encoded fonts?

Incorrectly!

More seriously... this is a fundamental problem in TeX, due to the  
lack of a character/glyph distinction. Text-processing operations  
such as hyphenation are carried out in the same code-space as font  
access, which means that TeX is dealing with text in a font- 
dependent, glyph-encoded way. Packages such as inputenc or extensions  
like encTeX allow transcoding between codes in an external input and  
"character" codes within TeX, but there's no way to do such a mapping  
between the "character" codes TeX processes (e.g., hyphenates) and  
the font access codes that end up in the DVI (or PDF) file.

So the result you get will depend on the encoding used by the  
patterns. Hyphenation patterns are necessarily expressed in terms of  
a specific encoding, and in TeX that has to be the "font encoding" --  
the character codes that are being used by TeX to interact with  
fonts, whether that means TFM files or OpenType fonts. You can use  
TeX macros to remap codes between the input file and the application  
of hyphenation patterns, but not between the application of patterns  
and the font access codes.

So any given set of patterns loaded in TeX are specific to a certain  
*font* encoding, and will not work correctly with other encodings.  
Some of the standard patterns (e.g., German) fudge this issue  
slightly, by including duplicate patterns for two encodings (e.g.,  
patterns with ^^ff [T1] for ß, and also patterns using ^^Y [OT1] for  
ß). They get away with this because in T1 text, ^^Y will not occur in  
words, and in OT1 text, ^^ff will not occur, so the extra patterns  
never match in practice. But it's a hack, and is fundamentally a dead- 
end approach that cannot extend to cover the full range of possible  
font encodings, only a few cases with very limited differences.

The problem becomes much more obvious in cases such as Russian, where  
the hyphenation files have to be configured at format-compile time to  
load according to the particular Cyrillic font encoding you want to  
use, and if you subsequently decide to use a different encoding, they  
simply won't work right.

This cannot be solved at the TeX macro level, unless we were to build  
format files with patterns loaded multiple times under different  
\language codes, and then use these different codes according to the  
font encoding chosen at runtime.

I believe that a better way forward is to move away from processing  
text in the old custom font encodings as quickly as possible, towards  
use of Unicode as *the* standard encoding for text data. Obviously,  
we can't achieve that in an instant, but it's the long-term answer,  
and that's the goal that I'd prefer to put effort towards. So in the  
XeTeX formats that I create, I aim to load patterns as Unicode  
wherever possible, so that hyphenation will work correctly for  
Unicode text. Because Unicode and Latin1 character codes match for  
letters with codes < 256, the patterns should also behave correctly  
when used with Latin1-encoded text/fonts, which is adequate for many  
of the major western European languages. But they can't  
simultaneously support all the other, differently-arranged font  
encodings. You can, of course, load patterns in XeTeX using other  
encodings if you wish; but what you can't have is a single set of  
patterns loaded in the format file that correctly hyphenate text in  
conflicting encodings.

It would be possible to extend TeX so as to support some kind of  
mapping between the "character" codes in the text to be hyphenated  
and the pattern codes; perhaps a new table \unicode, similar to  
\lccode, could map font-encoded characters (in the text) to Unicode  
values (in the hyphenation tables) on the fly. This could then be  
changed at runtime to match the current font encoding. This would  
need support from LaTeX/ConTeXt packages as well as an extension in  
the program itself, though; I'm not sure it's the most worthwhile way  
to invest effort.

JK




More information about the XeTeX mailing list