Re: [ft] Seeking answers on subpixel rendering

[chojin]

Hmm those didn't work, try again:

http://www.designloft.com.au/files/freetype.png
http://www.designloft.com.au/files/disksize.png


chojin wrote:
> 
> 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#a9678056
Sent from the Freetype - User mailing list archive at Nabble.com.