matplotlib-devel Mailing List for matplotlib

On Wed, Apr 29, 2009 at 4:07 PM, Ken Schutte <kts...@gm...> wrote:
> Yes, I'm sorry, I also spoke too soon. I have found problems with
> this patch - mainly things like it chopping off xlabel, titles, etc,
> for some examples.
>
I'm not sure if these are related with my patch.
Please show some example when you have time.
Regards,
-JJ

Argg, attached a wrong patch. This one should work
 # set the paper size to the figure size if isEPSF. The
 # resulting ps file has the given size with correct bounding
 # box so that there is no need to call 'pstoeps'
 if isEPSF:
 paperWidth, paperHeight = self.figure.get_size_inches()
+ if isLandscape:
+ paperWidth, paperHeight = paperHeight, paperWidth
 else:
 temp_papertype = _get_papertype(width, height)
 if papertype=='auto':
On Wed, Apr 29, 2009 at 5:55 PM, Jae-Joon Lee <lee...@gm...> wrote:
> Thanks Darren,
>
> I believe that my patch only affects eps output with usetex=True,
> i.e., only those "tex_*.eps" files are affected.
>
> I found that my previous patch didn't treated the orientation of the
> paper correctly.
> So the bounding box of all the landscape eps outputs are incorrect.
> This can be easily fixed.
>
> Index: lib/matplotlib/backends/backend_ps.py
> ===================================================================
> --- lib/matplotlib/backends/backend_ps.py    (revision 7071)
> +++ lib/matplotlib/backends/backend_ps.py    (working copy)
> @@ -1100,8 +1100,11 @@
>     # set the paper size to the figure size if isEPSF. The
>     # resulting ps file has the given size with correct bounding
>     # box so that there is no need to call 'pstoeps'
>       paperWidth, paperHeight = self.figure.get_size_inches()
> +      if isLandscape:
> +        paperWidth, paperHeight = paperHeight, paperWidth
>     else:
>       temp_papertype = _get_papertype(width, height)
>       if papertype=='auto':
>
>
>
>
> Anyhow, after the landscape fix, all eps output looks fine to me.
> Can you check this?
>
> Regards,
>
> -JJ
>
>
>
> On Wed, Apr 29, 2009 at 3:55 PM, Darren Dale <dsd...@gm...> wrote:
>> Hi Jae-Joon,
>>
>> On Tue, Apr 28, 2009 at 3:49 PM, Jae-Joon Lee <lee...@gm...> wrote:
>>>
>>> This patch is now committed to the trunk (r7068).
>>
>> I think these changes have had unintended consequences. I attached a test
>> file I used to inspect the results when I wrote the original code that you
>> recently tried to improve. There are lots of combinations of large and small
>> figures, with usetex and without, and with no distiller, gs distiller, of
>> xpdf (pdftops) distiller. You have to visually inspect all of the ps/eps
>> files that are generated. At one time, all of these files looked acceptable,
>> but that was a couple years ago and I don't remember what version of
>> ghostscript I was using at the time (I'm sure there is a record of it
>> somewhere on this mailing list). WIth r7067, most of the files look fine, a
>> few of the large files (large paper sizes) have problems. With r7068, quite
>> a few examples have problems.
>>
>> Darren
>>
>>
>>>
>>> On Sat, Apr 25, 2009 at 8:29 AM, Ken Schutte <kts...@gm...> wrote:
>>> > Yeah, that seems to work! thanks a lot,
>>> > Ken
>>> >
>>> > On Fri, Apr 24, 2009 at 5:21 PM, Jae-Joon Lee <lee...@gm...>
>>> > wrote:
>>> >> 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
>>> >>>
>>> >>
>>> >
>>>
>>>
>>> ------------------------------------------------------------------------------
>>
>>
>>
>>>
>>> Register Now & Save for Velocity, the Web Performance & Operations
>>> Conference from O'Reilly Media. Velocity features a full day of
>>> expert-led, hands-on workshops and two days of sessions from industry
>>> leaders in dedicated Performance & Operations tracks. Use code vel09scf
>>> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>

