Weekly Edition
Return to the Development pageSponsored link
Serve your customers, not your servers, with VERIO Linux VPS. Full-access test-drive here.
| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Font rasterization techniques
(Log in to post comments)
Font rasterization techniques
Posted Sep 24, 2007 17:34 UTC (Mon) by elanthis (subscriber, #6227) [Link]
This story was already posted here a couple months back.
Font rasterization techniques
Posted Sep 24, 2007 17:55 UTC (Mon) by elanthis (subscriber, #6227) [Link]
Actually, it was probably another site I saw this on before - ignore me. :)
Just one minor error
Posted Sep 24, 2007 19:21 UTC (Mon) by khim (subscriber, #9252) [Link]
Great article - perhaps it'll lead to the better font handling eventually. Just one minor error. "I'm not sure, but probably the MS Word developers calculate the glyph advance at a high resolution for “unhinted” glyphs" - this is just simply wrong. We do know what they do to calculate distance! They are using printer's context! That's why DEVMODE stucture is there in OOXML! This is the only way to produce consistent output from MS Word on the same system. Want to print 1000-pages document with the same layout on different printer with different resolution ? Well - you are out of lack: Word will repaginate the text and you'll get different line and page breaks!
Well-known ages old problem, still true today. Of course nowadays typical resolution of printer is 600dpi and this mitigates the problem somewhat but select old 144dpi 9dot matrix printer in your system as default - and watch how layout of big documents goes to hell.
Just one minor error
Posted Sep 24, 2007 20:04 UTC (Mon) by AJWM (subscriber, #15888) [Link]
That (mis)behaviour also causes another problem with emailed docs -- Word sits there for several minutes trying to contact the specific printer that the doc was saved with before giving up and asking you if you want Word to keep on trying. Sheesh.
(It doesn't always do this, I've never figured out the dependency. Maybe if there's a network printer involved or something. Or if certain fonts are used.)
Font rasterization techniques
Posted Sep 24, 2007 22:07 UTC (Mon) by jengelh (subscriber, #33263) [Link]
Subpixel rendering is really ugly on CRTs. Even at 1280x1024 I notice the red/green tint at the edges. (Much like some people being able to notice 60,65,70 Hz flicker of CRT.)[Remembering Vista Beta2, disabling ClearType did not even deactivate it everywhere. Ugh.]
Font rasterization techniques
Posted Sep 24, 2007 22:15 UTC (Mon) by jwb (subscriber, #15467) [Link]
OK, but why would you use subpixel rendering on a CRT? A CRT doesn't _have_ subpixels!
Font rasterization techniques
Posted Sep 24, 2007 22:19 UTC (Mon) by jengelh (subscriber, #33263) [Link]
I would of course not, but see the Vista part of my previous comment.
Font rasterization techniques
Posted Sep 24, 2007 22:32 UTC (Mon) by k8to (subscriber, #15413) [Link]
I thought the term "subpixel rendering" referrred to a general idea. That is, using a model of the image data at an arbitrary or higher resolution, and then rendering it to the actual display in some smart way, be it antialiasing or tweaky LCD color hacks.
I've yet to read the article so maybe he or she is using the term only to refer to the LCD hacks.
Font rasterization techniques
Posted Sep 24, 2007 23:27 UTC (Mon) by quotemstr (subscriber, #45331) [Link]
The author is using "subpixel positioning" to refer to laying out characters with better than pixel level precision, and I think it's an excellent idea.
Font rasterization techniques
Posted Sep 25, 2007 1:43 UTC (Tue) by k8to (subscriber, #15413) [Link]
Yes, after having read the entire text, I see his entire thrust is that text, that is characters, need not be pixel-aligned. For a great many applications this type of layout seems superior, although I cannot help but feel the surrounding text provided by my browser is easier to read than any of his examples, though they may be more elegant.
In essence I think crappy pixel aligned text still has its place (such as in this edit box into which I am typing), but when the goal is to have any sort of font and page-layout fidelity, I'm convinced of his arguments.
Font rasterization techniques
Posted Sep 27, 2007 21:06 UTC (Thu) by Ross (subscriber, #4065) [Link]
It is actually much easier to do it that way, but it leads to text which looks blurry and lightened (try zooming out of a screenshot in an image viewer and notice how the text turns gray). (This could be accomplished with supersampling or vector-based calculation.) You get less spacial aliasing in exchange for blurriness.
It's a classic sampling theory problem.
Subpixel rendering of course refers to not treating the different LCD pixel elements as if they were at the exact same locaiton. You get better resolution at the cost of color fringing.
Some comination of the approaches is likely to produce the best results, which is why fonts have complex hinting attributes for handing pixel alignment at different sizes.
But this entire area is a patent minefield so Free Software developers don't have all that many options.
Amazing
Posted Sep 24, 2007 22:48 UTC (Mon) by ncm (subscriber, #165) [Link]
It's amazing how easy it is to see the differences he calls out, and how much better, how much easier on the eyes, his text is.
These days, code should assume it's rendering for an LC display unless told otherwise.
I hope Gnome 2.22, and the next Gecko, get all this right. I recall time after time trying out lists of default typefaces in browsers, disappointed each time a mature, well-designed face came out blotchy and uneven, often with some strokes invisible; and ultimately settling again on Vera just because it doesn't look actively bad.
Amazing
Posted Sep 25, 2007 3:26 UTC (Tue) by mjg59 (subscriber, #23239) [Link]
A large part of the problem is that our fonts are simply not designed for that sort of use right now. Turn on subpixel anti-aliasing and either disable hinting or set it to slight. Now type some content in Vera Sans at a moderate pixel height (15 pixels or so is probably enough, but 20 should also show it). Marvel at how the vertical strokes suddenly gain offensively obvious colour fringes.
There are some tricks we can play with different colouring algorithms for subpixel anti-aliasing which can improve the perceived rendering of the font in many cases, but moving to a model where we don't try to align the glyphs to whole pixel boundaries is going to require a good set of fonts that cope with that model.
Font rasterization techniques
Posted Sep 24, 2007 23:13 UTC (Mon) by alankila (subscriber, #47141) [Link]
The article is rather depressing because good font rendering is so complicated. Here's a bit of a summary where Linux needs work in.
Firstly, truetype hints. Microsoft fonts are apparently badly hinted for use with freetype, for instance the curve of 2 tends to vanish in times new roman or the diagonal stem at z. This is because the algorithms differ on the ways they handle thin areas (especially those that are reduced to just lines): microsoft version always renders them 1px wide, but freetype can make them vanish completely. This looks like an artifact.
For some fonts, therefore, it would seem that freetype would have to forget calculating areas for things that are too narrow and simply opt to render them at some minimum width. Of course, this only needs to be done for fonts intended for a different rendering engine from freetype, because fonts with freetype as target probably make use of this.
To properly blend the fonts against background, one should compensate for the gamma of the display. Doesn't seem likely to happen any time soon, this should probably land into X server or preferably GPU hardware. It's no good to gamma correct the ARGB pixmap generated by freetype because freetype doesn't know what kind of background it will be applied on, so it has to go into the blending step. It's a simple summation now; the gamma-correct path should perform linear blending in the physical intensity and needs fractional roots and exponentiation to do that (read: is slow).
If you highlight a piece of text with mouse, simple invertion of colours will not do, again because of gamma. Everything needs to be redrawn for the background.
Then there's the trouble with kerning and getting accurate advance widths for text. (The agg guy seems to suggest abolishing horizontal hinting completely for accurate representation of width. Well, that's good idea if you care about that sort of thing, but at the same go, you'll get lots of variants for every letter, making glyph pixmap caching more memory consuming... and if you don't do gamma correction right, these glyphs will not look even nearly identical because a pattern like 0x00 0xff has very different brightness from 0x80 0x80, although the average values for both patterns are the same. Yet you could naively get the latter from the former if you imagine that a pixel is shifted to left by half a pixel, and therefore occupies two slots equally. For a gamma 2.0 display, the correct brightness is approximately 0xb4.)
As an aside, most LCD screens seem to have horrible scalers because they ignore gamma issues, and as a result have noticeably different brightness for features that are modified by the scaling. Ideally, scaling only makes things blurrier but shouldn't affect pixel intensity. In practice, things often look darker when scaled. Across a wide range of shades, it seems that
LCD displays do not really have a constant gamma either, but it's often not very big deviation from some value such as 2.0.
Even worse, everything that needs to know the precise position of a glyph needs to become aware of the fractional positioning of everything. And it still won't be perfect. For instance, in a browser, all elements need to be snapped to pixel grid, so there's always going to be compromises, uneven spacing between words or even letters, etc. (Think <span>this</span> <span>that</span> etc.) I imagine fixing this means an avalance of api changes, and might even introduce incompatible things like elements that you can't hover on with mouse because they are narrower than 1 pixel and fall between the gaps.
All in all, subpixel rendering is much more complicated than just colouring the fringes of fonts. It touches *everything* on the system when properly done. And it absolutely needs all that gamma correction crap if you are serious about not ever wanting to see any fringes.
In conclusion: Here's to hoping that 200 dpi displays (and/or 16-bit gamma 1.0) screens or something come one day and solve the problem for us. I don't have much faith in that it will ever get properly solved by software.
To put it bluntly, the problem is too intricate to understand, depends on features not in user control (display gamma value, and its constantness), imposes performance penalties to all users (unless GPU vendors rush to implement gamma-corrected blending), and the benefits (beautiful font rendering) are in the end rather small.
Font rasterization techniques
Posted Sep 24, 2007 23:44 UTC (Mon) by quotemstr (subscriber, #45331) [Link]
I don't see why a browser has to snap glyphs to a pixel grid. Why can't it just render the text like any other application would? If you really do need pixel-level precision (say, a span with a mouseover effect), you can just use a pixel-level approximation for that purpose. The text rendering itself can still use subpixel positioning.
Also, "colouring the fringes of fonts" isn't mutually exclusive with the article's proposed technique. I don't think you fully understood the article. Sub-pixel <b>rendering</b>, the "colouring the fringes," is just one kind of anti-aliasing. It gives you a higher effective resolution on an LCD monitor, but there's no reason the author's technique wouldn't work with conventional antialiasing too.
I'm with you when it comes to gamma correction though; it'd be nice for that to be implemented consistently and correctly throughout the OS. (Though I don't see why you couldn't use a 256*256 lookup table for the blending instead of on-the-fly exponentiation).
As for the benefits: I, and I suspect most people reading this, spend a great deal of time reading computer displays.
Font rasterization techniques
Posted Sep 25, 2007 10:42 UTC (Tue) by alankila (subscriber, #47141) [Link]
> I don't see why a browser has to snap glyphs to a pixel grid.
I didn't really say it would have to. All I said was that HTML *elements* (tags) probably have to. When I talked about in-word snapping, I meant for HTML like t<span>h</span>i<span>s</span>. As to whether elements could be positioned with finer than pixel granularity, it'll likely take a long time, if ever, before that happens.
> Also, "colouring the fringes of fonts" isn't mutually exclusive with the
> article's proposed technique. I don't think you fully understood the
> article. Sub-pixel <b>rendering</b>, the "colouring the fringes," is just
> one kind of anti-aliasing. It gives you a higher effective resolution on an
> LCD monitor, but there's no reason the author's technique wouldn't work
> with conventional antialiasing too.
On this point you are absolutely correct. Subpixel rendering isn't really the focus of the article. It is the focus for me, because I hunger for higher DPI displays, and subpixels have a chance to triple the value in one direction. I confess I have not read the article for months, but I did read it attentively back then and even ran his wine binaries showing the alternative font rendering.
However, in the context I used the phrase you quoted above, I was actually talking about the fact that a lot of work is required before Linux font support raises to the level of the other two operating systems. The "cleartype rendering" is generally taken to be the highest quality rendering, and on Linux we have xft or freetype producing coloured glyphs, but haven't done the required job in the other parts of the system. I started my comment with a desire to simply highlight the issues that are wrong in Linux font rendering currently.
> As for the benefits: I, and I suspect most people reading this, spend a
> great deal of time reading computer displays.
Yes, but I suspect for most people the rendering is already good enough. The subtle benefit in correct gamma blending for instance isn't likely to woo a lot of people over, if the cost is noticeably slower display updates. As to using 256*256 lookup table, sure it's possible. But if it has to be done by the CPU, then it's still replacing something that there probably exists MMX/SSE instructions for with something that goes much slower.
There's also the minor issue that if you do a repeated blendings, errors inherent in constantly quantizing to 8-bit become apparent. Ideally, one would render everything to a gamma 1.0 off-screen 16-bit per color channel canvas, and periodically render snapshots of that to screen...
Font rasterization techniques
Posted Sep 25, 2007 13:06 UTC (Tue) by forthy (guest, #1525) [Link]
Shit! After reading that article, I see tons of font rendering artefacts on the screen which weren't there before!
But at least in KDE, you can select how much hinting you want. The problems don't go away if you reduce hinting and turn on subpixel rendering (wrong gamma, suboptimal approach), but it improves somewhat. BTW: The RGB triplet is not really the best pattern, it's just historical. I'd rather use a Bayer pattern with two different greens - this would instantly boost the subpixel resolution to 200dpi, while the colored resolution still is 100dpi (fine for Windows), and it would also have better saturated colors.
Font rasterization techniques
Posted Sep 25, 2007 17:13 UTC (Tue) by ringerc (guest, #3071) [Link]
The resolution issue with Windows' font rendering has driven me insane for years, since I like to use high resolution displays. You can force it to render fonts at (closer to) real physical sizes but it's still inaccurate and it breaks other parts of the UI (though in less annoying ways).
I'm personally pretty happy with font rendering under Linux these days, though there's definitely room for improvement and some apps (eg Firefox) do a rather poor job.