Intolerable difference in glyph width: font=vnbx12

[Reinhard Kotucha]

Sorry, pressed the wrong key...

On 2021-10-18 at 07:23:59 +0000, Werner LEMBERG wrote:

 > >> 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).
 > >
 > > yes this seems the root of the problem.  The pfb files were
 > > converted using a number of tools and I honestly cannot recall
 > > exactly how it was done.  Fortunately there is a tugboat article
 > > https://www.tug.org/TUGboat/tb24-1/thanh.pdf about it.
 >
 > Interesting, thanks!
 >
 > > From the article it looks likely that all [uoUo]horn letters (plus
 > > their accented variants) from vnr fonts will have this problem, and
 > > it will take quite a lot of time/work to fix.  I wish I had the time
 > > to fix this problem, but I have other things that have higher
 > > priority on my todo list.
 >
 > As mentioned already in a private mail, the following might be a route
 > that shouldn't take too long:
 >
 > * Find out whether there are more glyph width differences in the vnr
 >   family (dvipdfmx shows that).
 >
 > * Fix the widths by using `t1disasm` + manual editing + `t1asm`.  A
 >   skilled user might even write a script to automate the manual
 >   editing part, i.e., taking the width of the 'u' glyph from the
 >   disassembled output and replacing the widths of all other
 >   occurrences of 'u + accent(s)'.

Hi Werner,
this is what I had in mind too but it takes some time.  There are some
other things which should be fixed too.

  \font\v=vnr12 at 1000pt \v
  \setbox0\hbox{0}
  \showthe\wd0

  > 489.4638pt.
  l.8 \showthe\wd0

The tfm file contains (CHARWD R 0.489464).  This looks fine so far

  489.464pt * 72.27/72 = 491.29949bp

but the pfb file contains

  /zero {
      41 490 hsbw

There are many of such rounding errors in the font.  I assume that
it's best to replace all widths in the pfb files by values derived
from the tfm files.  Then xetex should behave like the other engines.

I need to write some scripts in order to investigate all fonts but I
think that this is a reasonable approach.

Regards,
  Reinhard

--
------------------------------------------------------------------
Reinhard Kotucha                            Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover                    mailto:reinhard.kotucha at web.de
------------------------------------------------------------------