Re: [ft] Seeking answers on subpixel rendering

[chojin]

David,

I can't thank you enough for your detailed response. It answered a lot of my
questions and has been extremely helpful.

I think you are very correct about the screen calibrations and the fact that
you mention mac screens confirms it, I was using a mac screen for some of
the testing (and also a Benq).

Interestingly, in the screenshots you provided, I personally can't stand the
last two (lite grayscale/lcd) screenshots you've taken, and prefer the first
two (the subpix version is actually quite nice). If you look at the stems in
the 'lite' shot, a lot of the glyphs have different stem widths (some for
example, spanning two pixels at 50% black, some spanning one stem at 100%
black). Kerning is mixed on both, with some kerns in the 'normal' screens
being more comfortable, and some on the 'lite' being a better fit. It's that
kind of thing that personally drives typophiles like myself mad trying to
work out. I think basically, the overall letterforms and spacing looking
right are more important to designers/typographers than excessive hinting
which can produce more readable but ugly, mishapen letters.

The patches you have provided have helped somewhat (I did find them
earlier), after a great deal of messing about and recompiling several times
I am fairly comfortable with my fonts at the moment, I've uploaded examples
of my desktop also.

http://www.nabble.com/file/7429/freetype.png 
http://www.nabble.com/file/7430/disksize.png 

Some of the fonts, converted with fontographer from my osx machines (so I am
allowed to do this... I think), have come out the best. As an aside about
qt's rendering, it's fairly unusable for me, I know you have
patches/wrappers to make everything use freetype though and will investigate
these further.

Thankyou very much for your time and patience.

Rob


