Re: Round-off errors in metrics ...

["Melissa O'Neill" <oneill@cs.sfu.ca>]

I wrote:
>>It'd also be useful to know just how much difference the current `round
>>to an integer' process makes -- Berthold Horn did seem pretty outraged
>>at the very idea, but are other people similarly upset by these
>>inaccuracies. Is there a noticable difference?  

... and Rob Hutchings replied:
> Isn't worrying about the round-off (or truncation?) rather like
> straining at a gnat and swallowing a camel? The camel is the complete
> neglect of 'overshoot' by every afm conversion program I've seen,
> which means that the height of a,e,o in the .tfm is slightly greater
> than xheight, with the visible result that accents placed over these
> letters by \accent (in OT1 encoding) are higher than the same accents,
> either placed over \i or u by \accent, or placed by PostScript if T1
> encoding is used. [Accents are raised by (character height - xheight).]
>
> [...]
>
> So if anyone is planning to improve the algorithms for afm conversion,
> I suggest that the overshoot area is well worth investigation. It's
> even possible that fixing heights and depths before they are seen by
> vptovf might eliminate the necessity for rounding at that stage.

Yesterday I wrote a Perl script called `afmtopl' which generates a ligful
PL file from an AFM file, without those roundoff errors I was complaining
about. In combination with pltotf, it can already replace the basic
functionality of afmtotfm. If anyone can better explain this `overshoot'
issue, and how it should be handled, I'll include code to handle that
too.

> Incidentally, in reply to a later question, the rounding takes place
> because the format of a .tfm file only allows 16 different values for
> character height and 16 for depth. 

Oh... eww...   is it resonably smart in its choice of values?

Comments welcome,

    Melissa.