[cairo] FreeType internals in new versions of cairo

[David Turner]

> > The Freetype filters work better on unhinted glyphs than the cairo
> > filter, but the cairo filter works better (to my eye) on hinted
> > glyphs.
> > The cause is intrinsic in the design of the two filters -- the
> > cairo/Xft
> > filter is entirely intra-pixel, so a solid pixel doesn't leak out into
> > the neighboring sub-pixels while the FreeType filter (which is more
> > 'correct' from a simplistic DSP perspective) ignores pixel boundaries
> > and filters subpixels across both adjacent subpixels.
> > 
> > I haven't considered using the freetype filter for Xft, and I'm not
> > sure we should for cairo either.
> 
> Thanks for the explanation.  In that case why not adding cairo/Xft's
> filter to FreeType?
>

It's already there since 2.3.0, it's called FT_LCD_FILTER_LEGACY, there
is also a new FT_LCD_FILTER_LIGHT that uses a smaller kernel (which means
more contrast with a bit more color fringes as well).

The real problem is that there is no fontconfig-level option to select a
LCD filter yet, so the current patch just hardcodes FT_LCD_FILTER_DEFAULT.
And one more rendering fontconfig option is going make the font properties
dialog even more confusing that it currently is (not even talking about the
related changes required in other programs like OpenOffice, FireFox,
Evince, etc... :-)

I refuse to use an environment variable to do the selection, font configuration
is already too baroque for my taste, this kind of hack is exactly what
perpetuates the inconsistencies of the various Unix platforms.

Also, I don't use the bytecode interpreter on my own FreeType builds, and
the libXft filter *totally* sucks in this case, the color fringes are too
obvious to go unnoticed. At least the default filter gives consistent results,
independent of the hinting technology being used. And it also looks good on
CRT screens.

Also, I think a revamp of the desktop font rendering preferences is needed;
I have not dug the question a lot, but I'd like to replace the current scheme with
something like the following (a + denotes a radio button, a ? a checkbox,
a <XXX> is a spinner/numeric entry, and a = entries in a single combo box):

  text rendering:
    + best shapes
    + best contrast
    + use native TrueType hints
        ? optimized TrueType anti-aliasing
          disable anti-aliasing for sizes under: <NNN>

  text anti-aliasing    = standard
                        = light
                        = best for CRTs

  LCD display type      = standard (RGB)
                        = mirrored (BGR)
                        = rotated  (VRGB)
                        = rotated mirrored (VBGR)


main ideas behind this interface:

- LCD rendering is the default, unless disabled by your FreeType build,
  or if the user selects "best for CRTs"

- there is no point in having a "monochrome" rendering mode, like we
  do currently, it just looks ugly unless you have activated native
  TrueType hints, so make this explicit in the interface.

  Also, this gets rid of the big confusion in the current scheme regarding
  "light/medium/full" hinting. In "gray" renderig, medium==full, while
  for LCD rendering, "full != medium", and full hinting produces very slightly
  crisper glyphs with sometimes atrocious diagonals, and is thus not
  recommended at small sizes.

  monochrome rendering is only useful with native TrueType hints so make
  it apparent. Using a numeric value as the size selector allows best of
  both worlds.

- "optimized TrueType aliasing" really means use the libXft/legacy filter,
  but the user doesn't need to know this level of detail. It would *only*
  apply to TrueType fonts. Possibly, we would want to filter the fonts it
  would apply to, because there is a large number of fonts available with
  none-to-average hints that render more poorly with this filter.

- if the bytecode interpreter is not activated in your FreeType build,
  the "use native TrueType hints" line and its dependent elements are
  gray-ed out. If the user hovers it, a popup explains that this is due
  to patent reasons

- "LCD Display Type" would be gray-ed out when "best for CRTs" is
  selected, of if the build doesn't support LCD rendering (need a
  way to explain that, probably a popup on hover)

All of this is doable, but would probably require a new fontconfig
enumeration option. I'll try to do a prototype one day...

Also, I wonder if there is a way to query the X Server about each screen's
orientation and LCD matrix ?

- David

> 
> -- 
> behdad
> http://behdad.org/
> 
> "Those who would give up Essential Liberty to purchase a little
>  Temporary Safety, deserve neither Liberty nor Safety."
>         -- Benjamin Franklin, 1759
> 
> 
> 
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://cairographics.org/cgi-bin/mailman/listinfo/cairo