Re: [matplotlib-devel] fonts pixelated in rotated text

2008-04-26 Thread John Hunter
On Fri, Apr 25, 2008 at 2:12 PM, Michael Droettboom <[EMAIL PROTECTED]> 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.  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.

JDH

-
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


[matplotlib-devel] dpi-related positioning errors in Agg savefig

2008-04-26 Thread Eric Firing
The attached script, run on svn mpl, illustrates a positioning problem: 
note that the subplot titles are badly positioned in the 50 dpi version. 
 I believe that changing from 150 to 50 dpi should yield a perfect 
scaling of everything in the plot, but it doesn't.  There is a similar 
problem with a quiver key positioned outside the axes frame, but I don't 
have a trivial example yet; I am hoping that whatever solves the title 
positioning problem will take care of that also.  If not, I will make a 
simple example and we can attack it separately.


I have made a first attempt to figure out the cause of the positioning 
problem, and I have failed; I hope someone else will find it easier to 
track down.  I also find that following the chain of events involved in 
savefig, and following the dpi setting, is rather difficult, and I 
wonder whether it might be possible to clarify and simplify anything.


In any case, the dpi-related positioning bug (or bugs) is a significant 
problem for me now.


Eric

import matplotlib
matplotlib.use('agg')
import matplotlib.pyplot as plt

fig = plt.figure()

ax1 = fig.add_subplot(2,1,1)
ax1.plot([1,2])
ax1.set_title('Top Plot')


ax2 = fig.add_subplot(2,1,2)
ax2.plot([1,2])
ax2.set_title('Bottom Plot')

fig.savefig('dpi150.png', dpi=150)
fig.savefig('dpi50.png', dpi=50)

-
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


Re: [matplotlib-devel] dpi-related positioning errors in Agg savefig

2008-04-26 Thread John Hunter
On Sat, Apr 26, 2008 at 2:04 PM, Eric Firing <[EMAIL PROTECTED]> wrote:

> The attached script, run on svn mpl, illustrates a positioning problem: note
> that the subplot titles are badly positioned in the 50 dpi version.  I
> believe that changing from 150 to 50 dpi should yield a perfect scaling of
> everything in the plot, but it doesn't.  There is a similar problem with a
> quiver key positioned outside the axes frame, but I don't have a trivial
> example yet; I am hoping that whatever solves the title positioning problem
> will take care of that also.  If not, I will make a simple example and we
> can attack it separately.

There were two problems with title positioning.  The first was that
the title offset transformation was hardcoded in pixels and not dpi,
and the second was that is was not getting notifed when the figure dpi
was changed.  I changed the offset to read:

self.titleOffsetTrans = mtransforms.Affine2D().translate(
0.0, 5.0*self.figure.dpi/72.)

and added a callbacks registry to the figure instance so that
observers could be notified when dpi was changed (dpi used to be a
lazy value on the maintenance branch but is a plain-ol-value on the
trunk).

 def on_dpi_change(fig):
self.titleOffsetTrans.clear().translate(
0.0, 5.0*fig.dpi/72.)

self.figure.callbacks.connect('dpi_changed', on_dpi_change)

It looks like the problem in the quiver code is that the "labelsep"
property reads the dpi when the QuiverKey is intiitalized but does not
get notified on dpi change.  I added a callback there too so you
should test to see if this helps.  The dpi setting is also referenced
in the _set_transform method.  Since you are more familiar with the
quiver code that I am, and this hint may point you in the right
direction, I'll let you take a look at that and see if a callback is
needed.

On a related note, one trick I use when debugging text layout problems
is to turn on the "bbox".  If the bbox is right but the text is in the
wrong place, you know it is in the layout.  If the bbox is in the
wrong place, you know the problem is in the font metrics:

boxprops = dict(facecolor='red')
ax1.set_title('Top Plot', bbox=boxprops)

JDH

-
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


