Re: [ft] Tahoma rendering differently on Freetype & Windows

[Werner LEMBERG]

Hello Lewis!


Sorry for the late reply.

> I've noticed a rendering discrepancy between Freetype and the
> Windows font engine.  I'm comparing output from Freetype 2.5.5 and
> Windows XP's native rendering.
> 
> The font in question is Tahoma 12pt rendered at 96 dpi.  Note the
> bowl of the lowercase 'a' differs between the two in the attached
> image.  IMHO Freetype's rendering isn't quite as nice.
> 
> I'm not sure if this qualifies as a bug, but to my eyes, it does
> seem to look wrong.  It's amazing how a one-pixel difference can
> sometimes be so immediately noticeable.

This case exhibits an example of bad hinting in Tahoma's `a' glyph,
obviously taylored to the Windows rasterizer by trial and error.
Using tahoma.ttf version 3.14, as delivered with Windows XP, the
bytecode for this glyph contains a SHPIX instruction that moves point
25 from the pixel border to the right by 0.25px if the ppem value is
in the range 14-16 (and 12pt at 96dpi is 16ppem).  Due to this
movement, the outline one pixel row below doesn't cover a pixel
center, thus drop-out mode becomes active – see the attached image.

Tahoma uses drop-out mode 5; the standard writes the following for our
case:

  If a scan line between two adjacent pixel centers (either vertical
  or horizontal) is intersected by both an on-Transition contour and
  an off-Transition contour and neither of the pixels was already
  turned on by rules 1 and 2, turn on the pixel which is closer to the
  midpoint between the on-Transition contour and off-Transition
  contour.  This is “Smart” dropout control.

Let's turn to the numbers.  I've just added tracing info for the B/W
rasterizing process to the current git version of FreeType; the data
below is from the call

  FT2_DEBUG=raster:7 ftview -m "a" -r 96 -e unic 12 tahoma.ttf

after pressing the `a' key in ftview to activate B/W rendering (this
needs a FreeType library compiled with debugging support).

Among other lines the tracing output shows the following:

  y=1 x=[0.043212890625;0.969482421875], drop-out=5 -> x=1 (drop-out)

The B/W rasterizer internally shifts the whole outline by -0.5px both
horizontally and vertically so that the pixel centers lie on the grid.
The question now is whether to use pixel center (0,1) or (1,1).  The
value

  (0.043212890625 + 0.969482421875) / 2 = 0.50634765625

is slightly nearer to the right pixel center (value 1), thus FreeType
switches on the right pixel.

Obviously, the Windows rasterizer uses a different method to get the
outline intersection values so that the left pixel is used...

Note that it is *not* a precision problem alone: Even if I
artificially activate FreeType's `low-precision' rendering mode for
this ppem value, the right pixel will be turned on.

> If this isn't a bug, is there a way for me to 'tune' the hinting to
> match the results produced by Windows XP's native rendering?

The direct answer is: Sorry, no, there is no possibility to do that.
The indirect answer is: You might privately modify Tahoma's bytecode
so that point 25 is moved by only 0.15px to the right, say, thus
avoiding a drop-out mode case.  However, this is nothing for the
faint-hearted :-)


    Werner