freetype-devel
[Top][All Lists]
Advanced

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

Re: [Devel] Re: [Freetype] Bad truetype rendering? still not satisfied


From: David Turner
Subject: Re: [Devel] Re: [Freetype] Bad truetype rendering? still not satisfied!!
Date: Wed, 20 Feb 2002 22:24:58 +0100

Hello Brian,

Brian Stell a écrit :
> 
> Robert Schelander wrote:
> >
> > After comparing the results with an old freetype1 I'm
> > again not really satisfied.
> >
> > [FreeType2] Rendering of seperate letters is now more or
> > less ok with activated bytecode interpreter,
> 
> (I assumming that the FreeType2 glyphs here were rendered
> with the interpreter as indicated by the statement above.)
> 
> Even with the bytecode interpreter the FreeType2 glyphs are
> far *blurrier* than the FreeType1 glyphs. Use 'xmag' and
> compare the pixels between the 2 'E' glyphs:
> 
>               ===========
> ##########    ###########
> #             #=
> #             ##
> #             ##========-
> ##########    ##========-
> #             #=
> #             #=
> #             #=
> ##########    ###########
> 
>
I think the blurr is caused by sub-pixel text positioning, which
shouldn't happen if your text layout code is correct. 

Do you have evidence that properly laid-out text is blurrier
in FT2 than in FT1 when both use the bytecode interpreter ??

I'd be extremely interested in seeing these, I can't reproduce
them with "ftview"..

 
> > but spacing between ':' and '.' characters makes still not a
> > good result. Look at the link and compare:
> > http://members.aon.at/schleppealm/rendertext4.png
> 
> I vagely I remember hearing that FreeType2 is more mathmatically
> correct. My guess is that being more mathmatically correct has
> some kind of relationship with the blurring and changed spacing
> for the colon and period glyphs.
>

Hummm... there is probably a mix-up of issues here. I think that
the following assertions should be assumed correct:


  - the FT2 anti-aliasing rasterizer, i.e. the code in charge
    or converting a vector outline (that may be hinted or not)
    into a gray-scale bitmap is more mathematically correct
    than the one in FT1.

    That's because it uses an analytical algorithm to compute
    the gray level (i.e. direct computation of pixel coverages),
    instead of producing a scaled bitmap then filtering it..

    It also uses 256 levels of gray, instead of 5 (like in FT1)


  - the FT1 and FT2 monochrome rasterizers are slightly different
    and seem to produce slightly different results for a very small
    minority of glyphs. I haven't studied this problem very hard,
    mainly because it doesn't seem to be annoying to anyone..


  - the FT1 and FT2 TrueType bytecode interpreters should produce
    identical results, when it comes to hinting vector outlines.    
    the resulting monochrome or anti-aliased bitmaps should then
    be extremely similar..


  - properly laid-out text rendered by FT1 or FT2 (with the bytecode
    interpreter), should generate texts that are _highly_ similar both
    in proportions and quality


  - the results of the FT2 auto-hinter are lower than that of the
    patented TrueType bytecode interpreter (except for certain
    fonts with really bad hinting :o)

    Latin sans serif fonts generally give satisfying results, except
    mainly with accented characters (if the glyph isn't defined as
    a composite within the font).

    For serifed and ornamental fonts, results are between average
    and poor depending on many subtle parameters that I haven't
    mastered yet :o)

    There are also a few annoying things that should be fixed
    in a near future (e.g. inflexion points seem to require
    special interpolation status, like in the middle of an
    "S")

    In all cases, a auto-hinted glyph will likely be different from
    its bytecode-hinted image at small pixel sizes.


  - the process of hinting, no matter which method is used, tends
    to _modify_ glyph outlines to make their images more readable.
    this implies shifting and re-scaling stems and other subtle
    things.

    In other words, it's really a means of destroying the glyph's
    original outline to find an approximation that will be more
    pleasant to the eye..

    The only way to get glyph images that look like their original
    design at all sizes is simply _not_ to perform hinting. This
    is what Nautilus or the Apple MacOS X UI do (most of the time).

    This generally results in blurry text though, except in Apple's
    case, since they seem to use special filtering techniques to
    increase the final glyph image contrast and make it more
    readable in the end

    (though significantly less contrasted than hinted glyphs.. this
     is extremely visible for serifed fonts at small character sizes)


  - finally, the postscript hinter provided in latest releases of FT2
    produces results of varying quality, depending on the hints
    themselves present in the font..

    For fonts with no or low-quality T1 hints, the auto-hinter will
    always produce better results.

    For average-quality T1 hints, the postscript and auto hinters should
    produce nearly identical outputs.

    For high-quality hints, the postscript hinter will probably always
    out-perform the auto-hinter..


    Note that there are still ways to improve the postscript hinter in
    the future. It doesn't work as well as T1Lib for a certain number
    of fonts, including the Ghostscript fonts which unfortunately seem
    to have some pretty bogus hints in certain of their glyphs..


I hope this helps..


Regards,

- David Turner



reply via email to

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