# [XeTeX] xdvipdfmx code updated

Jonathan Kew jonathan_kew at sil.org
Tue Jun 20 15:00:41 CEST 2006

On 18 Jun 2006, at 11:45 am, Toralf Senger wrote:

>> I don't seem to have chemarrows.sty as part of my usual gwTeX setup
>
> Sorry, my mistake, it is chemarrow.sty
>
>> if you might be able to produce a small test file using plain
>> xetex, or xelatex

> [snip]

> An Here a XeTeX file:
>
> \font\x=arrow at 12pt
> normal font: A\hbox to 60pt{\cleaders\hbox{-}\hfill}B;
> arrow font: A\hbox to 60pt{\cleaders\hbox{\x \char71}\hfill}B;
> \bye
>
> When I TeX those files, I get for the arrow font a hbox, where all
> \char71 seem to overlap and fill the box only up to about 70%. When
> I force TeX to fill the box entirely (by manually placing 13(?)
> about overfill hboxes. As if XeTeX and TeX are disagreeing about
> the dimensions of the glyph?

I've taken a brief look at this; I don't have a solution right now,
but at least I understand what's happening.

The PFB font "arrow" from the chemarrow package is a little strange,
in that the glyphs project a long way beyond their advance widths;
you'll see this if you open the font with FontForge or FontLab. So if
you were to render \char71\char71\char71 using the font's "natural"
spacing, you will indeed get overlapping glyphs.

That in itself is not a problem. However, the TFM metrics are
apparently very different, and do *not* result in overlapping glyphs;
thus, if you actually use TeX and load arrow.tfm and set \char71
\char71\char71, you get glyphs that should just barely touch at the
ends.

And that's the root of the problem. What goes into the DVI file is a
series of setchar_71 codes, with no intervening positioning. But the
driver then renders a series of "character 71" glyphs at their
natural spacing in the device font (as the DVI called for a series of
setchar operations, with no positioning adjustments), without
realizing that TeX expected them to be spaced according to an
entirely different set of metrics.

To see this in actual figures, compare arrow.mf and arrow.afm.
According to arrow.mf, char 65 (right arrow) has a width of 120u#,
where u# is 0.82 * 0.1 pt, for a 10pt font. That works out to 9.84pt.
So that's the TFM width, which (Xe)TeX uses in determining how many
glyphs will fill a given \leaders.

But arrow.afm, which gives the metrics of the PFB, says that
character 65 has a width of 395 (for a 1000-unit em), or 3.95pt at a
size of 10pt. And so when a string of characters gets printed, that
is their natural spacing.

I suppose this could be solved by insisting that the DVI driver must
read the TFM file and compare the widths there with the widths in the
actual PFB. But that is additional work for the DVI driver that
shouldn't be necessary. I'd consider this a bug, or at least a
peculiarity, in the PFB font, as it doesn't match the TFM (or the
Metafont source, or the PK fonts) that it's supposed to correspond to.

I suspect, too, that some other drivers would have similar issues
with this font. (PdfTeX happens to do OK because it is generating the
PDF directly from the list of characters with their precise positions
as calculated (from the TFM metrics) within TeX. And maybe some DVI
drivers always read TFMs and position glyphs on this basis, but not
all do this.

JK