Thanks Darren,
I believe that my patch only affects eps output with usetex=True,
i.e., only those "tex_*.eps" files are affected.
I found that my previous patch didn't treated the orientation of the
paper correctly.
So the bounding box of all the landscape eps outputs are incorrect.
This can be easily fixed.
Index: lib/matplotlib/backends/backend_ps.py
===================================================================
--- lib/matplotlib/backends/backend_ps.py (revision 7071)
+++ lib/matplotlib/backends/backend_ps.py (working copy)
@@ -1100,8 +1100,11 @@
 # set the paper size to the figure size if isEPSF. The
 # resulting ps file has the given size with correct bounding
 # box so that there is no need to call 'pstoeps'
 paperWidth, paperHeight = self.figure.get_size_inches()
+ if isLandscape:
+ paperWidth, paperHeight = paperHeight, paperWidth
 else:
 temp_papertype = _get_papertype(width, height)
 if papertype=='auto':
Anyhow, after the landscape fix, all eps output looks fine to me.
Can you check this?
Regards,
-JJ
On Wed, Apr 29, 2009 at 3:55 PM, Darren Dale <dsd...@gm...> wrote:
> Hi Jae-Joon,
>
> On Tue, Apr 28, 2009 at 3:49 PM, Jae-Joon Lee <lee...@gm...> wrote:
>>
>> This patch is now committed to the trunk (r7068).
>
> I think these changes have had unintended consequences. I attached a test
> file I used to inspect the results when I wrote the original code that you
> recently tried to improve. There are lots of combinations of large and small
> figures, with usetex and without, and with no distiller, gs distiller, of
> xpdf (pdftops) distiller. You have to visually inspect all of the ps/eps
> files that are generated. At one time, all of these files looked acceptable,
> but that was a couple years ago and I don't remember what version of
> ghostscript I was using at the time (I'm sure there is a record of it
> somewhere on this mailing list). WIth r7067, most of the files look fine, a
> few of the large files (large paper sizes) have problems. With r7068, quite
> a few examples have problems.
>
> Darren
>
>
>>
>> On Sat, Apr 25, 2009 at 8:29 AM, Ken Schutte <kts...@gm...> wrote:
>> > Yeah, that seems to work! thanks a lot,
>> > Ken
>> >
>> > On Fri, Apr 24, 2009 at 5:21 PM, Jae-Joon Lee <lee...@gm...>
>> > wrote:
>> >> 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
>> >>>
>> >>
>> >
>>
>>
>> ------------------------------------------------------------------------------
>
>
>
>>
>> Register Now & Save for Velocity, the Web Performance & Operations
>> Conference from O'Reilly Media. Velocity features a full day of
>> expert-led, hands-on workshops and two days of sessions from industry
>> leaders in dedicated Performance & Operations tracks. Use code vel09scf
>> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Jae-Joon Lee wrote:
> On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning <eri...@gm...> wrote:
>> I like that this solution doesn't litter every call to draw with
>> rasterize checks. But it means that the rasterization support had
>> better be robust, since Artist authors might not know they're
>> interacting with the rasterization code. It has the downside of being
>> implicit rather than explicit.
> 
> Eric,
> I think we'd better stick to your decorator solution.
> 
> Anyhow, I thought you had a svn commit permission but it seems not. Do
> you (and other dwevelopers) mind if I commit this patch to the trunk?
It would be especially good for John and Mike to have a look.
As a matter of style, I suggest a name change. 
"@hook_before_after_draw" is too generic, and brings to mind discussions 
a long time ago about possibly adding a general hook mechanism; even 
before rasterization, and before decorators were available, there were 
thoughts that we might need this. (Now I don't remember what the 
motivation was, but I think it had to do with coordinating different 
elements of a plot.) In any case, the decorator is actually very 
specific to rasterization, so maybe call it "@with_rasterization" or 
"@allow_rasterization".
I am very anxious to see rasterization support in place; let's just be 
sure we have a good API and mechanism. The patch looks reasonable to 
me, but I have no experience in writing decorators, and have not had 
time to really think about the rasterization API problem.
Eric
> 
> One I thing I want to add your patch is to warn users when they set
> "rasterized" attribute of the artists whose draw method is not
> decorated. I'll think about it later but feel free to propose any.
> 
> Thanks,
> 
> -JJ
> 
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations 
> Conference from O'Reilly Media. Velocity features a full day of 
> expert-led, hands-on workshops and two days of sessions from industry 
> leaders in dedicated Performance & Operations tracks. Use code vel09scf 
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Yes, I'm sorry, I also spoke too soon. I have found problems with
this patch - mainly things like it chopping off xlabel, titles, etc,
for some examples.
I have some major deadlines using this stuff right now, so I don't
have time to experiment. But, eventually, I will try to take a look
at what is happening.
Ken
On Wed, Apr 29, 2009 at 3:56 PM, Darren Dale <dsd...@gm...> wrote:
> The test file is attached this time.
>
> On Wed, Apr 29, 2009 at 3:55 PM, Darren Dale <dsd...@gm...> wrote:
>>
>> Hi Jae-Joon,
>>
>> On Tue, Apr 28, 2009 at 3:49 PM, Jae-Joon Lee <lee...@gm...>
>> wrote:
>>>
>>> This patch is now committed to the trunk (r7068).
>>
>> I think these changes have had unintended consequences. I attached a test
>> file I used to inspect the results when I wrote the original code that you
>> recently tried to improve. There are lots of combinations of large and small
>> figures, with usetex and without, and with no distiller, gs distiller, of
>> xpdf (pdftops) distiller. You have to visually inspect all of the ps/eps
>> files that are generated. At one time, all of these files looked acceptable,
>> but that was a couple years ago and I don't remember what version of
>> ghostscript I was using at the time (I'm sure there is a record of it
>> somewhere on this mailing list). WIth r7067, most of the files look fine, a
>> few of the large files (large paper sizes) have problems. With r7068, quite
>> a few examples have problems.
>>
>> Darren
>>
>>
>>>
>>> On Sat, Apr 25, 2009 at 8:29 AM, Ken Schutte <kts...@gm...> wrote:
>>> > Yeah, that seems to work! thanks a lot,
>>> > Ken
>>> >
>>> > On Fri, Apr 24, 2009 at 5:21 PM, Jae-Joon Lee <lee...@gm...>
>>> > wrote:
>>> >> 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
>>> >>>
>>> >>
>>> >
>>>
>>>
>>> ------------------------------------------------------------------------------
>>
>>
>>
>>>
>>> Register Now & Save for Velocity, the Web Performance & Operations
>>> Conference from O'Reilly Media. Velocity features a full day of
>>> expert-led, hands-on workshops and two days of sessions from industry
>>> leaders in dedicated Performance & Operations tracks. Use code vel09scf
>>> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>

