[Top][All Lists]

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

Re: [Freetype] Re: Glitch with monochrome renderer

From: Rogier van Dalen
Subject: Re: [Freetype] Re: Glitch with monochrome renderer
Date: Wed, 19 Feb 2003 09:32:40 +0100

From: "David Turner" <address@hidden>
> Soeren Sandmann wrote:
> > There is a small glitch using the monochrome renderer in FreeType
> > 2.1.3. This image
> >
> >
> >
> > shows a magnified version of the small 'w' of the Trebuchet font
> > rendered in monochrome with the bytecode interpreter enabled.
> >
> If that is true, this simply means that the bytecode contained within
> these fonts relies on the exact fixed-point computations performed by
> the original Apple/Microsoft TrueType interpreter.
> Certain things are incredibly influenced by rounding, like diagonals
> when computing point by performing divisions and dot products.
> Though I have spent considerable time in my youth to get the computations
> "right" for Arial/Times/Courier, I have not the will to do that again to
> fix a few small glitches in more recent fonts. Again, a kind volunteer is
> needed to perform this massive task.

Hello David and Soeren,

Looking at Trebuchet "w" with my TrueTypeViewer
( I do not think this is a problem with
the interpreter, but rather with the rasteriser, and more specifically, with
the drop-out control. The stem that produces this glitch is very thin and
has an intersecting line (this you can also see on FreeType with AA
We are talking about Trebuchet at 11 ppem, aren't we?

A glitch I would say stems from rounding errors can be seen in Tahoma "w" at
9 ppem.

I don't think, however, this has to be repaired: the fact that Microsoft
fonts have been tested and tweaked for the MS rasteriser doesn't mean that
FreeType's implementation is incorrect.



reply via email to

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