Comment 58 for bug 80921

On Mi, 2010-03-24 at 09:12 +0000, Anders Kaseorg wrote:

> The way forward here is to work with Cairo upstream to resolve the
> problems with users whose FreeType lacks subpixel rendering, and try get
> the patches reintroduced for the 1.9 branch.

Yes, I hope they will pick this up soon.

The test suite point is something I didn’t really agree with. If a
distribution wants to avoid the risk of patent infringement and disables
LCD filtering then it doesn’t matter if the code doing the filtering is
at a lower or higher level. The FreeType solution to higher level
libraries requesting LCD filtering then was to just render R=G=B, which
I agree is a lame way to handle it.

> > Yes, but there are still many users who revert back to the old look and
> > the old filter (e.g.: http://goo.gl/tnvl )
>
> People’s monitors, vision, and preferences differ; they always will. We
> should respect that instead of forcing our preferences upon them.

Right, everything should remain configurable. But we need a method to
configure LCD filter on an app-by-app basis. Just asking FontConfig is
not enough, is my point.

Behdad E. agrees:
http://lists.cairographics.org/archives/cairo/2010-January/018920.html

> > The reason is that you would get very bad kerning if you would enable
> > full hinting in a PDF.
>
> Hasn’t that been a solved problem for many years?
> http://fishsoup.net/articles/grid-fitting/

Theoretically yes. But not in practice. Not at all. It would look like
Fig.6. The worst part is that in a PDF you don’t get continuous runs of
text (viz. paragraphs) that the renderer is at liberty to layout itself.
You get chunks of glyphs that have precisely defined coordinates, and
unless to stick to »natural« metrics you will get bad looking text.