[Fontinst] fontinst fontdsize variance?

[Lars Hellström]

Karl Berry skrev 2016-02-01 23.00:
> Hi Lars,
>
>      This smells like a rounding issue, does it not?
>
> Yes, it sure does.  It just seemed bizarre to me the TFM would store
> more digits than could be used by TeX.  But I guess it does.

For most part, there is a logic in this: TFM numbers are relative to the 
at-size of a font, which is usually in the range 8-16pt, so in order to have 
significant data for the last bit of the TeX dimen, the TFM needs about 20 
bits after the decimal point.

The designsize is however that lone number in the TFM file which is in 
absolute units, so it has greater precision than is needed. But on the other 
hand the most significant bits aren't needed (fontsize 128pt isn't allowed), 
so there is no loss of expressivity.

>
>        - the TFM format keeps more than 16 bits after the decimal point in the
>      designsize (not sure how many; would need to check the format spec to be
>      sure) which is of questionable value,
>
> Yeah.  It's a fix_word: 32 bits, 12 to the left of the binary point.
> (See, e.g., section 541 in tex.web, "The most important data type used
> here...".)
>
>        - the EC fonts have botched the design size calculation for its 14pt-ish
>      size (it's supposed to be 14.4pt exactly).
>
> Yeah.  Haven't looked at the EC sources in decades, and not going to :).
> Maybe it's related to the "improved" precision of the EC font names.
> Well, in any case, they aren't going to change now.

Upon closer examination, I have to conclude that the EC fonts cannot be 
blamed; this appears to be a pit that Knuth has dug for us all by himself. 
The catch is that MetaFont represents numbers (at least the designsize) 
using 16+16 bits, so 14.4 is represented internally as 14 + 26214/65536. So 
far so good. But when written to the TFM file, this is simply padded with 
zeroes, turning it into $14 + 419424/1048576 \approx 14.399994$, and tftopl 
naively reports the latter. The designer would however rather have expected 
$14 + 419430/1048576$ (not just 1 epsilon larger, but 6 epsilon) as the best 
possible binary approximation of 14.4.

In other words, the problem exists for all MF fonts at non-dyadic 
designsizes. It seems there aren't any CM fonts at 14.4pt, but cmr17.pl 
indeed claims to have a designsize of $17.279999 \approx 17 + 
293600/1048576$ rather than $17.28 \approx 17 + 293601/1048576$. So Knuth 
had an example where he could have seen this.

>
>      fontinst side do anything to avoid them completely? I think so (but
>      whether it is worth it is another matter).
>
> The reason why it could be worth it is that I have scripts to check vf
> validity in TL that are run regularly.  Of course I can tell the scripts
> not to check these particular fonts, but then any real errors, like
> unresolved base fonts (this happens sadly frequently, overall) would be
> omitted.

Yes; vptotf isn't all that detailed in its messages either. It seems more 
reasonable to have fontinst preserve the designsize-as-given then. I'll see 
if I can have a patch ready for you in a couple of days.