[XeTeX] Strange Euler Script font behaviour
Jonathan Kew
jonathan_kew at sil.org
Fri Nov 19 15:38:59 CET 2004
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
More information about the XeTeX
mailing list