When attempting to build matplotlib 0.98.5.2 on Solaris 10 using GCC 
4.3.3, I get an error:
ttconv/pprdrv_tt2.cpp: In member function ‘void 
GlyphToType3::stack(TTStreamWriter&, int)’:
ttconv/pprdrv_tt2.cpp:107: error: ‘class TTStreamWriter’ has no member 
named ‘putc’
So I tried invoking GCC with the -E flag to get the output of the 
preprocessor and I see that line 107 of pprdrv_tt2.cpp gets rewritten to:
stream.putc(('{'), (&__iob[1]));
so it seems that something in GCC 4.3.3 on Solaris is defining a putchar 
macro that is doing this, but not correspondingly being applied to the 
pprdrv.h.
Searching the list archives, I see that back in July & August, 2008 
there was a brief thread between Peter Norton and Mike Droettboom about 
this and a proposal was made to rename TTStreamWriter::putchar to 
TTStreamWriter:put_char. I just looked at the trunk and it looks like 
this has never been done. Was there some other work-around that didn't 
make it into the thread that obviated the need for the mentioned change?
I can confirm that the renaming of putchar to put_char does solve the 
problem. I've attached a patch file, though it is against 0.98.5.2.
-- Dave

The test file is attached this time.
On Wed, Apr 29, 2009 at 3:55 PM, Darren Dale <dsd...@gm...> wrote:
> Hi Jae-Joon,
>
> On Tue, Apr 28, 2009 at 3:49 PM, Jae-Joon Lee <lee...@gm...>wrote:
>
>> This patch is now committed to the trunk (r7068).
>>
>
> I think these changes have had unintended consequences. I attached a test
> file I used to inspect the results when I wrote the original code that you
> recently tried to improve. There are lots of combinations of large and small
> figures, with usetex and without, and with no distiller, gs distiller, of
> xpdf (pdftops) distiller. You have to visually inspect all of the ps/eps
> files that are generated. At one time, all of these files looked acceptable,
> but that was a couple years ago and I don't remember what version of
> ghostscript I was using at the time (I'm sure there is a record of it
> somewhere on this mailing list). WIth r7067, most of the files look fine, a
> few of the large files (large paper sizes) have problems. With r7068, quite
> a few examples have problems.
>
> Darren
>
>
>
>>
>>
>> On Sat, Apr 25, 2009 at 8:29 AM, Ken Schutte <kts...@gm...> wrote:
>> > Yeah, that seems to work! thanks a lot,
>> > Ken
>> >
>> > On Fri, Apr 24, 2009 at 5:21 PM, Jae-Joon Lee <lee...@gm...>
>> wrote:
>> >> 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
>> >>>
>> >>
>> >
>>
>>
>> ------------------------------------------------------------------------------
>>
>
>
>
>
>> Register Now & Save for Velocity, the Web Performance & Operations
>> Conference from O'Reilly Media. Velocity features a full day of
>> expert-led, hands-on workshops and two days of sessions from industry
>> leaders in dedicated Performance & Operations tracks. Use code vel09scf
>> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>

