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:

Very illuminating read.

I've put the results of some of my own experiments up at:

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?)


This 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 >>
Matplotlib-devel mailing list

Reply via email to