Stefan van der Walt wrote: > On Fri, Aug 03, 2007 at 03:13:01PM -0400, Michael Droettboom wrote: >> On a related note, the Agg backend suffers a little bit from the lack of >> subpixel character placement. The spacing of symbols can look slightly >> incorrect because of that (since their placement is rounded to the >> nearest integer), particularly at the smaller sizes. I haven't gotten >> around to experimenting with rounding vs. truncating to see if that >> alone makes it look any better. > > An interesting article by the author of AGG on the intricacies of font > rendering: > > http://antigrain.com/research/font_rasterization/index.html
Very illuminating read. I've put the results of some of my own experiments up at: ftp://ftp.stsci.edu/tmp/mdroe I've chosen to ignore subpixel anti-aliasing on LCD issue (aka ClearType) since you definitely wouldn't want that for a plot whose ultimate destination is a printer or even the web. (Besides, trying that out in matplotlib would require significant refactoring of ft2font to support color bitmaps internally.) 1) mathtext_example_default_hinting.png - Uses freetype's default hinting which uses hinting information in the file along with auto-hinting to get around some patents. This is what matplotlib was using when I got here. 2) mathtext_example_light.png - Uses freetype's "light" hinting. 3) mathtext_example_nohint.png - All hinting off. 4) mathtext_example_vert_hinting.png - This follows the suggestion in Maxim's article to hint only in the vertical direction. Since freetype doesn't support that natively, it uses a hack where you set the x-dpi to be much higher than the y-dpi, thereby hinting the x-direction to a much finer grid. When the glyph is copied from freetype's bitmap into matplotlib's bitmap, it is resampled back to the correct aspect ratio. If you look at the examples, the character rendering differences are most pronounced, IMO, on the italic i's and y's. I think 3) looks the best and it is theoretically the most "accurate", but I imagine some will find it too blurry. Unfortunately, however, there are places where the lack of y-hinting make the text appear to have a wandering baseline (see #20 especially). 4) effectively solves that problem, at the expense of a hack. I'm happy to commit the code for 4), however, I have reservations, since it really uglifies the code in ft2font.cpp. Once you start using freetype in "stretched space", all the metrics it returns etc. are also stretched and need to be unstretched when returning values to the caller (of ft2font). It isn't good enough to work in unstretched space and only stretch prior to rendering since the hinting causes the width of the glyphs to change based on the resolution of the grid they're being drawn on. It's not insurmountable (in fact I've already worked through most of the places where the division needs to occur), and it's completely hidden from *users* of ft2font, it just adds something fairly obscure and hackish to worry about the next time that code is modified. Are there plans to use Agg itself for font rendering in the future (and thereby push this issue downward?) Cheers, Mike ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel