<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 20, 2021 at 12:01 AM Werner LEMBERG <<a href="mailto:wl@gnu.org">wl@gnu.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> > * Fix the widths by using `t1disasm` + manual editing + `t1asm`.<br>
> >   A skilled user might even write a script to automate the manual<br>
> >   editing part, i.e., taking the width of the 'u' glyph from the<br>
> >   disassembled output and replacing the widths of all other<br>
> >   occurrences of 'u + accent(s)'.<br>
><br>
> this is what I had in mind too but it takes some time.  There are some<br>
> other things which should be fixed too.<br>
> <br>
>   \font\v=vnr12 at 1000pt \v<br>
>   \setbox0\hbox{0}<br>
>   \showthe\wd0<br>
> <br>
>   > 489.4638pt.<br>
>   l.8 \showthe\wd0<br>
> <br>
> The tfm file contains (CHARWD R 0.489464).  This looks fine so far<br>
> <br>
>   489.464pt * 72.27/72 = 491.29949bp<br>
> <br>
> but the pfb file contains<br>
> <br>
>   /zero {<br>
>       41 490 hsbw<br>
> <br>
> There are many of such rounding errors in the font.  I assume that<br>
> it's best to replace all widths in the pfb files by values derived<br>
> from the tfm files.<br>
<br>
Yes.  Ideally, the values are rational approximations, similar to what<br>
is done in the cmsuper fonts, for example<br>
<br>
  41 4913 10 div hsbw<br><br></blockquote><div><br></div><div>a side note: actually the original values in pfb fonts by BlueSky were in this form; but I had to convert them</div><div>to get rid of those "div" because some of the FMP tool didn't not work with them</div><div><br></div><div>Regards,</div><div>Thanh</div><div><br></div></div></div>