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
