Re: [Freetype] New documents available

[Giuliano Pochini]

David Turner wrote:
> 
> 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.

Ehm, YOU are the author of FT :)))))

> 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.

Hmmm..., yes, I think you're right.

> >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.

I have to study the current hinter first. I'll have a look at it.

> >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.
> [...]
> 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 !!

:-/ Yes and it isn't white (or black). So stem width must be multiple of
3. But stem position only need to be integer (with strict hinting and
if there is no space between pixels on the screen). If I hint the outline
and then I scale it horizontally by a factor of 3, both stem width and
positions are aligned at 3 pixels boundaries.

> 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.

It's impossible to do, unless the width of the stem is a multiple of three. If
it is, diagonal lines are like these:

RGB   RGB
 GBR    BRG
  BRG     GBR
   RGB      RGB
    GBR       BRG
     BRG        GBR

that don't have color fringes. Well... on LCD displays everything have
color fringes. Even a simple square show a red line on the left edge
and a blue one on the right. You can't remove them (if you do, you get a
green one). It's possile to dim the effect with proper filtering, but this
isn't what FT is supposed to do, I believe.

Bye.