I got this interesting answer from MS.
Werner
--- Begin Message ---
OpenType list address: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
Unsubscribe: [EMAIL PROTECTED]
Set list to inactive: [EMAIL PROTECTED]
Set list to active: [EMAIL PROTECTED]
Message mode: [EMAIL PROTECTED]
Digest mode: [EMAIL PROTECTED]
--- End Message ---
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
