freetype-devel
[Top][All Lists]
Advanced

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

Re: Pd: Re: Odp: Re: ttfautohint — additional feature requests.


From: Werner LEMBERG
Subject: Re: Pd: Re: Odp: Re: ttfautohint — additional feature requests.
Date: Tue, 03 Mar 2020 15:10:07 +0100 (CET)

> So you're saying the only anti-aliasing is overkill
> anti-aliasing.

?  What do you mean?

> Who thought of this as a good idea?  It is ever so slightly more
> accurate but really not worth it on lower end hardware such as
> embedded systems.  4*4 oversampling is a high priority feature
> request.  I also suggest more oversampling rates of lower priority:
> 6*5, 8*8, 2*2, 4*1, 6*1, 8*1, 2*1, oh you might as well make it
> customizable, but at high priority is 4*4 oversampling.

Sorry, but you are talking nonsense.  FreeType was developed
especially to run on embedded systems!  In particular, the rasterizers
(both the B/W and the A/A one) do work with systems that have just a
very small amount of memory.

> > FreeType doesn't do any filtering for grayscale rendering.
> > Instead, it produces *exact* coverage values per pixel with 256
> > levels.  In general this gives better results than filtering, for
> > example, if you have to render long lines with a small slope.
>
> That is pretty much what a box filter is (to take the area in each
> square).

Well, yes.  IIRC, however, rendering B/W at a much larger resolution
followed by applying a filter is *slower* than FreeType's approach of
directly computing the pixel coverage.

> But to implement that exactly would be severe overkill.  [...]

Again, you are talking nonsense.  Please get acquainted with
FreeType's A/A rendering code before doing such unfounded claims.

> If the glyph is very complex, with many intersections with pixel
> edges and corners, the method would spend a lot of time finding the
> exact value of the intersections then taking the exact integral
> value of the entire square and take 8 fractional bits of it.  This
> is a processing waste, it also makes it much more complicated to
> implement dropout control (in anti-aliasing it's supposed to have a
> more subtle effect functioning on individual samples)

There is no drop-out control in A/A mode, since it's kind-of useless.

> and you would have to completely rewire the method to disable
> vertical anti-aliasing as in the gasp flag.

FreeType doesn't support the (crippled) mode of having A/A only along
one axis.

> It makes FreeType impossible to run with anti-aliasing on embedded
> platforms.  I am marking adding 4*4 oversampling as a high priority
> now because FreeType deserves to have anti-aliasing (obviously with
> correct gamma, and only when the font enables anti-aliasing) even on
> embedded platforms that could run 4*4 oversampling but certainly not
> the integral overkill monstrosity.

Sigh.


    Werner



reply via email to

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