Re: [Devel] Kerning problem with capitals

[Antoine]

[Werner: I see only your side of the discussion with
"apodtele(arroba)mccammon..."; looks like he is not subscribed, so his posts
do not pop up.]

On Wednesday, December 08, 2004 3:55 PM Robert Clark va escriure:
>
>   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.

This reminds me a lot of the problems with floating/fixed points and
rounding.

Anyway, it looks like the problem is with the way the 'kern' table values
behave. Obviously, since there is only one value (for any ppem), at small
ppem the rounding will create problems such as the ones youe are seeing
here. It is functionally the same as the roundings for coordinates, and the
proper solution is probably the same: there is a need for hinting, either
with instructions or with "indications". Even more, this already exists, as
Werner mentionned, and it is called the 'GPOS' kern feature: with the device
values, it allows for proper handling of these kind of situation. But it
also requires the whole TrueType Open machinery to work :-(.

On the other hand, the logical behaviour would be to refrain to use kerning
at such small ppem values: if the effect of rounding (half-pixel at 12ppem
are 85 Funits) is larger than the styling effects intended by the designers,
then obviously the results cannot be correct.


> 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.
>
>   Would this have unintended consequences?

I can see problems when for example the advance has been augmented (such as
for a W) by instructions, in order to achieve optical effects, like having
the same numbers of pixels both sides. If you compare the resulting
(enlarged) advance with the original design, there is a good chance that you
could apply negative kerning when it should not apply...

Your solution looks like to me an ad-hoc that happens to work here.
Unfortunately.


Question: what is the advance with 6 binary decimals (i.e., not the value
returned by TrueType, but the scaled value after the Delta have been
applied) ?
If it is greater than 8.00, it could make sense to apply the scaled (to 6
decimals, here 0.547 = 35/64) kerning value to this value, not to the
rounded ones?


Antoine