Re: [Fontforge-devel] Vera Hints problem

[George W. <gw...@si...>]

On Thu, 2007-01-18 at 23:45, Wiesiek wrote:
> I want to make a font based on the Bitstream Vera Fonts.
> 
> I open Vera.ttf with FontForge [ 0.0.20061220-1 debian experimental ],
> change the FontNames to "V", clear XUID and generate V.ttf.
> The problem is a small change in space between the letters[width?
> kern?] in size 16,15,14... with hinting "on". 
> 
> In size 17,18,19... it is ok[not changed]. In size 16,15,14... with
> hinting "off" it is ok. 
> 
> Why? How to change/reapir it ?
The problem is the 'hdmx' table. FontForge does not support it.

According to the documentation this table is supposed to contain
precomputed widths for certain (common) pixel sizes. In Vera the widths
stored in the 'hdmx' table are sometimes different from those returned
by the rasterizer.

I looked at two cases, "$" at 12ppem.
  "$" has a horizontal advance of 1303. At 12ppem this corresponds to an
  advance of 7.6, or, after rounding, of 8 pixels.
  The instructions in "$" then change the advance width to 9 pixels.

The 'hdmx' table claims the advance width of "$" at 12ppem is 8 pixels.
Which appears wrong.

I also looked at "(" at 15ppem
  "(" has an advance width of 799. At 15ppem this corresponds to an
  advance of 5.9, or, after rounding, 6 pixels.
  The instructions in "(" then change the advance width to 7 pixels

The 'hdmx' table claims the advance width of "(" at 15ppem is 6 pixels.

In both cases the hdmx table simply contains the scaled value of the
advance width and does not include the effects of the instructions. This
looks suspiciously like a bug in the font's design, but it could be
intentional.

The table does not conform to the spec in its use of the "maxWidth"
field. This should be the horizontal ppem (on a square grid, as this is,
it should be the same as the vertical ppem value), instead it is the
maximum advance width stored in the table. This is either a bug in the
font or a bug in the spec.

The docs say that the hdmx table is an optimization (which is one reason
ff doesn't bother with it). They do not say that it can be used to tune
the advance widths for selected ppem.