matplotlib-devel Mailing List for matplotlib

On Mon, Apr 28, 2008 at 09:51:54AM -0400, Michael Droettboom wrote:
> Paul Kienzle wrote:
> >
> > Thanks. It looks much better in png, but pdf has the subscript raised much
> > higher, 
> That was a DPI-related bug, that is hopefully now fixed in SVN.
> > and svg isn't rendering fonts at all (see attached).
Yes.
> Thanks. The SVG was broken in SVN March 26 trying to workaround an 
> Inkscape copy/paste bug. I think it is fixed now so it works in Mozilla 
> and Inkscape simultaneously. But please let me know if you see anything 
> fishy -- there seems to be a great deal of variability between SVG viewers.
Works in Safari 3.1.1, Inkscape 0.45 and FF 2.0.0.14
> Are you seeing this bug with 0.91.2 release, or just the 0.91.2 SVN 
> branch? I'd be surprised by the former (and I can't reproduce it there).
0.91.2 SVG does indeed work (with the old superscript position of course).
- Paul

Paul Kienzle wrote:
> On Thu, Apr 24, 2008 at 08:38:02AM -0400, Michael Droettboom wrote:
> 
>> Paul Kienzle wrote:
>> 
>>> Hi,
>>>
>>> The superscripts in mpl don't seem to be placed at the correct height for
>>> small fonts. The y-tics on the attached plot shows this. The effect is
>>> similar in svg and pdf backends.
>>> 
>>> 
>> Thanks. When looking up the x-height, the code was not taking the font 
>> size into account. This has been fixed on the branch and trunk.
>> 
>
> Thanks. It looks much better in png, but pdf has the subscript raised much
> higher, 
That was a DPI-related bug, that is hopefully now fixed in SVN.
> and svg isn't rendering fonts at all (see attached).
> 
Thanks. The SVG was broken in SVN March 26 trying to workaround an 
Inkscape copy/paste bug. I think it is fixed now so it works in Mozilla 
and Inkscape simultaneously. But please let me know if you see anything 
fishy -- there seems to be a great deal of variability between SVG viewers.
Are you seeing this bug with 0.91.2 release, or just the 0.91.2 SVN 
branch? I'd be surprised by the former (and I can't reproduce it there).
Cheers, and thanks for your patience,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> On Fri, Apr 25, 2008 at 2:12 PM, Michael Droettboom <md...@st...> wrote:
>
> 
>> I'm stumped. It looks like the code (and even the inputs to
>> draw_text_image) are virtually identical, modulo the differences between Agg
>> 2.3 and 2.4. Maybe the change is in Agg, and 2.4 is theoretically more
>> correct? We can always experiment with different kernels and parameters
>> until finding one that looks right.
>> 
>
> I'll poke around with this then -- I was hoping the report would
> trigger some memory about a font change you made. 
I don't recall any font changes -- if you diff ft2font.cpp in 0.91.2 and 
trunk you'll see they're virtually identical. And the unrotated text 
looks identical to me.
> The differences in
> the 2.3 and 2.4 agg incantations were all I could see too -- I wonder
> if some default template parameter that is different in 2. is creeping
> in.
> 
Perhaps. I was going to check the Agg examples to see if the spline 
filters look different there, too, but I can't get 2.3 to compile 
anymore for some reason, so I gave up for now.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> On Sun, Apr 27, 2008 at 3:14 AM, Eric Firing <ef...@ha...> 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

John Hunter wrote:
> On Sun, Apr 27, 2008 at 12:56 PM, Eric Firing <ef...@ha...> wrote:
> 
>> The plot thickens. The postscript backend is completely confused by the
>> quiver plot. Try the attached example.
> 
> 
> Argg, that was a subtle one -- there was a bug in backend ps which was
> exposed only if you are using a path collection with offsets,
> transoffset and clippath and cliprect both None. In that scenario,
> the translate in the bind def function was not getting wrapped in a
> gsave/grestore pair, which was causing the axes to be drawn in the
> wrong place because the translate from the offset remained in effect.
> I tried following the draw_markers logic and putting the
> gsave/grestore in the ps_cmd, eg in draw_markers Michael writes ijn a
> comment:
> 
> ps_cmd = ['/o {', 'gsave', 'newpath', 'translate'] # dont want
> the translate to be global
> 
> so clearly he was bumping up against the same problem with markers.
> For some reason, trying the same thing in the path_collection was not
> working for me, so I resorted to the somewhat hackish approach of
> forcing _draw_ps to wrap a gsave/grestore if it wasn't getting one
> from the cliprect or clippath:
> 
> needwrap = not (clippath or cliprect)
> if needwrap:
> # we need to make sure that there is at least 1
> # save/grestore around each ps write so we'll force it if
> # we're not getting one from the cliprecot or clippath.
> # hackish, yes
> write('gsave\n')
> 
> and then
> 
> if needwrap:
> write('grestore\n')
> 
> I think there will be cleaner way, but it will need some fresh
> eyeballs tomorrow and this will provide a temporary fix.
I went ahead and committed an alternative fix that I think is cleaner, 
and greatly reduces the number of needless gsave/grestore pairs. Your 
version of the method is still there, with a mangled name, for easy 
reference and testing until we are sure which way to go.
Sorry for whatever duplicated effort there has been. I did not intend 
to spend a fair chunk of the day working on this, but I let myself get 
sucked in. It was a challenge.
As mentioned in a message a few minutes ago that I don't think went to 
the list, my gs interpreter is choking on the apostrophe (single quote) 
character, as in title or label strings. I can't find any reason why 
this should cause trouble--maybe it is a particular version or 
configuration of gs.
Eric

On Sun, Apr 27, 2008 at 8:28 PM, John Hunter <jd...@gm...> wrote:
> Argg, that was a subtle one -- there was a bug in backend ps which was
> exposed only if you are using a path collection with offsets,
> transoffset and clippath and cliprect both None. In that scenario,
> the translate in the bind def function was not getting wrapped in a
One thing I failed to make clear: the artist with said properties is
quiver.QuiverKey.vector
JDH

On Sun, Apr 27, 2008 at 12:56 PM, Eric Firing <ef...@ha...> wrote:
> The plot thickens. The postscript backend is completely confused by the
> quiver plot. Try the attached example.
Argg, that was a subtle one -- there was a bug in backend ps which was
exposed only if you are using a path collection with offsets,
transoffset and clippath and cliprect both None. In that scenario,
the translate in the bind def function was not getting wrapped in a
gsave/grestore pair, which was causing the axes to be drawn in the
wrong place because the translate from the offset remained in effect.
I tried following the draw_markers logic and putting the
gsave/grestore in the ps_cmd, eg in draw_markers Michael writes ijn a
comment:
 ps_cmd = ['/o {', 'gsave', 'newpath', 'translate'] # dont want
the translate to be global
so clearly he was bumping up against the same problem with markers.
For some reason, trying the same thing in the path_collection was not
working for me, so I resorted to the somewhat hackish approach of
forcing _draw_ps to wrap a gsave/grestore if it wasn't getting one
from the cliprect or clippath:
 needwrap = not (clippath or cliprect)
 if needwrap:
 # we need to make sure that there is at least 1
 # save/grestore around each ps write so we'll force it if
 # we're not getting one from the cliprecot or clippath.
 # hackish, yes
 write('gsave\n')
and then
 if needwrap:
 write('grestore\n')
I think there will be cleaner way, but it will need some fresh
eyeballs tomorrow and this will provide a temporary fix.
JDH