[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