Hi Jae-Joon,
On Tue, Apr 28, 2009 at 3:49 PM, Jae-Joon Lee <lee...@gm...> wrote:
> This patch is now committed to the trunk (r7068).
>
I think these changes have had unintended consequences. I attached a test
file I used to inspect the results when I wrote the original code that you
recently tried to improve. There are lots of combinations of large and small
figures, with usetex and without, and with no distiller, gs distiller, of
xpdf (pdftops) distiller. You have to visually inspect all of the ps/eps
files that are generated. At one time, all of these files looked acceptable,
but that was a couple years ago and I don't remember what version of
ghostscript I was using at the time (I'm sure there is a record of it
somewhere on this mailing list). WIth r7067, most of the files look fine, a
few of the large files (large paper sizes) have problems. With r7068, quite
a few examples have problems.
Darren
>
>
> On Sat, Apr 25, 2009 at 8:29 AM, Ken Schutte <kts...@gm...> wrote:
> > Yeah, that seems to work! thanks a lot,
> > Ken
> >
> > On Fri, Apr 24, 2009 at 5:21 PM, Jae-Joon Lee <lee...@gm...>
> wrote:
> >> 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
> >>>
> >>
> >
>
>
> ------------------------------------------------------------------------------
>
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Wed, Apr 29, 2009 at 19:51, John Hunter <jd...@gm...> wrote:
> On Wed, Apr 29, 2009 at 12:13 PM, Sandro Tosi <mo...@de...> wrote:
>>
>> On Wed, Apr 29, 2009 at 18:07, <jd...@us...> wrote:
>> > Log Message:
>> > -----------
>> > add masked array support to fill_between
>> >
>> > Modified Paths:
>> > --------------
>> >  trunk/matplotlib/examples/user_interfaces/embedding_in_gtk.py
>> >  trunk/matplotlib/examples/user_interfaces/embedding_in_gtk2.py
>>
>> is the switch to FigureCanvasGTKAgg in the examples somewhat related to...
>>
>> >  trunk/matplotlib/lib/matplotlib/axes.py
>>
>> ...supporting masked array here?
>>
>> I'm asking because I'm studying those embedded_in_gtk* examples to
>> learn/describe how to embed mpl into gtk :)
>
> No, it is unrelated; my commit message was incomplete.
:)
> I was demo-ing the embedding example to a colleague and got a gtk drawing
> error (we have an older pygtk error here). Apparently our backend gtk api
> is not consistent with all the pygtk's in the wild. With gtkcairo and
> gtkagg, I am not too concerned with this, so I just changed the default to
> gtkagg for that example which will work out of the box for more users, and
> we always try to push people onto *agg where feasible.
and I also got a reply for my next question "why this change?" :)
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Wed, Apr 29, 2009 at 12:13 PM, Sandro Tosi <mo...@de...> wrote:
> On Wed, Apr 29, 2009 at 18:07, <jd...@us...> wrote:
> > Log Message:
> > -----------
> > add masked array support to fill_between
> >
> > Modified Paths:
> > --------------
> > trunk/matplotlib/examples/user_interfaces/embedding_in_gtk.py
> > trunk/matplotlib/examples/user_interfaces/embedding_in_gtk2.py
>
> is the switch to FigureCanvasGTKAgg in the examples somewhat related to...
>
> > trunk/matplotlib/lib/matplotlib/axes.py
>
> ...supporting masked array here?
>
> I'm asking because I'm studying those embedded_in_gtk* examples to
> learn/describe how to embed mpl into gtk :)
No, it is unrelated; my commit message was incomplete.
I was demo-ing the embedding example to a colleague and got a gtk drawing
error (we have an older pygtk error here). Apparently our backend gtk api
is not consistent with all the pygtk's in the wild. With gtkcairo and
gtkagg, I am not too concerned with this, so I just changed the default to
gtkagg for that example which will work out of the box for more users, and
we always try to push people onto *agg where feasible.
JDH

