Re: [Freetype] New documents available

[David Turner]

Hello Giuliano,

Giuliano Pochini wrote:

> Yes, I didn't explain my opinion well. What I think is wrong is that
> chars with strong vertical stems already looked well with the old
> hinter. The new hinter makes them look fuzzier, while it vastly
> improves all the other characters which do not have "important" h&v
> stems ("wevyscr"). I mean... in some chars most of the "information"
> is carried by diagonals and curves, so the user notices immediately
> if they are not symmetric (vw), if there is no hole (e) or the
> thickness is wrong (ay). Other chars are different: the user expects
> that chars like "LIiPBb..." have well defined stems, and a slight
> distortion of ther shape is not annoying.
Very frankly, I'm pretty certain that this isn't true. You propose to 
basically keep the "fuzzy"
logic for "complex" glyphs, but enforce stricter alignments for 
"well-formed" ones. Well, I'd
like to know how you'd intend to categorize glyphs in this bi-polar scheme.

For example: how do you render the two vertical stems of a "D" ? Its 
left stem is
"straight", and its right one is "rounded":

 * you "snap" the left stem, and keep the right one fuzzy. Trust me, 
this will not
   look good since the stems will not have equal "width" on screen

 * you "snap" both stems, but then your "D" will have stems that will 
not look
    the same than a "C", for example. When displaying text with lots of 
characters,
    this will also become quite visible.

I have just taken a _very_ simple example. Things can easily become more 
confusing
with not-so-complex glyphs.

More generally, I consider that consistency is more important than 
contrast. That's
why hand-tuned glyph bitmaps are so much different from the original 
scaled outline,
because they have been heavily distorted to optimize both contrast and 
consistency,
at the cost of shape. This cannot be done easily in software however, so 
we need to
choose to work on other aspects...

> Perhaps the best hinter is something between FT2.0 and FT2.1 :-)) I'm
> a coder and I know how much difficult is to solve fuzzy problems
> like this. It's not much different than coding a psycoacustic
> mode for an audio encoder. Most of the work is: change something
> and try again. :)
> Ah, what I said is based on the shots you provided. I'll have time
> to make some tests in the weekend.
Ideas are interesting, but test implementations are always a lot more 
valuable :o) I would
appreciate some screenshots if you happen to work out an algorithm that 
performs what
you described.

> > 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.
> >    
>
> Hmm, I haven't an LCD monitor, so I can't try, but I think you have
> to scale the outline and *then* apply hinting to get proper alignment
> based on the 3x horizontal resolution.
>  
Nope, let's take an example. You want to generate a perfect "dotless i" 
bitmap that is optimized
for LCD screens with horizontally-laid ou RGB sub-pixels. For the sake 
of simplicity, the
glyph has no serif, and is made of _one_ simple rectangle.

Let's say that you chose a character pixel size of say 8 pixels. 
Generating the LCD-optimized
bitmaps means that:

 * you compute a linearly scaled glyph width of, say, 0.8 pixels
 * "strict" hinting (à la FT 2.0) then round this to 1 full pixel width,
    it also aligns the left and right edges to integer pixel positions
 * you inflate the hinted outline horizontally by a factor of 3
 * you render it into a gray-scale bitmap, the result can be used
    as an RGB bitmap for LCD text display

Since the stem edges were on integer pixel positions before the 3x 
inflation,
you end up with a visible rectangle that will appear on your LCD screen has
a 1-pixel wide black rectangle.

According to your technique:

 * you chose a character size of 8*3 = 24
 * the linearly scaled advance width is 0.8*3 = 2.4
 * "strict" hinting will round this to 2 pixels only
 * you render the hinted outline into a gray-scale bitmap,
    the result can be used as an RGB bitmap for LCD text
    display

The problem is that now your rectangle will only cover 2 RGB
sub-pixels (instead of 3). There is no chance that your glyph will
appear "black" (it will be instead RG, GB or BR). Worse, there
are no guarantees that its edges are aligned on integer LCD pixels
(not sub-pixels) positions. I.e. your glyph could require a two-pixel
color bitmap to be displayed. The color fringes will be visible !!

Actually, you don't even need an LCD screen to see this defect.
The RedHat 8.0 test I described recently will still work on a CRT
because the colors will be much more visible than what you'd expect..

Note that FT 2.1 doesn't perform strict hinting, except if you specifically
request them with the FT_LOAD_TARGET_LCD, FT_LOAD_TARGET_LCD_V
or FT_LOAD_TARGET_MONOCHROME flags that have been recently added.

Without strict hinting, stems edges are not strictly aligned to integer
pixel positions, which will always result in color fringes for vertical and
horizontal segments of a glyph.

Curved/Diagonals parts of a glyph will always have some unpleasant color
fringes. The whole point of ClearType and similar technologies is to apply
a small filtering to the resulting RGB pixmap to reduce these artefacts. 
However,
it will never convert a "colored" vertical stem into a black one.

Hope this helps,

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