freetype
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft] Stray pixel from FT_Outline_Get_Bitmap()?


From: Werner LEMBERG
Subject: Re: [ft] Stray pixel from FT_Outline_Get_Bitmap()?
Date: Fri, 06 Aug 2010 07:47:46 +0200 (CEST)

> - Even though I'm getting different rasterization results between
>   2.3.9 and 2.3.11, I can't seem to see anything different being
>   done.  The output I attached is the same for both versions,
>   leading me to suspect I'm not looking at the relevant code.

I suggest that you build your product with both 2.3.9 and 2.3.11 and
do two parallel gdb sessions, inserting breakpoints in the sweep
functions to find out where the additional pixel gets set.  Then you
should be able to repeat it with the standalone version of the
rasterizer.

> - I found the spot(s) in Vertical_Sweep_Span() where some pixels are
>   being set (See attached), but I can't seem to find where the rest
>   of the pixels are being set.

Basically, it doesn't matter: the remaining pixels are all set to
black and are completely uninteresting.

>   I had expected the 'while' loop at the bottom to be doing it,
>   setting 0xFF into *target, but that loop is never entered...

The leftmost and rightmost 8 pixels are handled within `f1' and `f2',
respectively.  The loop is used only if the width of the current span
exceeds 8 pixels.

> - Vertical_Sweep_Drop() is never called.

Then there aren't any drop-outs to consider during the vertical sweep
phase.

> - Horizontal_Sweep_Span() is called, but doesn't do anything (The
>   'if' is never entered).

This means that there aren't any spans smaller than a single pixel
(which has the width/height of `ras.precision') to take care of during
the horizontal sweep phase.

> - Horizontal_Sweep_Drop() doesn't do anything when called (Bails
>   early due to leftmost/rightmost stub tests)

Then there aren't any drop-outs to consider during the horizontal
sweep phase.  This is strange, however, since one of the drop routines
should be responsible for your additional pixel, I believe.

> - Can you clarify what you define a 'dropout' to be, so I'm not
>   making any incorrect assumptions?

I can only cite the six possible rules for drop-out control from the
MicroSoft TrueType specification (page 245):

  Rule 1: If a pixel’s center falls within the glyph outline, that
          pixel is turned on.

  Rule 2: If a contour falls exactly on a pixel’s center, that pixel
          is turned on.

  Rule 3: 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 left-most pixel (horizontal scan line) or
          the bottom-most pixel (vertical scan line).  This is
          `Simple' dropout control.

  Rule 4: Apply Rule 3 only if the two contours continue to intersect
          other scan lines in both directions.  That is, do not turn
          on pixels for `stubs.'  The scanline segments that form a
          square with the intersected scan line segment are examined
          to verify that they are intersected by two contours.  It is
          possible that these could be different contours than the
          ones intersecting the dropout scan line segment.  This is
          very unlikely but may have to be controlled with
          grid-fitting in some exotic glyphs.

  Rule 5: 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.

  Rule 6: Apply Rule 5 only if the two contours continue to intersect
          other scan lines in both directions.  That is, do not turn
          on pixels for `stubs.'

The most tricky one is rule 4 since it is nowhere described how
exactly to form the `square'.

Figure 9 and 10 in

  http://developer.apple.com/fonts/ttrefman/RM02/Chap2.html#control_dropouts

give some helpful images, however, it doesn't describe rule 4.  [Note
that Apple uses a different numbering scheme for drop-out rules.]


    Werner

reply via email to

[Prev in Thread] Current Thread [Next in Thread]