John Hunter wrote: > On Sun, Apr 27, 2008 at 3:14 AM, Eric Firing <[EMAIL PROTECTED]> wrote: > > >> 1) The hline generated by frac is too long with dpi=50. >> > > The problem with the hline appears to be that the width of the line in > the frac has a component that depends on the thickness > > thickness = state.font_output.get_underline_thickness( > state.font, state.fontsize, state.dpi) > width = max(num.width, den.width) + thickness * 10. > > and get_underline_thickness here is defaulting to 1.0 because of this > max call in get_underline_thickness > > return max(1.0, cached_font.font.underline_thickness / 64.0 / > fontsize * 10.0) > I believe that this is where the dpi needs to be factored in. Ft2font (well, freetype, really) seems to scale metrics for individual glyphs by dpi, but not the font-global metrics. I had wrongly assumed they were all scaled by dpi. So this is a subtler instance of the recent x-height bug that caused sub/superscripts to be incorrect at different dpi's. > Michael -- what is the role of these 10.0 scale factors, which is > showing up in both the frac call and the get_underline_thickness? Is > this something from Knuth, or is it a fudge factor that gets it mostly > right? I suspect we will need something like > > width = max(num.width, den.width) + thickness * 10. * state.dpi/72. > This 10.0 is from Knuth. It is the amount of overhang of the fraction beam, and is meant to be relative to the thickness of the beam itself. The other 10.0 (in get_underline_thickness) is my own experimental fudge to deal with the peculiarities of how underline thickness is stored in Truetype fonts. (Remember "pure" TeX uses a completely different font metric standard, so some mapping from TrueType/freetype etc. had to be fudged on.)
What's causing the fraction bar to be too wide at lower dpi is the minimum underline thickness of 1.0 enforced in get_underline_thickness. I think that was a mistake -- enforcing 1.0 pixel lines should happen closer to the backend level -- so I've removed the max(1.0, ...) there. > but with this change the frac bar looks a little too wide -- which is > why I'm wondering if there is something magic about 10. or if another > number might serve better. > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
