[XeTeX] xdvipdfmx code updated

[Jonathan Kew]

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(?)  
> \char71 instead of the \cleaders construct), it is complaining  
> 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