freetype
[Top][All Lists]
Advanced

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

Re: [Freetype] New documents available


From: David Turner
Subject: Re: [Freetype] New documents available
Date: Thu, 07 Nov 2002 16:25:59 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020910

Hello,

Giuliano Pochini wrote:
On 07-Nov-2002 David Turner wrote:

Hello,

  you'll find a new version of the "smooth hinting" document at
  the following address, including screenshots:

    http://www.freetype.org/hinting/smooth-hinting.html


Interesting. The screenshots show quite well what has been
changed and FT2.1 looks better overall than 2.0. Text brightness
is now constant in all characters, which is fine, but the loss
of crispness is strange and IMHO can be avoided. Vertical stems
are ofter drawn with a "shadow" at their side. Look at one of
these chars "hlikdtnLE", the stem is full black, so only a side
of it has been grid-aligned. It only happen with vertical stems,
while horizontal ones are perfect. Also round parts don't have
that the shadow, strange. You can try to enforce better
alignment of strictly vertical stems.
>
Alas, this is not so easy. Allow me to quote the web page itself:

""More technically, "crisp" text is created by distorting the
  original scalable character outlines so that their most important
  vertical and horizontal edges are **strictly** aligned to the pixel
  grid.

  This has the benefit of creating high-contrast text be it on
  monochrome or anti-aliased modes. However, this high distortion also
  means that certain features of the font become *out* *of*
  *proportion*, like *diagonals* and certain *curves*.

  The new "fuzzier" text is created by minimizing outline distortion,
  even though we still perform grid-fitting and stem width/height
  quantization to optimize the output. The fuzziness is not very
  important, and the *overall* *legibility* and *clarity* of the text
  is still very high. Moreover, the final result looks a lot
  more *consistent* and *polished*. """

You see, strong alignement on the pixel grid is possible, since that's
what 2.0 did. However, this has the sad "benefit" of making your
diagonals really look strange, since they often will appear fatter
or thinner than the horizontal/vertical stems, and this results
in text that is unpleasant to read and looks *very* unprofessional.

That why 2.1 does things a bit more fuzzy. Because it distorts the
outline less, it generates text that has "constant brightness", and
I regard this as a *good* thing. I prefer to optimize the output
to make the whole text consistent rather than optimizing for only
80% of the glyphs, which is unfortunately *very* visible, even to
un-trained eyes :-)

"g" looks better with FT2.0, but it's probably a random quirk.

Yes, it's a random quirk. It's pretty hard to come with a auto-hinting
algorithm that works with all cases equally well :-)

Why did you write an hinter for LCD sub-pixels ?  I think that
rendering text at triple width works just fine with the default
hinter, or am I missing something ?

First of all, you don't "render at triple width". You hint the outline
at the *normal* width, and scale the resulting vector horizontally or
vertically by a factor of 3. This is very different than using a
triple character width.

With 2.0, this aligns all stem edges to the pixel grid, and you're
happy.

With 2.1, strict stem edge alignment is not guaranteed with
FT_RENDER_MODE_DEFAULT, which means that you'll end up with glyphs
that will contain many color fringes, and this is unpleasant.

To test it: run RedHat 8.0, install latest FreeType CVS on it,
and tweak the font control panel to enable "LCD-optimized"
rendering. Look at the pretty colors everywhere :-)

That's why FT_RENDER_MODE_LCD and FT_RENDER_MODE_LCD_V were
introduced. They specifically request strict stem edge alignment
in the horiziontal and vertical directions (respectively), in
order to get something usable for LCD display.

However, this requires a tiny change in libXft/libXft2 to
use the feature correctly. And I didn't produce a patch yet.

By the way, FT_RENDER_MONOCHROME forces strict stem edge alignments
on both directions, so it could also work for LCD-optimized rendering.

Sadly, I thought that the web page did explain these issues pretty
well. Are you sure you read it, or did you just look at the
screenshots without looking at the text ??

Regards,

- David Turner
- The FreeType Project  (www.freetype.org)




reply via email to

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