matplotlib-devel Mailing List for matplotlib

ps backend, when usetex=True, uses latex with psfrag package to
generate the output (with some extra steps).
It seems that the bounding box information is not correctly recovered
during this process.
I first thought that it would be quite difficult to get this correct,
however the attached (relatively simple) patch seems to work fine.
Ken, can you try the patch and see if it works?
-JJ
On Thu, Apr 23, 2009 at 2:25 PM, Ken Schutte <kts...@gm...> wrote:
> I've been trying to track down some strange behavior I was getting,
> and I think narrowed it down to some code that I'll paste below.
>
> I'm trying to write to .eps files, and when I have usetex=True,
> something is screwed up with the padding on the left, and eventually
> the whole image is just white.
>
> If I run this script, the 'testA-*.eps' look good, but 'testB-*' does
> not. The same problem happens even if I remove the ticklabels.
>
> Any tips would be appreciated.
> thanks,
> Ken
>
>
>
> ------------------------------------------------
> import matplotlib.pyplot as plt
> import numpy as np
> from matplotlib import rc
>
> fig = plt.figure()
> ax = fig.add_axes([0,0,1,1],frameon=False)
>
> X = np.tile(np.arange(500),(10,1)) # (10,500) shape
>
> ax.imshow(X,interpolation='nearest',aspect='auto')
>
> def go(name):
>
>  for d in (1,2,3,4):
>
>    w = d*5
>    h = d
>
>    fig.set_size_inches(w,h)
>    fig.savefig("%s-%d.eps" % (name,d))
>
> rc('text', usetex=False)
> go("testA")
>
> rc('text', usetex=True)
> go("testB")
>
> ------------------------------------------------------------------------------
> Crystal Reports &#45; New Free Runtime and 30 Day Trial
> Check out the new simplified licensign option that enables unlimited
> royalty&#45;free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Thu, Apr 9, 2009 at 8:18 PM, Adam Mercer <ram...@gm...> wrote:
> On Thu, Apr 9, 2009 at 13:46, Michael Droettboom <md...@st...> wrote:
> > I did a lot of the initial fixes for Python 2.6 within the first week of
> the
> > 2.6.0 release -- they were mostly of the warning/style nature. I've been
> > running it on 2.6 on and off ever since, so it should be ok. But let us
> > know if you find anything.
>
> The only things I've seen so far are some deprecation warnings of the form:
>
>
> /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/matplotlib/texmanager.py:55:
> DeprecationWarning: os.popen4 is deprecated. Use the subprocess
> module.
> stdin, stdout = os.popen4('dvipng -version')
>
I fixed this in r7063. It works for me on Linux, but the windows users
might want to double check that there isn't some weird subprocess
incompatibility. (tex_demo.py exercises this code.)
I also fixed the use of os.popen in cbook.report_memory(). Again, it works
for me here, but I'd love for others to check. There is no code for windows
with this one, but there is code for Macs.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, Oklahoma, United States

On Thu, Apr 23, 2009 at 9:54 PM, Eric Bruning <eri...@gm...>wrote:
> On Thu, Apr 23, 2009 at 3:06 PM, Jae-Joon Lee <lee...@gm...>
> wrote:
>
> The discussion about what to do with my patch fizzled. I created a
> decorator that made mixed-mode switching a one-line change per artist
> type. I also added get/set_rasterized and an _rasterized attribute to
> the Artist base class. I've used it on and off for a few months now
> with no noted bugs.
>
> If we don't like the decorator, we can just make a helper function
> that is called at the beginning of every artist.draw() method. It's
> not a very complicated modification.
I think part of the problem with decorators before was that they came around
in 2.4. I think we only support >=2.4 now, so this is no longer an issue.
IMO, decorators seem like a sensible way to go.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Thu, Apr 23, 2009 at 3:06 PM, Jae-Joon Lee <lee...@gm...> wrote:
> On Tue, Apr 21, 2009 at 10:42 PM, Eric Bruning <eri...@gm...> wrote:
>> On a somewhat related note, how are you turning rasterization on and
>> off? Are you using my per-artist patch (which last I knew wasn't in
>> trunk) or some other solution?
>
> I remember that I tried to use your patch, but all the links that I
> found were broken. So I wrote a few lines for monkey patching. It was
> straight forward as I only needed a rasterization of the QuadMesh
> class.
Sorry about the broken links. I've attached a diff made against trunk
from a few days ago.
The discussion about what to do with my patch fizzled. I created a
decorator that made mixed-mode switching a one-line change per artist
type. I also added get/set_rasterized and an _rasterized attribute to
the Artist base class. I've used it on and off for a few months now
with no noted bugs.
If we don't like the decorator, we can just make a helper function
that is called at the beginning of every artist.draw() method. It's
not a very complicated modification.
>
> Are you planning to commit your patch to the trunk? I'll be glad to
> help you if there are any issues.
I'd love to get the patch in trunk, if only so that more people can
try it out and find things to improve (or re-implement).
Thanks,
Eric