matplotlib-devel Mailing List for matplotlib

On Thu, Apr 30, 2009 at 2:29 PM, John Hunter <jd...@gm...> wrote:
>
>
> On Thu, Apr 30, 2009 at 4:14 PM, T J <tj...@gm...> wrote:
>>
>> Fill between is for filling between two y-values over a range of
>> x-values.  Is there anything which fills between to x-values over a
>> range of y-values?
>
> Nothing with the ease of use of fill_between, but you can always write your
> own PolyCollection, which is what fill_between does (see the function
> implementation for details) or create a Polygon for a simple region.  My use
> cases are typically in the time series world where I have datetime on the
> x-axis and some range of values on the y.  If folks think it is sufficiently
> useful to have a fill_betweenx function with a similar interface, you could
> probably fairly easy port fill_between to fill_betweenx.
>
>   http://matplotlib.sourceforge.net/faq/howto_faq.html#contributing-howto
>

Done.  Attached diff is against rev7075.

On Thu, Apr 30, 2009 at 4:10 PM, Michael Abshoff <mab...@go...>wrote:

> On Thu, Apr 30, 2009 at 6:29 AM, Michael Droettboom <md...@st...>
> wrote:
> > Thanks.  I have committed this to the 0.98.x branch and the trunk, so
> > this fix will make it into the next release.
> >
> > Mike
>
> Excellent. For the record this is/was also a problem on some FreeBSD
> releases, so I am glad it was cleanly fixed.
>
> I have been sitting on some trivial FreeBSD 7/8 and a gcc 4.4 build
> fix. Is it still time to get those into 0.98.x?


There is certainly time to get it into the trunk -- if you want to put it in
as a bugfix on the branch, you must be pretty sure that this will not break
anything because it is a bugfix release.

JDH

On Thu, Apr 30, 2009 at 6:29 AM, Michael Droettboom <md...@st...> wrote:
> Thanks.  I have committed this to the 0.98.x branch and the trunk, so
> this fix will make it into the next release.
>
> Mike

Excellent. For the record this is/was also a problem on some FreeBSD
releases, so I am glad it was cleanly fixed.

I have been sitting on some trivial FreeBSD 7/8 and a gcc 4.4 build
fix. Is it still time to get those into 0.98.x?

Cheers,

Michael

Jae-Joon Lee <lee...@gm...> writes:

> I don't see such any error and I'm not sure if the error is related
> with my patch since the ps backend does not use dviread module.

Darren didn't include the complete traceback, but it seems that dviread
does get used by TexManager.get_text_width_height_descent unless the
text.latex.preview parameter is set. So if preview.sty is available,
setting the parameter might help with that particular problem.

> On Thu, Apr 30, 2009 at 11:44 AM, Darren Dale <dsd...@gm...> wrote:
>>   File "/usr/lib64/python2.6/subprocess.py", line 1084, in _execute_child
>>     data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB
>> OSError: [Errno 4] Interrupted system call

I thought subprocess.el handled EINTR, but apparently not:

http://bugs.python.org/issue1068268

I guess the reason why some people run into this and others don't is
that (some) GUI toolkits make use of signals, and the probability of
receiving a signal while reading from the subprocess pipe depends on
various system-specific details.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On Thu, Apr 30, 2009 at 11:44 AM, Darren Dale <dsd...@gm...> wrote:
> I have to make several attempts before the test script will run to
> completion, I get errors like:
>
>   File "/usr/lib64/python2.6/site-packages/matplotlib/dviread.py", line 812,
> in find_tex_file
>     pipe = subprocess.Popen(cmd, stdout=subprocess.PIPE)
>   File "/usr/lib64/python2.6/subprocess.py", line 595, in __init__
>     errread, errwrite)
>   File "/usr/lib64/python2.6/subprocess.py", line 1084, in _execute_child
>     data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB
> OSError: [Errno 4] Interrupted system call
>

I don't see such any error and I'm not sure if the error is related
with my patch since the ps backend does not use dviread module.

Anyhow, I just committed the patch for the landscape mode, so that
others can test.
I'll revert the changes if they seem to cause more harm than good.

Regards,

-JJ


> Aside from that, the results from this patch look better. Thanks,
> Darren
>
> On Wed, Apr 29, 2009 at 5:57 PM, Jae-Joon Lee <lee...@gm...> wrote:
>>
>> 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
>> >>
>> >>
>> >
>
>

I have to make several attempts before the test script will run to
completion, I get errors like:

  File "/usr/lib64/python2.6/site-packages/matplotlib/dviread.py", line 812,
in find_tex_file
    pipe = subprocess.Popen(cmd, stdout=subprocess.PIPE)
  File "/usr/lib64/python2.6/subprocess.py", line 595, in __init__
    errread, errwrite)
  File "/usr/lib64/python2.6/subprocess.py", line 1084, in _execute_child
    data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB
