freetype-devel
[Top][All Lists]
Advanced

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

[ft-devel] Fw: [OpenType] Re: rounding bug in MS TT rasterizer


From: Werner LEMBERG
Subject: [ft-devel] Fw: [OpenType] Re: rounding bug in MS TT rasterizer
Date: Sat, 01 Apr 2006 06:40:29 +0200 (CEST)

I got this interesting answer from MS.


    Werner

--- Begin Message --- Subject: [OpenType] Re: rounding bug in MS TT rasterizer Date: Fri, 31 Mar 2006 11:48:35 -0800
OpenType list address: address@hidden

Hi Werner,

This sort of thing happens all the time in the TrueType rasterizer, and
it relates to precision and the order of operations.

In the particular example below, the x value of point 25 is 9.5 (608),
and the interpolate instruction wants us to add 4.4978769 to it. With
the 26.6 fixed point precision of the TrueType rasterizer, 4.4978769 is
represented as 4.5. When added to the 9.5 we get 14 (896). Since we are
rounding to half grid, the following MDAP rounds us to 14.5, which then
gets DELTA'd to 13.5. 

I don't consider this a bug nor incorrect, the TrueType hinting engine
is consistent in how it deals with rounding and precision.

In the Microsoft implementation of the TrueType rasterizer we based the
definitions of precision and rounding _in the interpreter_ on the code
originally developed by Sampo, Mike Reed, & al. at Apple. Microsoft did
make some changes in how we scan converted quadratic Beziers, which did
lead to some pixel differences, but we considered that acceptable. Other
changes, such as dealing with composite transforms have been
synchronized with Apple.

I see the TrueType specification as a font creator's guide and not an
implementation guide. The later would take a significant amount of time
to document.

Greg

> Werner LEMBERG wrote:
> 
> Sergej, Paul,
> 
> 
> from time to time we from the FreeType team get reports that our
> engine doesn't rasterize certain TrueType glyphs correctly.  The most
> noticeable and disturbing case is glyph `W' in the font `arialuni.ttf'
> (see attached image).  Careful inspection has shown that the very
> problem here (and in other cases) is a rounding bug in the MS
> rasterizer which the bytecode instructions of arialuni.ttf explicitly
> circumvent.
> 
> Rogier van Dalen writes:
> 
>   I see the very same asymmetry on my rasterizer.  Point 25 is the
>   problematic point.  I've calculated it all; Microsoft rounds the
>   x-coordinate 895.455782 up to 896 (14.0) in an interpolate
>   instruction.  It is then rounded to half a pixel, to 14.5 according
>   to the MS interpreter, to 13.5 according to FreeType's and mine.  A
>   delta instruction then moves it left to 13.5 (12.5).  To conclude,
>   the MS rasterizer does faulty rounding here, and a delta instruction
>   could have been spared if they had implemented it properly.
> 
> I'm quite sure that this rounding bug has historical roots and won't
> be fixed -- many, many fonts would render worse.  This means that we
> have to emulate the behaviour of the MS rasterizer to get `correct'
> results.
> 
> Can you tell us more about this problem?  Which instructions are
> affected?  What exactly is the reason for the incorrect rounding?
> 
> Since so many fonts rely on this `feature' it should be documented --
> ideally in the TrueType specification.
> 
> 
>     Werner
> 
> 
> PS: I wonder whether Apple's rasterizer renders this glyph similar to
>     MS Windows...


Subscribe: address@hidden
Unsubscribe: address@hidden
Set list to inactive: address@hidden
Set list to active: address@hidden
Message mode: address@hidden
Digest mode: address@hidden

 

--- End Message ---

reply via email to

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