Intolerable difference in glyph width: font=vnbx12

[Werner LEMBERG]

>> Processing the attached test file with with tex and dvipdfmx yields
>> the following warning.
>> 
>>   dvipdfmx:warning: Intolerable difference in glyph width: font=vnbx12, char=247
>>   dvipdfmx:warning: font: 656 vs. tfm: 624.847
>> 
>> and indeed, as you can see in the PDF output, the paragraph with 'u
>> horn' glyphs sticks into the right margin because dvipdfmx uses the
>> font's glyph width.
>> 
>> I'm not sure whether this is a bug in the METAFONT sources or in
>> the conversion process that generated `vnbx12.pfb`...

> I get the erroneous result only with xetex but not with pdftex or
> luatex.  Can you confirm?

Yes, confirmed.

> But there is something interesting though:
> 
> vnbx12.pfb:
>   dup 247 /uhorn put
> 
> $ tftopl vnbx12.tfm
> 
> (CHARACTER C u
>    (CHARWD R 0.624847)
> 
> (CHARACTER O 367
>    (CHARWD R 0.624847)
> 
> It looks wrong at a first glance that /u and /uhorn have the same
> width.  But it is desired.  [...]

OK, thanks for the information.

> The problem here is that xetex obviously doesn't rely on the data
> provided by the font metrics (.tfm) file but determines the width of
> a particular glyph from the /charpath of the Type 1 font and then
> complains that these widths are different.  It's completely wrong to
> use the calculated widths from the font instead of the widths given
> in the .tfm file.

No, this is *not* the problem.  You might call it a feature of
(x)dvipdfmx that it prefers the information from the font file over
the TFM data – it is debatable whether this is the right choice (IMHO
it's probably not, and I ask the maintainers of dvipdfmx to chime in)
but it is a possible design option.

> In this case the horn accent shouldn't have an impact on character
> spacing.  This can only be accomplished if the positions of glyphs
> are determined from the .tfm files but not from their actual shapes.

You are missing the important point here: In the Type1 font file,
there are *also* width values!  And the width value for 'u horn' (and
its accented siblings) doesn't fit the value from the TFM.

In other words, the metrics change for the advance width of 'u horn'
to be identical to 'u' was done in the vnbx12 sources and/or the TFM
files but apparently forgotten in `vnbx12.pfb` (see attached images).

Someone™ should check all vnr glyphs for such misalignments; using the
route

  tex  →  dvipdfmx -v  →  PDF

to get the appropriate warnings is probably the simplest way – maybe
there are more such problems.

BTW, this would also be an excellent point of time to convert the vnr
Type1 fonts to OpenType, given that Adobe is discontinuing active
support for Type1 fonts in its products next year (passive support for
displaying Type1 fonts remains, though).

> If my assumptions are correct xetex doesn't use the widths provided
> by the metrics files but determines them from the actual glyph
> outlines in the fonts.

No, it doesn't.


    Werner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vnbx12-type1-u.png
Type: image/png
Size: 54778 bytes
Desc: not available
URL: <https://tug.org/pipermail/tex-live/attachments/20211017/90817b96/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vnbx12-type1-uhorn.png
Type: image/png
Size: 69135 bytes
Desc: not available
URL: <https://tug.org/pipermail/tex-live/attachments/20211017/90817b96/attachment-0003.png>