OSError: [Errno 4] Interrupted system call

Aside from that, the results from this patch look better. Thanks,
Darren

On Wed, Apr 29, 2009 at 5:57 PM, Jae-Joon Lee <lee...@gm...> wrote:

> 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.  I have committed this to the 0.98.x branch and the trunk, so 
this fix will make it into the next release.

Mike

Dave Peterson wrote:
> 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
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> 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

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


      

This patch is now committed to the trunk (r7068).

-JJ


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
>>>
>>
>

Darren Dale wrote:
> On Tue, Apr 28, 2009 at 12:19 PM, Pierre Raybaut <co...@py... 
> <mailto:co...@py...>> wrote:
>
>     2009/4/28 John Hunter <jd...@gm... <mailto:jd...@gm...>>:
>     >
>     >
>     > On Tue, Apr 28, 2009 at 8:18 AM, Pierre Raybaut
>     <co...@py... <mailto:co...@py...>>
>     > wrote:
>     >>
>     >> Hi all,
>     >>
>     >> I would like to contribute to matplotlib with this enhancement
>     for the
>     >> PyQt4 backend: the idea is to add a toolbar button to configure
>     figure
>     >> options (axes, curves, ...).
>     >>
>     >> It's based on a tiny module called formlayout to generate PyQt4
>     form
>     >> dialog automatically.
>     >>
>     >> Some screenshots:
>     >> http://code.google.com/p/formlayout/
>     >>
>     >> So, if you're interested (all the following is GPL2):
>     >>
>     >> *matplotlib patch*
>     >>
>     >> In FigureManagerQT.__init__, added:
>     >> self.canvas.axes = self.canvas.figure.add_subplot(111)
>     >>
>     >> In NavigationToolbar2QT._init_toolbar, added:
>     >> a = self.addAction(self._icon("customize.png"), 'Customize',
>     >> self.edit_parameters)
>     >> a.setToolTip('Edit curves line and axes parameters')
>     >>
>     >> Added the following method in NavigationToolbar2QT:
>     >> def edit_parameters(self):
>     >>    from figureoptions import figure_edit
>     >>    figure_edit(self.canvas, self)
>     >>
>     >> *additionnal modules and data*
>     >>
>     >> formlayout.py (http://code.google.com/p/formlayout/)
>     >> figureoptions.py (http://code.google.com/p/PyQtShell/)
>     >> customize.png (http://code.google.com/p/PyQtShell/)
>     >
>     > Hi Pierre -- this looks very nice (the last link is broken
>     though , I get a
>     > 404 error).  We would be happy to include this in matplotlib or as a
>
>     Here is the last link:
>     http://code.google.com/p/pyqtshell/
>
>     > toolkit.  To contribute it to to mpl,  the license needs to be
>     matplotlib
>     > compatible
>     >
>     (http://matplotlib.sourceforge.net/devel/coding_guide.html#licenses)
>     but we
>     > have more licensing flexibility in a toolkit, though we prefer
>     to keep
>     > everything BSD compatible where possible.   And of course you
>     would need to
>     > agree to maintain it :-) but I think many users would appreciate
>     a GUI plot
>     > configuration dialog.
>
>     I was not aware of this license restriction in matplotlib... I fully
>     understand the motivation, of course, but still: I wrote all this on
>     my free time which means no PyQt4 commercial license, so it can't be
>     anything but GPL. Sorry...
>
>
> I think you have overlooked a subtlety of PyQt4's license. The author 
> of PyQt4 wrote on the enthought-dev mailing list:
>
> "PyQt is GPL but has exceptions that allow it to be used with BSD code -
> hence it's Ok for TraitsBackendQt to be BSD.
>
> However, the exception imposes additional conditions which, to all intents
> and purposes, infects the code with the GPL. To be fair to people that
> should be made clear in any text.
>
> It's still a good idea for TraitsBackendQt to use a BSD license because it
> allows commercial (ie. non-GPL) users to use it without problems."
>
> Darren

I think it might be worth contacting the PyQt folks (Phil Thompson) 
about this.  I think there might be some differences here because Phil 
was the author of TraitsBackendQt and thus his efforts didn't quite fall 
under the "develop under a free license, your results needs to be GPL" 
clause Qt/PyQt have in their licensing.

-- Dave

On Tue, Apr 28, 2009 at 12:19 PM, Pierre Raybaut <co...@py...>wrote:

> 2009/4/28 John Hunter <jd...@gm...>:
> >
> >
> > On Tue, Apr 28, 2009 at 8:18 AM, Pierre Raybaut <co...@py...>
> > wrote:
> >>
> >> Hi all,
> >>
> >> I would like to contribute to matplotlib with this enhancement for the
> >> PyQt4 backend: the idea is to add a toolbar button to configure figure
> >> options (axes, curves, ...).
> >>
> >> It's based on a tiny module called formlayout to generate PyQt4 form
> >> dialog automatically.
> >>
> >> Some screenshots:
> >> http://code.google.com/p/formlayout/
> >>
> >> So, if you're interested (all the following is GPL2):
> >>
> >> *matplotlib patch*
> >>
> >> In FigureManagerQT.__init__, added:
> >> self.canvas.axes = self.canvas.figure.add_subplot(111)
> >>
> >> In NavigationToolbar2QT._init_toolbar, added:
> >> a = self.addAction(self._icon("customize.png"), 'Customize',
> >> self.edit_parameters)
> >> a.setToolTip('Edit curves line and axes parameters')
> >>
> >> Added the following method in NavigationToolbar2QT:
> >> def edit_parameters(self):
> >>    from figureoptions import figure_edit
> >>    figure_edit(self.canvas, self)
> >>
> >> *additionnal modules and data*
> >>
> >> formlayout.py (http://code.google.com/p/formlayout/)
> >> figureoptions.py (http://code.google.com/p/PyQtShell/)
> >> customize.png (http://code.google.com/p/PyQtShell/)
> >
> > Hi Pierre -- this looks very nice (the last link is broken though , I get
> a
> > 404 error).  We would be happy to include this in matplotlib or as a
>
> Here is the last link:
> http://code.google.com/p/pyqtshell/
>
> > toolkit.  To contribute it to to mpl,  the license needs to be matplotlib
> > compatible
> > (http://matplotlib.sourceforge.net/devel/coding_guide.html#licenses) but
> we
> > have more licensing flexibility in a toolkit, though we prefer to keep
> > everything BSD compatible where possible.   And of course you would need
> to
> > agree to maintain it :-) but I think many users would appreciate a GUI
> plot
> > configuration dialog.
>
> I was not aware of this license restriction in matplotlib... I fully
> understand the motivation, of course, but still: I wrote all this on
> my free time which means no PyQt4 commercial license, so it can't be
> anything but GPL. Sorry...
>

I think you have overlooked a subtlety of PyQt4's license. The author of
PyQt4 wrote on the enthought-dev mailing list:

"PyQt is GPL but has exceptions that allow it to be used with BSD code -
hence it's Ok for TraitsBackendQt to be BSD.

However, the exception imposes additional conditions which, to all intents
and purposes, infects the code with the GPL. To be fair to people that
should be made clear in any text.

It's still a good idea for TraitsBackendQt to use a BSD license because it
allows commercial (ie. non-GPL) users to use it without problems."

Darren

2009/4/28 John Hunter <jd...@gm...>:
>
>
> On Tue, Apr 28, 2009 at 8:18 AM, Pierre Raybaut <co...@py...>
> wrote:
>>
>> Hi all,
>>
>> I would like to contribute to matplotlib with this enhancement for the
>> PyQt4 backend: the idea is to add a toolbar button to configure figure
>> options (axes, curves, ...).
>>
>> It's based on a tiny module called formlayout to generate PyQt4 form
>> dialog automatically.
>>
>> Some screenshots:
>> http://code.google.com/p/formlayout/
>>
>> So, if you're interested (all the following is GPL2):
>>
>> *matplotlib patch*
>>
>> In FigureManagerQT.__init__, added:
>> self.canvas.axes = self.canvas.figure.add_subplot(111)
>>
>> In NavigationToolbar2QT._init_toolbar, added:
>> a = self.addAction(self._icon("customize.png"), 'Customize',
>> self.edit_parameters)
>> a.setToolTip('Edit curves line and axes parameters')
>>
>> Added the following method in NavigationToolbar2QT:
>> def edit_parameters(self):
>>    from figureoptions import figure_edit
>>    figure_edit(self.canvas, self)
>>
>> *additionnal modules and data*
>>
>> formlayout.py (http://code.google.com/p/formlayout/)
>> figureoptions.py (http://code.google.com/p/PyQtShell/)
>> customize.png (http://code.google.com/p/PyQtShell/)
>
> Hi Pierre -- this looks very nice (the last link is broken though , I get a
> 404 error).  We would be happy to include this in matplotlib or as a

Here is the last link:
http://code.google.com/p/pyqtshell/

> toolkit.  To contribute it to to mpl,  the license needs to be matplotlib
> compatible
> (http://matplotlib.sourceforge.net/devel/coding_guide.html#licenses) but we
> have more licensing flexibility in a toolkit, though we prefer to keep
> everything BSD compatible where possible.   And of course you would need to
> agree to maintain it :-) but I think many users would appreciate a GUI plot
> configuration dialog.

I was not aware of this license restriction in matplotlib... I fully
understand the motivation, of course, but still: I wrote all this on
my free time which means no PyQt4 commercial license, so it can't be
anything but GPL. Sorry...

Pierre

>
> JDH
>