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" >> <[EMAIL PROTECTED]> 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 >> Freetype@nongnu.org >> 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. _______________________________________________ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype