Re: [matplotlib-devel] mathtext examples
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
Re: [matplotlib-devel] mathtext examples
On 8/6/07, Michael Droettboom <[EMAIL PROTECTED]> wrote: > 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?) agg 2.5, and any enhancements Maxim makes to support fonts, will be GPL and not usable by us, sadly. JDH - 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
Re: [matplotlib-devel] mathtext examples
On 8/6/07, Michael Droettboom <[EMAIL PROTECTED]> wrote: > 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. I am still a bit confused here -- since the bakoma cm fonts presumably include hinting, why is it so bad? Is it just that the hinting information in them is not good, and some of the autohinting approaches below are simply better? I initially thought the problem was that they didn't include hinting... > 2) mathtext_example_light.png - Uses freetype's "light" hinting. To my eyes, the biggest problems are in plain roman text, eg \sin, and I think 1 and 2 both fail this case pretty badly (eg example 10 in your output). TO my eyes, no hinting looks better than light hinting for these examples (and 4 is best) > 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 I guess beauty is in the eye of the holder, but at screen resolution I am not seeing too much difference in the italic 'i' and 'y'. But for roman text, eg the "c" in "braces" in example 7 and "sin" in example 10, I think 3 and 4 are the best two, with 4 getting the nod. If it is simply a case where the bakoma hinting is bad, and another set of fonts with better hinting will solve the problem using default hinting, we could opt to turn hinting off until we get a better set of fonts. As for uglifying ft2font, presumably we could encapsulate the ugliness into a helper class so we could say things like o.get_metrics_unstretched() and o.get_metrics_stretched() and the rest of the code would remain non-uglified. But I'm just arm-chair quarterbacking here JDH - 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
Re: [matplotlib-devel] mathtext examples
John Hunter wrote: > On 8/6/07, Michael Droettboom <[EMAIL PROTECTED]> wrote: > >> 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. > > I am still a bit confused here -- since the bakoma cm fonts presumably > include hinting, why is it so bad? Is it just that the hinting > information in them is not good, and some of the autohinting > approaches below are simply better? I initially thought the problem > was that they didn't include hinting... I haven't been able to find a way to determine if a font has embedded hinting information. However, I should have mentioned that Freetype by default will use the embedded hinting or fallback on auto-hinting. There is also an option, FT_LOAD_FORCE_AUTOHINT that will ignore the embedded hinting. It produced identical results to FT_LOAD_DEFAULT, so I presume the fonts have no embedded hinting, which sort of makes sense, given their pedigree. However, I'm flying blind on that, so if anyone can suggest a way to prove that, let me know. My original conjecture (which I admit wasn't worded very carefully) was that if they included manually-tweaked hinting, they might look better than if they were auto-hinted. Since no one is about to add manual hinting to the font, we'll probably never know ;) >> 2) mathtext_example_light.png - Uses freetype's "light" hinting. > > To my eyes, the biggest problems are in plain roman text, eg \sin, and > I think 1 and 2 both fail this case pretty badly (eg example 10 in > your output). TO my eyes, no hinting looks better than light hinting > for these examples (and 4 is best) > >> 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 > > I guess beauty is in the eye of the holder, but at screen resolution I > am not seeing too much difference in the italic 'i' and 'y'. It's subjective, but the hook in the upper-left corner of 'y' looks really anemic to me in 1) and 2). Likewise the hooks on the 'i' get too thin. > But for > roman text, eg the "c" in "braces" in example 7 and "sin" in example > 10, I think 3 and 4 are the best two, with 4 getting the nod. I think you and I are seeing the same thing: a general thinness or unevenness. > If it is simply a case where the bakoma hinting is bad, and another > set of fonts with better hinting will solve the problem using default > hinting, we could opt to turn hinting off until we get a better set of > fonts. That's the easy solution. Unfortunately, Vera Sans looks pretty wobbly without vertical hinting. > As for uglifying ft2font, presumably we could encapsulate the > ugliness into a helper class so we could say things like > o.get_metrics_unstretched() and o.get_metrics_stretched() and the rest > of the code would remain non-uglified. But I'm just arm-chair > quarterbacking here Unfortunately, it's a lot more pervasive than just that one function. But if all calls to get freetype metrics were encapsulated, that could probably be reduced. I'll think on it some more. 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