David Turner-5 wrote:
> 
> Hello Chojin,
> 
> On Thu, 22 Mar 2007 21:31:53 -0700 (PDT), "chojin"
> <address@hidden> said:
>> 
>> I am a long time windows user who has, around once a year for the past 6
>> or so years, tried to make an effort to switch my business (graphic
>> design
>> and web development) over to linux and the one thing consistently holding
>> me
>> back is font rendering... freetype is the best attempt so far, but is SO
>> far away from windows and osx.
>> 
>> I have done my best to educate myself on freetype and so on, and one of
>> the few things I'm left speechless about is subpixel fonts. (Yes I am
>> using
>> an LCD, yes the bars are RGB, yes subpix is calibrated correctly for it -
>> this is in regards to subpixel rendering as a method itself and not my
>> specific implementation).
>> 
>> Basically, it does nothing. It's a massive scam. It just produces slight
>> annoying color ringing around fonts and hinders readibility. As a test,
>> here is a cooltype rendered font, then the same paragraph below it in
>> grayscale:
>> 
>> http://www.nabble.com/file/7364/whysubpixelsucks.png 
>> 
>> As you can see, the grayscale is far more comfortable to read, with no
>> annoying ringing. Yet, when subpixel rendering is turned off in freetype,
>> the actual RENDERING changes. Why is this? Shouldn't subpixel just
>> convert some of the antialiasing into fringe colors, corresponding to the
>> adjacent rgb bars?
>> 
>> What I am saying is, shouldn't type libs focus on antialiasing and
>> kerning (which in themselves have a long, long, long way to go before
>> they hit
>> the same level that win/osx have) and drop the (possibly patent
>> infringing)
>> subpixel stuff? Does the bytecode interpreter have anything to do with
>> this kind of antialiasing? Could an autohinter produce the quality of
>> antialiasing shown above?
>> 
>> Maybe I am confused but that's why I posted here - the best place to get
>> an answer would be from freetype users themselves.
>> -- 
> 
> Well, well, I don't know exactly where to start, so I'll start randomly.
> The short version is that this is an on-going battle, and that FreeType
> probably
> isn't to be blamed for most of the issues you're facing, and that a
> solution
> is probable though I wouldn't bet to see it deployed soon.
> 
> * First, on the topic of LCD filtering itself: its effect depends on a lot
> of
>   things, like the fabric of your LCD screen, your overall display gamma,
>   the text color/background being used, the eye-screen distance (really)
> and
>   your own perceptual sensitivity to the color "fringes" themselves.
> 
>   I've tried to see the example image you posted with two different
> monitors.
>   On my pretty old 13" laptop, the LCD text is clearer than the gray one
> that
>   appears more blurry. However, on my work 24" Dell, the difference is a
> lot
>   less significant. In no way is the "gray" text "far more conformtable"
> to
>   read to me.
> 
>   Similarly, I have a 15" MacBook Pro for work. Its display is very bright
> and
>   colourful, but it displays LCD text with very visible color fringes to
> my
>   eye (and the "gray" text is blurry anyway). However, when I hook up the
> same
>   computer to my 24" Dell, everything looks really good.
> 
>   I have tried to play with display settings to change that, but can't
> reproduce
>   the same quality on the Mac's screen in any way. Some other people don't
> seem
>   to see any colors on the Mac.
> 
>   So I don't agree it's massive scam, it just depends on lots of factors.
> 
> 
> * Second, you are true that LCD filtering and hinting are two separate
> issues.
>   The fact that you select "LCD rendering" in Linux and see some changes
> in text
>   rendering come from libraries like libXft, Cairo or Qt that use FreeType
>   and your font settings incorrectly.
> 
>   Another problem is the design of the font preferences dialog which is
> simply
>   misleading, and from a user-point of view, buggy. However, that's a
> different
>   problem I would prefer not to address here.
> 
> 
> * regarding the very visible color fringes you're seeing in Linux, they
> come from
>   the fact that the default LCD filter being used in libXft and Cairo was
> designed
>   solely for the case of TrueType fonts with very high-quality bytecoded
> hints.
> 
>   this means that you need to enable the bytecode intepreter to get
> anything
>   sensible out of it. If you don't, you'll see these atrocious blue/yellow
> fringes
>   all over the place. Even if you do, you'll see them on a lot of fonts
> that don't
>   have high-quality hints anyway.
> 
>   I've provided patches to these libraries to get rid of this problem a
> long time
>   ago. For some reason, these have not been integrated in the respective
> libraries.
>   See http://david.freetype.org/lcd/ for details.
> 
>   A better filter works consistently across all fonts and hinting modes,
> though it
>   can produce slightly more blurry glyphs in the high-quality case. recent
> versions
>   of FreeType provide such a filter, but it is not used by Cairo and
> LibXft yet.
> 
> 
> * As an example, here are four snapshots of my current desktop. They
> represent the
>   same content rendered through four different hinting/rendering
> combinations and
>   should give you an idea of what is possible with FreeType:
> 
>     http://david.freetype.org/freetype/example-normal-gray.png
>     http://david.freetype.org/freetype/example-normal-lcd.png
>     http://david.freetype.org/freetype/example-light-gray.png
>     http://david.freetype.org/freetype/example-light-lcd.png
> 
>   note that some pretty important label displacements between versions,
> these come
>   from what appears a bug in Firefox which is somewhat confused when asked
> to reload
>   a page after you alter your font settings (it does that all the time,
> even on the
>   simplest pages).
> 
> * My personal favorite is to use the "light" hinting mode, with or without
> LCD filtering
>   depending on the screen I'm using (definitely on my home laptop, not on
> the 24" Dell).
>   The rendering is very close to what you'll get with Mac OS X, with the
> exception that
>   you won't see sub-pixel positioning. 
> 
>   Most people won't see a difference anyway. And though it's possible to
> do that with
>   FreeType (the auto-hinter even supports sub-pixel positioned hinting,
> though this
>   is not usable from the API at the moment), it's the rest of the graphics
> stack on Linux
>   that is not ready to use it.
> 
> * I still force myself to use the "normal" hinting mode, since I like to
> eat my own dog
>   food to be able to improve it as much as possible.
> 
> * Regarding matching ClearType rendering, this is more subtle than it
> seems because:
> 
>   - ClearType in Vista is different from ClearType on XP; at a minimum,
> the LCD filter
>     can be different, and it seems Vista supports sub-pixel positioning
> now (both in 
>     LCD and "gray" modes)
> 
>   - supporting ClearType-like rendering is possible using FreeType, but
> must be essentially
>     done on top of it. Basically you need to produce bytecode-hinted text
> at 3x the horizontal
>     resolution (which is different that dilating 3x horizontally glyph
> outlines loaded at 1x
>     the resolution), then apply the LCD filter. There are also a few
> interpreter bytecodes
>     whose behaviour changes, but nothing too drastic.
> 
>     there are however some issues regarding the sub-pixel advances and how
> they can be
>     used to perform text layout.
> 
>   - more importantly, Microsoft has several patents covering the ClearType
> "technology"
>     (which do not amount to a lot of things, by the way). Some of the
> claims in these
>     patents are very broad and likely have prior art. For example, I've
> seen sub-pixel
>     text rendering on delta-nabla LCD screens a *long* time before
> ClearType was
>     released.
> 
>     however, certain claims might not be easily invalidated, and it's
> unknown at the time
>     wether it's possible to implement something that doesn't infringe on
> them. Also, the
>     prior art, if it exists, need to be clearly identified.
> 
>   - since FreeType is used in many embedded devices, I don't want to
> enable a feature that
>     could cost unsuspecting developers millions in a few years when
> Microsoft feels it's
>     "payback" time. That's why the LCD filtering in FreeType is disabled
> in all default
>     builds and you need to enable it manually (just like the bytecode
> interpreter).
> 
>     It seems that libXft and Cairo authors, which perform their own LCD
> filtering in their
>     respective code, don't feel it's important. that's their point of
> view, and I don't
>     share it.
> 
>     Also, because of the patents issue, I'm not going to lose my time on
> this "feature".
>     If someone wants to implement it in Cairo/LibXft/Qt/Whatever, please
> do it; I don't
>     really care...
> 
> Voilà, I don't know if this answers all your questions, but it's already
> plenty of info
> to digest. I advise you to lobby the Cairo/LibXft authors if you want
> better rendering
> results...
> 
> - David Turner
> - The FreeType Project  (www.freetype.org)
> 
> 
> _______________________________________________
> Freetype mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/freetype
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Seeking-answers-on-subpixel-rendering-tf3451933.html#a9677946
Sent from the Freetype - User mailing list archive at Nabble.com.