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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