On Wed, Apr 29, 2009 at 18:07, <jd...@us...> wrote:
> Log Message:
> -----------
> add masked array support to fill_between
>
> Modified Paths:
> --------------
>  trunk/matplotlib/examples/user_interfaces/embedding_in_gtk.py
>  trunk/matplotlib/examples/user_interfaces/embedding_in_gtk2.py
is the switch to FigureCanvasGTKAgg in the examples somewhat related to...
>  trunk/matplotlib/lib/matplotlib/axes.py
...supporting masked array here?
I'm asking because I'm studying those embedded_in_gtk* examples to
learn/describe how to embed mpl into gtk :)
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning <eri...@gm...> wrote:
> I like that this solution doesn't litter every call to draw with
> rasterize checks. But it means that the rasterization support had
> better be robust, since Artist authors might not know they're
> interacting with the rasterization code. It has the downside of being
> implicit rather than explicit.
Eric,
I think we'd better stick to your decorator solution.
Anyhow, I thought you had a svn commit permission but it seems not. Do
you (and other dwevelopers) mind if I commit this patch to the trunk?
One I thing I want to add your patch is to warn users when they set
"rasterized" attribute of the artists whose draw method is not
decorated. I'll think about it later but feel free to propose any.
Thanks,
-JJ

Yeah -- this looks like a bad merge from the branch. The branch's 
version of convert_path takes two arguments, the trunk takes three 
because it was updated to support path simplification routines which do 
their own transformation. The trunk has been updated to use the 
three-argument form consistently (r7069).
Mike
Michiel de Hoon wrote:
> Hi everybody,
>
> I believe a bug was introduced in revision 7002 of backend_cairo.py.
> This code, in two places, now calls RendererCairo.convert_path with two arguments (ctx and tpath), whereas RendererCairo.convert_path expects three arguments. In one other place, RendererCairo.convert_path is called (correctly) with three arguments. One example of the code containing the bug is
>
> tpath, affine = clippath.get_transformed_path_and_affine()
> ctx.new_path()
> affine = affine + Affine2D().scale(1.0, -1.0).translate(0.0, self.height)
> tpath = affine.transform_path(tpath)
> RendererCairo.convert_path(ctx, tpath)
>
> Before this revision, the corresponding code was 
>
> tpath, affine = path.get_transformed_path_and_affine()
> ctx.new_path()
> affine = affine + Affine2D().scale(1.0, -1.0).translate(0.0, self.renderer.height)
> RendererCairo.convert_path(ctx, path, affine) 	 
>
> RendererCairo.convert_path is defined as
>
> @staticmethod
> def convert_path(ctx, path, transform):
>
> so with three arguments. Either the calls to convert_path are incorrect, or convert_path should be updated to handle two arguments.
>
> --Michiel
>
>
> 
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations 
> Conference from O'Reilly Media. Velocity features a full day of 
> expert-led, hands-on workshops and two days of sessions from industry 
> leaders in dedicated Performance & Operations tracks. Use code vel09scf 
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi everybody,
I believe a bug was introduced in revision 7002 of backend_cairo.py.
This code, in two places, now calls RendererCairo.convert_path with two arguments (ctx and tpath), whereas RendererCairo.convert_path expects three arguments. In one other place, RendererCairo.convert_path is called (correctly) with three arguments. One example of the code containing the bug is
tpath, affine = clippath.get_transformed_path_and_affine()
ctx.new_path()
affine = affine + Affine2D().scale(1.0, -1.0).translate(0.0, self.height)
tpath = affine.transform_path(tpath)
RendererCairo.convert_path(ctx, tpath)
Before this revision, the corresponding code was 
tpath, affine = path.get_transformed_path_and_affine()
ctx.new_path()
affine = affine + Affine2D().scale(1.0, -1.0).translate(0.0, self.renderer.height)
RendererCairo.convert_path(ctx, path, affine) 	 
RendererCairo.convert_path is defined as
 @staticmethod
 def convert_path(ctx, path, transform):
so with three arguments. Either the calls to convert_path are incorrect, or convert_path should be updated to handle two arguments.
--Michiel