Re: [matplotlib-devel] dpi-related positioning errors in Agg savefig

2008-04-26 Thread Eric Firing
John,

Thank you very much--that's a big help. Some time today or tomorrow I 
will try to track down any remaining quiver problems.  I suspect similar 
dpi-related problems may lurk elsewhere as well.

Those lazy values worked pretty well!

One of the things that puzzles me is the following method of 
FigureCanvasAgg in backend_agg:

 def print_png(self, filename_or_obj, *args, **kwargs):
 FigureCanvasAgg.draw(self)
 renderer = self.get_renderer()
 original_dpi = renderer.dpi
 renderer.dpi = self.figure.dpi
 if type(filename_or_obj) in (str, unicode):
 filename_or_obj = open(filename_or_obj, 'w')
 self.get_renderer()._renderer.write_png(filename_or_obj, 
self.figure.dpi)
 renderer.dpi = original_dpi

The FigureCanvasAgg.draw(self) command gets turned into 
self.figure.draw(self.renderer), which is executed *before* the 
renderer.dpi gets set to self.figure.dpi, so it seems like there is the 
possibility of an inconsistency.  I suspect there is no problem in 
practice, but it is confusing.

Now that I look again, it looks like what is happening is that the 
get_renderer call in FigureCanvasAgg.draw is setting the renderer dpi to 
the figure dpi, as well as setting self.renderer, in which case most of 
the code in print_png seems to be superfluous.


Mostly unrelated question: is there any point in keeping 
backend_agg2.py, or at least keeping it in the backends directory? 
Maybe it is time to move that and backend_emf.py (and maybe others) to 
some sort of cold storage, in case someone is inspired later to 
resurrect them.

Eric


John Hunter wrote:
> On Sat, Apr 26, 2008 at 2:04 PM, Eric Firing <[EMAIL PROTECTED]> wrote:
> 
>> The attached script, run on svn mpl, illustrates a positioning problem: note
>> that the subplot titles are badly positioned in the 50 dpi version.  I
>> believe that changing from 150 to 50 dpi should yield a perfect scaling of
>> everything in the plot, but it doesn't.  There is a similar problem with a
>> quiver key positioned outside the axes frame, but I don't have a trivial
>> example yet; I am hoping that whatever solves the title positioning problem
>> will take care of that also.  If not, I will make a simple example and we
>> can attack it separately.
> 
> There were two problems with title positioning.  The first was that
> the title offset transformation was hardcoded in pixels and not dpi,
> and the second was that is was not getting notifed when the figure dpi
> was changed.  I changed the offset to read:
> 
> self.titleOffsetTrans = mtransforms.Affine2D().translate(
> 0.0, 5.0*self.figure.dpi/72.)
> 
> and added a callbacks registry to the figure instance so that
> observers could be notified when dpi was changed (dpi used to be a
> lazy value on the maintenance branch but is a plain-ol-value on the
> trunk).
> 
>  def on_dpi_change(fig):
> self.titleOffsetTrans.clear().translate(
> 0.0, 5.0*fig.dpi/72.)
> 
> self.figure.callbacks.connect('dpi_changed', on_dpi_change)
> 
> It looks like the problem in the quiver code is that the "labelsep"
> property reads the dpi when the QuiverKey is intiitalized but does not
> get notified on dpi change.  I added a callback there too so you
> should test to see if this helps.  The dpi setting is also referenced
> in the _set_transform method.  Since you are more familiar with the
> quiver code that I am, and this hint may point you in the right
> direction, I'll let you take a look at that and see if a callback is
> needed.
> 
> On a related note, one trick I use when debugging text layout problems
> is to turn on the "bbox".  If the bbox is right but the text is in the
> wrong place, you know it is in the layout.  If the bbox is in the
> wrong place, you know the problem is in the font metrics:
> 
> boxprops = dict(facecolor='red')
> ax1.set_title('Top Plot', bbox=boxprops)
> 
> JDH


-
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