[XeTeX] Strange Euler Script font behaviour

[Jonathan Kew]

On 19 Nov 2004, at 4:39 am, Will Robertson wrote:

> Hi
>
> What is going on?
>
>    \font\1=eusm10 at 12 pt\1
>    ABCD
>    \bye
>
> In pdfTeX, I get "ABCD" in the Euler Script font.
> In XeTeX, I get "BCDE" (in Euler Script again) with messed up spacing.
>

OK, confession time.... access to characters in TeX legacy fonts using 
TFMs and non-standard encodings is currently rather fragile. (I'm 
amazed to have gotten away with it as far as this!)

You can get incorrect glyphs because xdv2pdf is guessing wrong about 
the character code -> glyph index mapping to use when drawing the 
glyphs (which is done through CoreGraphics APIs that take *glyph* 
indices in the font). You get messed up spacing because layout is done 
by xetex based purely on the .tfm file, so it uses the correct metrics 
of "ABCD"; rendering the glyphs "BCDE" at those positions is liable to 
look mis-spaced.

The problem arises because XeTeX (more specifically, the xdv2pdf tool) 
is not using the correct character-to-glyph mapping. It would probably 
be fixed if there was an encoding (.enc) file specified for this font 
in the psfonts.map file. Currently (this may change!), xdv2pdf reads 
dvips's font map file in order to determine the mapping from a tfm font 
name (which is what was specified in the document) to several things:
- the actual PS name of the font to be used
- the name of the font file to be activated (with .otf replacing .pfb)
- the encoding (.enc) file to be applied, if any

If an .enc file is provided, then xdv2pdf will use this to locate the 
correct glyphs by name (which means the .otf has to include glyph names 
in the 'post' table, something that not all conversion-to-otf processes 
achieve; that's another matter). If there's no .enc file, xdv2pdf makes 
some assumptions about the order of glyphs in the font matching the 
order of character codes that the .tfm says exist in the font. I tried 
to set up the .pfb->.otf conversion script such that this would usually 
work (the CM fonts I tested seemed to be fine), but I have not been 
able to exhaustively test all the auto-converted fonts, and clearly it 
didn't come out quite right in this case.

So, for right now you could probably solve this if you're prepared to 
create a suitable .enc file and edit psfonts.map to explicitly use 
this. For the longer term, I'm looking at possible ways to make the 
whole process more robust, and perhaps to avoid the need for a full 
'post' table in the .otf fonts (to simplify the conversion from .pfb), 
or even use the .pfb files directly. This is in a research/experimental 
stage at the moment; no guarantees of exactly what I'll be able to 
achieve.

Sorry for the brokenness of the current situation!

JK