Re: [Devel] Kerning problem with capitals

[Werner LEMBERG]

>   Looking back at the "Re" kerning and the effect of hinting on it:
> 
> Advance for "R":  1423 font units
> "Re" kerning:    -92   font units
> 
> Total:            1331 = 7.799 pixels @12ppem
> 
> which rounds up to 8 pixels. When hinted, however:
> 
> Advance for "R":  8 pixels
> "Re" kerning:    -1 pixels
> 
> Total:            7 pixels
> 
> The difference is attributable to the rounding down of -92 font units (=
> -0.539 pixels) to -1 pixel combined with the reduction of the advance
> from 1423 font units (= 8.338 pixels) to 8 pixels by hinting.
> 
>   Just to throw this idea out: what would the effect be if we tried to
> correct for this by adjusting the kerning table when hinting? I was
> thinking something like adding the difference between the hinted &
> unhinted advance of the left glyph. For example:
> 
> Advance for "R":         1423 font units
> After hinting @12ppem:   8 pixels = 1365 font units
> Difference:              58 font units
> Corrected "Re" kerning: -92 + 58 = -34 font units (= -0.199 pixels)
> 
> There are probably more intelligent methods, though.

This is an interesting idea.  What about the following reformulation:
Get advance width and kerning in font units and add them, then convert
it to device units and compare it with the advance width in the device
space.  If the rounded difference is non-zero, apply it.

  "R" advance width plus "Re" kerning:
    1423 - 92 = 1331 font units = 7.799 pixels
  "R" advance width @12ppem:
    8 pixels
  Difference:
    0.201 pixels; after rouding: 0 pixels

   -> no extra kerning

Note that such a kerning algorithm makes only sense for a particular
DPI value (e.g. for a screen); it is not suited for WYSIWYG
applications which try to stay device independent.


    Werner