matplotlib-devel Mailing List for matplotlib (Page 3)

>
> On Wed, Nov 11, 2009 at 7:12 PM, Andrew Straw <str...@as...> wrote:
>   
>> > I had a patch waiting in the wings for that, but I wanted to see the dust
>> > settle before committing it. I think the dust is officially settled, so
>> > please commit yours or else I'll commit mine.
>> >
>>     
>
> Please go ahead.
>   
Will do.


>> By the way, I just encountered some zorder issue with the new patch.
>> The thing is, zorder=1 for Images seems to high.
>> For example, patches also have zorders=1. So, if I draw an image, and
>> add some patches (which I often do to indicate regions of interests),
>> the patches are drawn before images and become invisible. This happens
>> because images are appended to dsu list after all other artists.
>>
>>     
>
> The other thing I noticed by quickly going through axes.py is that
> when _axisbelow==True, the zorders of xaxis and yaxis is set to 0.5,
> which is lower than images. While the doc say
>
>           *axisbelow*        draw the grids and ticks below the other
>                              artists
>
> I don't think one wants to draw axis (grid+ticks) even below images.
>
> Well, there should be a few ways to fix this, but how others think
> about reducing the Image's zorder to 0?

I'm fine with the default Image's zorder at 0 -- I'm explicitly setting 
it for the cases I'm interested in anyway, and I think that would give 
better consistency with the old way. Also, I think this is better and 
more explicit than just inserting them at the beginning of the dsu list 
and relying on a stable sort to keep them drawn below various patches, 
which is how I interpreted your meaning for that approach.

I'll check in this change, too.

-Andrew

On Thu, Nov 12, 2009 at 3:45 PM, Jae-Joon Lee <lee...@gm...> wrote:
> By the way, I just encountered some zorder issue with the new patch.
> The thing is, zorder=1 for Images seems to high.
> For example, patches also have zorders=1. So, if I draw an image, and
> add some patches (which I often do to indicate regions of interests),
> the patches are drawn before images and become invisible. This happens
> because images are appended to dsu list after all other artists.
>

The other thing I noticed by quickly going through axes.py is that
when _axisbelow==True, the zorders of xaxis and yaxis is set to 0.5,
which is lower than images. While the doc say

          *axisbelow*        draw the grids and ticks below the other
                             artists

I don't think one wants to draw axis (grid+ticks) even below images.

Well, there should be a few ways to fix this, but how others think
about reducing the Image's zorder to 0?

Regards,

-JJ

Jouni K. Seppänen wrote:
> No, that's exactly what I was thinking about - some newly-found font
> might break matplotlib, or might change somebody's output because of the
> font matching algorithm. 
> Actually, the font matching system can
> sometimes break things:
>
> http://thread.gmane.org/gmane.comp.python.matplotlib.general/18255/focus=18260
>   
Sorry that fell by the wayside.  On further investigation, there are two 
bugs here:

1) The "stretch" metric is not read from .afm files: it's always set to 
"normal", therefore, when specifying "Helvetica" which exists in a 
number of widths, it has an equal chance of choosing any of them 
depending on dictionary ordering.  Note that now {'family': 'Helvetica', 
'stretch': 'narrow'} should and does return "Helvetica-Narrow".  Both 
"Helvetica" and "Helvetica-Narrow" are of the same font family, so that 
in itself is not a bug (it's the same mechanism that makes {'family': 
'Helvetica', 'weight': 'bold'} give "Helvetica-Bold").

2) When pdf.use14corefonts is True, it will actually pull an afm font 
file from anywhere, not just from mpl-data/fonts/pdfcorefonts.  There's 
actually some logic in the FontManager to collect files from only that 
directory when "pdf.use14corefonts" is True, but that's only triggered 
at cache-build time.  That's how bug 1) resulted in adding a font that 
isn't a PDF core font to a PDF file.  But it would be just as easy to 
specify some other random "afm" font on the system and break things in 
the same way.

Lastly, to support all this, the cache needs to be thrown away, so I 
added support for versioning of the cache file -- if it doesn't match 
what the currently-installed matplotlib expects, it's thrown away and 
regenerated.

Mike
> Did that ever get fixed?
>
> Jouni
>
> Michael Droettboom <md...@st...> writes:
>
>   
>> Sorry about that bug.  Obviously it wasn't tested properly.
>>
>> It seems like the only side effect of this change is that matplotlib 
>> will pull in fonts from non-standard locations defined in their 
>> fontconfig configuration.  (It's already pulling them from standard 
>> locations that are hardcoded in font_manager.py).  There's a chance that 
>> some of these fonts will cause matplotlib to explode -- but no more so 
>> than if there were in a standard location.
>>
>> I think it seems like a pretty benign change -- unless there's something 
>> in particular you're thinking of that I'm not...
>>
>> Mike
>>
>> Jouni K. Seppänen wrote:
>>     
>>> Because of the problem described here:
>>>
>>> http://thread.gmane.org/gmane.comp.python.matplotlib.general/20328
>>>
>>> I modified font_manager.py to use subprocess.Popen instead of
>>> commands.getstatusoutput, since subprocess seems to deal with EINTR
>>> while the commands module does not. While looking at it, I changed the
>>> command being run from
>>>
>>> fc-list file
>>>
>>> to
>>>
>>> fc-list '' file
>>>
>>> because the former doesn't return any fonts on any system I have access
>>> to (maybe it would if I had a font whose name includes the word "file"),
>>> but the latter looks more like it is the intended command. Since the
>>> get_fontconfig_fonts function has not returned anything useful for some
>>> time (though presumably it has at some point in the past), this change
>>> might have big effects somewhere else.
>>>
>>> Would this change be appropriate for the bugfix branch?
>>>
>>>   
>>>       
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Wed, Nov 11, 2009 at 7:12 PM, Andrew Straw <str...@as...> wrote:
> I had a patch waiting in the wings for that, but I wanted to see the dust
> settle before committing it. I think the dust is officially settled, so
> please commit yours or else I'll commit mine.
>

Please go ahead.

By the way, I just encountered some zorder issue with the new patch.
The thing is, zorder=1 for Images seems to high.
For example, patches also have zorders=1. So, if I draw an image, and
add some patches (which I often do to indicate regions of interests),
the patches are drawn before images and become invisible. This happens
because images are appended to dsu list after all other artists.

Reducing the zorder of images would be a one option. Or we may add
images to the dsu list before all other artists, which seems sensible
to me.

Regards,

-JJ

No, that's exactly what I was thinking about - some newly-found font
might break matplotlib, or might change somebody's output because of the
font matching algorithm. Actually, the font matching system can
sometimes break things:

http://thread.gmane.org/gmane.comp.python.matplotlib.general/18255/focus=18260

Did that ever get fixed?

Jouni

Michael Droettboom <md...@st...> writes:

> Sorry about that bug.  Obviously it wasn't tested properly.
>
> It seems like the only side effect of this change is that matplotlib 
> will pull in fonts from non-standard locations defined in their 
> fontconfig configuration.  (It's already pulling them from standard 
> locations that are hardcoded in font_manager.py).  There's a chance that 
> some of these fonts will cause matplotlib to explode -- but no more so 
> than if there were in a standard location.
>
> I think it seems like a pretty benign change -- unless there's something 
> in particular you're thinking of that I'm not...
>
> Mike
>
> Jouni K. Seppänen wrote:
>> Because of the problem described here:
>>
>> http://thread.gmane.org/gmane.comp.python.matplotlib.general/20328
>>
>> I modified font_manager.py to use subprocess.Popen instead of
>> commands.getstatusoutput, since subprocess seems to deal with EINTR
>> while the commands module does not. While looking at it, I changed the
>> command being run from
>>
>> fc-list file
>>
>> to
>>
>> fc-list '' file
>>
>> because the former doesn't return any fonts on any system I have access
>> to (maybe it would if I had a font whose name includes the word "file"),
>> but the latter looks more like it is the intended command. Since the
>> get_fontconfig_fonts function has not returned anything useful for some
>> time (though presumably it has at some point in the past), this change
>> might have big effects somewhere else.
>>
>> Would this change be appropriate for the bugfix branch?
>>
>>   

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

Sorry about that bug.  Obviously it wasn't tested properly.

It seems like the only side effect of this change is that matplotlib 
will pull in fonts from non-standard locations defined in their 
fontconfig configuration.  (It's already pulling them from standard 
locations that are hardcoded in font_manager.py).  There's a chance that 
some of these fonts will cause matplotlib to explode -- but no more so 
than if there were in a standard location.

I think it seems like a pretty benign change -- unless there's something 
in particular you're thinking of that I'm not...

Mike

Jouni K. Seppänen wrote:
> Because of the problem described here:
>
> http://thread.gmane.org/gmane.comp.python.matplotlib.general/20328
>
> I modified font_manager.py to use subprocess.Popen instead of
> commands.getstatusoutput, since subprocess seems to deal with EINTR
> while the commands module does not. While looking at it, I changed the
> command being run from
>
> fc-list file
>
> to
>
> fc-list '' file
>
> because the former doesn't return any fonts on any system I have access
> to (maybe it would if I had a font whose name includes the word "file"),
> but the latter looks more like it is the intended command. Since the
> get_fontconfig_fonts function has not returned anything useful for some
> time (though presumably it has at some point in the past), this change
> might have big effects somewhere else.
>
> Would this change be appropriate for the bugfix branch?
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Because of the problem described here:

http://thread.gmane.org/gmane.comp.python.matplotlib.general/20328

I modified font_manager.py to use subprocess.Popen instead of
commands.getstatusoutput, since subprocess seems to deal with EINTR
while the commands module does not. While looking at it, I changed the
command being run from

fc-list file

to

fc-list '' file

because the former doesn't return any fonts on any system I have access
to (maybe it would if I had a font whose name includes the word "file"),
but the latter looks more like it is the intended command. Since the
get_fontconfig_fonts function has not returned anything useful for some
time (though presumably it has at some point in the past), this change
might have big effects somewhere else.

Would this change be appropriate for the bugfix branch?

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

Thanks.  This is applied in r7952 and r7954.

Mike

Urs Fleisch wrote:
> A function to get the font properties angle is missing in the EMF backend of matplotlib 0.99.1. This patch has to be applied in addition to  patch https://sourceforge.net/tracker/index.php?func=detail&aid=2853659&group_id=80706&atid=560722 (is already applied  to svn HEAD r7706) to fix the problem.
>
> You can find the patch at
>
> https://sourceforge.net/tracker/?func=detail&aid=2896459&group_id=80706&atid=560722
>
>   
>> JDH: None of the core mpl developers are
>> win32 users, so we will defer to you as to what is best for this backend.
>>     
>
> No problem, but you can test the EMF backend also without win32, OpenOffice supports EMF pictures.
>
> Regards,
> Urs
>
>
>
>       
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> 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

A function to get the font properties angle is missing in the EMF backend of matplotlib 0.99.1. This patch has to be applied in addition to  patch https://sourceforge.net/tracker/index.php?func=detail&aid=2853659&group_id=80706&atid=560722 (is already applied  to svn HEAD r7706) to fix the problem.

You can find the patch at

https://sourceforge.net/tracker/?func=detail&aid=2896459&group_id=80706&atid=560722

> JDH: None of the core mpl developers are
> win32 users, so we will defer to you as to what is best for this backend.

No problem, but you can test the EMF backend also without win32, OpenOffice supports EMF pictures.

Regards,
Urs



      

Jae-Joon Lee wrote:
> I also committed a small patch that makes zorders respected among
> images (not with other artists) for noncomposit backends.
>   
That looks fine to me. Thanks.
> Anyhow, can we get rid of the second items in the "dsu" list? My guess
> is that this is to make the sort stable, but python sort is already
> stable, isn't it?
>   
I had a patch waiting in the wings for that, but I wanted to see the 
dust settle before committing it. I think the dust is officially 
settled, so please commit yours or else I'll commit mine.

-Andrew

I also committed a small patch that makes zorders respected among
images (not with other artists) for noncomposit backends.

Anyhow, can we get rid of the second items in the "dsu" list? My guess
is that this is to make the sort stable, but python sort is already
stable, isn't it?

-JJ

On Tue, Nov 10, 2009 at 4:06 PM, Andrew Straw <str...@as...> wrote:
> Andrew Straw wrote:
>> John Hunter wrote:
>>
>>> On Mon, Nov 9, 2009 at 10:21 AM, Andrew Straw <str...@as...> wrote:
>>>
>>>
>>>> Hi All,
>>>>
>>>> I have addressed what I think is a long-standing wart: zorder is mostly
>>>> ignored for imshow(). (See e.g.
>>>> http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314
>>>> ) The question is whether I should apply the attached patch.
>>>>
> I went ahead and committed this patch to the trunk in r7950.
>
> Here's the CHANGELOG entry:
>
> 2009-11-10 Single images, and all images in renderers with
>           option_image_nocomposite (i.e. agg, macosx and the svg
>           backend when rcParams['svg.image_noscale'] is True), are
>           now drawn respecting the zorder relative to other
>           artists. (Note that there may now be inconsistencies across
>           backends when more than one image is drawn at varying
>           zorders, but this change introduces correct behavior for
>           the backends in which it's easy to do so.)
>
> Jae Joon raised a couple of concerns:
>
> 1) the patch would introduces inconsistent behavior between backends --
> namely that PS and other backends, when given more than one image, would
> "composite" (or rasterize) all images and stick them underneath
> everything else. Agg would have proper zordering between images and
> other artists.
>
> 2) there is doubt about the utility of such functionality. Jae-Joon says
> "I think it is often sufficient if we draw images at the bottom but
> respect zorders among images".
>
> As for #1, it seems to me this is simply a bug/limitation with the
> compositing functionality (e.g. the PS backend). The SVG backend has the
> possibility to turn compositing on or off based on the svg.image_noscale
> rcParam, and perhaps other backends could grow something similar. I
> can't see why this patch -- that specifically solves the bug/limitation
> in the backends where its easily possible -- should be held back due to
> this.
>
> As for #2, perhaps my use case will be convincing -- I'm trying to draw
> reconstructions of various experimental setups, and the easiest way to
> do this is to create texture-mapped rectangles in which I can control
> the zorder -- a single texture may need to be over some artists but
> under others. Perhaps there's an easier way to achieve this, but I'm not
> aware of it.
>
> Jae Joon has also stated that he's OK with the patch, so I went ahead
> and committed it. In light of all this, please let me know if you still
> have concerns, and hopefully they can be addressed. In the worst case,
> we can back this patch out.
>
> -Andrew
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Andrew Straw wrote:
> John Hunter wrote:
>   
>> On Mon, Nov 9, 2009 at 10:21 AM, Andrew Straw <str...@as...> wrote:
>>   
>>     
>>> Hi All,
>>>
>>> I have addressed what I think is a long-standing wart: zorder is mostly
>>> ignored for imshow(). (See e.g.
>>> http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314
>>> ) The question is whether I should apply the attached patch.
>>>     
I went ahead and committed this patch to the trunk in r7950.

Here's the CHANGELOG entry:

2009-11-10 Single images, and all images in renderers with
           option_image_nocomposite (i.e. agg, macosx and the svg
           backend when rcParams['svg.image_noscale'] is True), are
           now drawn respecting the zorder relative to other
           artists. (Note that there may now be inconsistencies across
           backends when more than one image is drawn at varying
           zorders, but this change introduces correct behavior for
           the backends in which it's easy to do so.)

Jae Joon raised a couple of concerns:

1) the patch would introduces inconsistent behavior between backends -- 
namely that PS and other backends, when given more than one image, would 
"composite" (or rasterize) all images and stick them underneath 
everything else. Agg would have proper zordering between images and 
other artists.

2) there is doubt about the utility of such functionality. Jae-Joon says 
"I think it is often sufficient if we draw images at the bottom but 
respect zorders among images".

As for #1, it seems to me this is simply a bug/limitation with the 
compositing functionality (e.g. the PS backend). The SVG backend has the 
possibility to turn compositing on or off based on the svg.image_noscale 
rcParam, and perhaps other backends could grow something similar. I 
can't see why this patch -- that specifically solves the bug/limitation 
in the backends where its easily possible -- should be held back due to 
this.

As for #2, perhaps my use case will be convincing -- I'm trying to draw 
reconstructions of various experimental setups, and the easiest way to 
do this is to create texture-mapped rectangles in which I can control 
the zorder -- a single texture may need to be over some artists but 
under others. Perhaps there's an easier way to achieve this, but I'm not 
aware of it.

Jae Joon has also stated that he's OK with the patch, so I went ahead 
and committed it. In light of all this, please let me know if you still 
have concerns, and hopefully they can be addressed. In the worst case, 
we can back this patch out.

-Andrew

On Mon, Nov 9, 2009 at 3:55 PM, Andrew Straw <str...@as...> wrote:
> What's the motivation of the ps backend "compositing" (rasterizing to a
> single bitmap) multiple images? It seems it will, by design, preclude the
> use of non-image artists between two images. I guess the motivation is to
> reduce output file size. Maybe Axes.draw() should disable compositing in the
> scenario where a non-image artist is sandwiched by image artists and suffer
> the increased file size.
>

I can't say about what the original intention was, but I guess one of
the benefit is that you can have alpha compositing of multiple images.
I personally think that no alpha support for images is a more serious
issue than no alpha support for other artists like lines and patches.
So, I'm +1 for doing the alpha compositing of images before passing it
to the backends (that do not support the alpha compositing).

However, as I said in my first email, I don't think there are much
cases that this actually matters,
while I'm also not sure about the benefit of having images above other
artists like lines.

Anyhow, as far as zorders between images are respected (in all
backends!), it should be good.

Regards,

-JJ

On Mon, Nov 9, 2009 at 3:08 PM, Leonid Petrov <ma...@lp...> wrote:
> Hi, John,
>
>  I got mpl from
>
> http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.1/matplotlib-0.99.1.1.tar.gz/download
>
> /d1/incoming> md5sum matplotlib-0.99.1.1.tar.gz
> bd0894dd924eb5bec84c42d26041a544  matplotlib-0.99.1.1.tar.gz
>
> I removed source code of matplotlib-0.99.1.1 from my previous attempt to
> install it and did it again.
>
> cd /d1/dist
> tar -zxf /d1/incoming/matplotlib-0.99.1.1.tar.gz
> cd matplotlib-0.99.1.1/
> python setup.py install --prefix=/opt64 > & matplotlib-0.99.1.1_comp.log
>
> gzip matplotlib-0.99.1.1_comp.log
> cp matplotlib-0.99.1.1_comp.log.gz         /pub/
> cp setup.cfg                               /pub/matplotlib-0.99.1.1_comp.log.gz
> cp /d1/incoming/matplotlib-0.99.1.1.tar.gz /pub/
>
> You can get them from
>
> ftp://71.178.13.84/matplotlib-0.99.1.1_comp.log
> ftp://71.178.13.84/matplotlib-0.99.1.1.tar.gz
> ftp://71.178.13.84/matplotlib-0.99.1.1_setup.cfg
>
> But stop, stop, stop... I looked at setup.cfg and found there at line 58
> macosx = True

Glad you found the fix -- I'm just uploaded a new tarball now with the
setup.cfg removed.

JDH

Hi, John,

  I got mpl from 

http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.1/matplotlib-0.99.1.1.tar.gz/download

/d1/incoming> md5sum matplotlib-0.99.1.1.tar.gz
bd0894dd924eb5bec84c42d26041a544  matplotlib-0.99.1.1.tar.gz

I removed source code of matplotlib-0.99.1.1 from my previous attempt to
install it and did it again.

cd /d1/dist
tar -zxf /d1/incoming/matplotlib-0.99.1.1.tar.gz
cd matplotlib-0.99.1.1/
python setup.py install --prefix=/opt64 > & matplotlib-0.99.1.1_comp.log

gzip matplotlib-0.99.1.1_comp.log            
cp matplotlib-0.99.1.1_comp.log.gz         /pub/
cp setup.cfg                               /pub/matplotlib-0.99.1.1_comp.log.gz         
cp /d1/incoming/matplotlib-0.99.1.1.tar.gz /pub/

You can get them from

ftp://71.178.13.84/matplotlib-0.99.1.1_comp.log
ftp://71.178.13.84/matplotlib-0.99.1.1.tar.gz
ftp://71.178.13.84/matplotlib-0.99.1.1_setup.cfg

But stop, stop, stop... I looked at setup.cfg and found there at line 58
macosx = True

One more attempt:

cd /d1/dist
rm -fR matplotlib-0.99.1.1
tar -zxf /d1/incoming/matplotlib-0.99.1.1.tar.gz
cd matplotlib-0.99.1.1/
sed -i 's@macosx = True@macosx = False@g' setup.cfg
python setup.py install --prefix=/opt64 > & matplotlib-0.99.1.1_comp.log
echo $?
0
tail -2 matplotlib-0.99.1.1_comp.log
Removing /opt64/lib/python2.6/site-packages/matplotlib-0.99.1.1-py2.6.egg-info
Writing /opt64/lib/python2.6/site-packages/matplotlib-0.99.1.1-py2.6.egg-info

Success!!

Thank you for a quick reply and suggestion to look at setup.cfg .

Leonid

Jae-Joon Lee wrote:
> On Mon, Nov 9, 2009 at 12:44 PM, Eric Firing <ef...@ha...> wrote:
>   
>> PS backend already does things differently from others because it doesn't
>> handle alpha, correct?  Does the patch make this situation any worse?
>>
>>     
>
> When there are multiple Images and render.option_image_nocomposite()
> is false (as in the ps backend ), the images are composited
> (rasterized) into a single image before it is passed to the backend.
> So, AS FAR AS the images are concerned, I think the ps backend does
> handle alpha correctly and the results are consistent between
> backends.
>
> And with the Andrew's patch, and if there are non-image artists
> between two images, the results can be different. For example, those
> non-image artists can be obscured by the foreground image in the agg
> backend, but will always show up in the ps backend.
> So, I think this is somewhat different issue than alpha being ignored
> in the ps backend.
>   
What's the motivation of the ps backend "compositing" (rasterizing to a 
single bitmap) multiple images? It seems it will, by design, preclude 
the use of non-image artists between two images. I guess the motivation 
is to reduce output file size. Maybe Axes.draw() should disable 
compositing in the scenario where a non-image artist is sandwiched by 
image artists and suffer the increased file size.

-Andrew

Darren,

Have you happened to review Pierre's patch for the toolbar
improvement? I am interested to see this integrated in mpl soon.

Thanks.

On Mon, Nov 9, 2009 at 2:43 PM, Pierre Raybaut <co...@py...> wrote:
> Hi,
>
> I've already sent everything to Darren. I don't have any news but I
> guess that it will be integrated soon.
>
> Pierre
>
> 2009/11/9 Gökhan Sever <gok...@gm...>:
>> Hi Pierre,
>>
>> What is the latest status on this improvement? Will you give a patch
>> to the matplotlib?
>>
>> Please let me know.
>>
>> Thanks
>>
>> On Sat, Jun 6, 2009 at 9:49 AM, Pierre Raybaut <co...@py...> wrote:
>>> 2009/4/28 Dave Peterson <dpe...@en...>:
>>>> Darren Dale wrote:
>>>>
>>>> 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
>>>>
>>>> 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
>>>>
>>>>
>>>
>>> Hi all,
>>>
>>> Dave, you are absolutely right.
>>>
>>> Last week-end, I found myself surfing on PyQt's website and I told to
>>> myself: what about re-reading the license? (always a pleasure) And
>>> surprisingly, I found out that anyone using the GPL version of PyQt
>>> can release source code under a very permissive license (like MIT or
>>> BSD) thanks to the PyQt-GPL Exception, as long as PyQt itself is not
>>> part of the distributed package (otherwise the whole package has to be
>>> licensed under GPL) - and with other little restrictions. It was a
>>> surprise because I've read here and there a lot of things on PyQt
>>> license and the general idea was "if you write PyQt code without the
>>> commercial license, your code *must* be licensed under GPL" - I can
>>> tell now that it's not true (to be absolutely certain about it, I even
>>> asked to Phil Thompson to confirm this, and he did).
>>>
>>> So, I switched all the code I was referring to in my original e-mail
>>> to MIT license.
>>> I guess now it could be integrated to matplotlib Qt4 backend?
>>>
>>> formlayout (generate option dialogs):
>>> http://code.google.com/p/formlayout/
>>>
>>> pydee (IDE which integrates matplotlib and the option dialog):
>>> http://code.google.com/p/pydee/
>>> Meanwhile, thanks to the brand new Google-code Mercurial support, you
>>> may browse the source code if you like:
>>> http://code.google.com/p/pydee/source/browse/pydeelib/widgets/figureoptions.py
>>>
>>> Cheers,
>>> Pierre
>>>
>>> ------------------------------------------------------------------------------
>>> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
>>> looking to deploy the next generation of Solaris that includes the latest
>>> innovations from Sun and the OpenSource community. Download a copy and
>>> enjoy capabilities such as Networking, Storage and Virtualization.
>>> Go to: http://p.sf.net/sfu/opensolaris-get
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>
>>
>>
>> --
>> Gökhan
>>
>



-- 
Gökhan

On Mon, Nov 9, 2009 at 1:29 PM, Leonid Petrov <ma...@lp...> wrote:
> Hi, matplotlibers,
>
>  I tried to compile matplotlib0.99.1.1 against Python-2.6.4, numpy-1.3.0,
> libpng-1.2.40, freetype-2.3.11 with the following command:
> python setup.py install --prefix=/opt64 > & comp.log
>
>  I got
>
> building 'matplotlib.backends._macosx' extension
> /opt64/bin/gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/opt64/include -I/opt64/include/wx-2.8 -I/opt64/lib/wx/include/gtk2-ansi-release-2.8 -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -I/opt64/lib/python2.6/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/opt64/lib/python2.6/site-packages/numpy/core/include -Isrc -Iagg24/include -I. -I/opt64/include/python2.6 -c src/_macosx.m -o build/temp.linux-x86_64-2.6/src/_macosx.o
> src/_macosx.m:1:25: error: Cocoa/Cocoa.h: No such file or directory
> src/_macosx.m:2:53: error: ApplicationServices/ApplicationServices.h: No such file or directory
> src/_macosx.m:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'style'
>
>
>  I checked, I have neither Cocoa.h , nor ApplicationServices.h in my system
> ( Linux 2.6.28-16-generic #55-Ubuntu SMP ). I have no idea to which
> package headers Cocoa.h and ApplicationServices.h belong.
>
>  Which additional source packages, not mentioned in
> http://matplotlib.sourceforge.net/users/installing.html, should I download
> and compile in order to build  matplotli

For some reason mpl is trying to build the macosx backend (for OSX)
even though you are on linux.  Please do a clean build (rm -rf build)
and capture all stdout and stderr into a file when rebuilding and post
it.  Also see if you have a setup.cfg file in your mpl dir next to
setup.py and post it.

Finally, where did you get the mpl src from?

JDH

Hi, matplotlibers,

  I tried to compile matplotlib0.99.1.1 against Python-2.6.4, numpy-1.3.0,
libpng-1.2.40, freetype-2.3.11 with the following command:
python setup.py install --prefix=/opt64 > & comp.log

  I got 

building 'matplotlib.backends._macosx' extension
/opt64/bin/gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/opt64/include -I/opt64/include/wx-2.8 -I/opt64/lib/wx/include/gtk2-ansi-release-2.8 -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -I/opt64/lib/python2.6/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/opt64/lib/python2.6/site-packages/numpy/core/include -Isrc -Iagg24/include -I. -I/opt64/include/python2.6 -c src/_macosx.m -o build/temp.linux-x86_64-2.6/src/_macosx.o
src/_macosx.m:1:25: error: Cocoa/Cocoa.h: No such file or directory
src/_macosx.m:2:53: error: ApplicationServices/ApplicationServices.h: No such file or directory
src/_macosx.m:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'style'


  I checked, I have neither Cocoa.h , nor ApplicationServices.h in my system 
( Linux 2.6.28-16-generic #55-Ubuntu SMP ). I have no idea to which 
package headers Cocoa.h and ApplicationServices.h belong. 

  Which additional source packages, not mentioned in 
http://matplotlib.sourceforge.net/users/installing.html, should I download 
and compile in order to build  matplotlib?

Thank you in advance,
Leonid

On Mon, Nov 9, 2009 at 12:44 PM, Eric Firing <ef...@ha...> wrote:
> PS backend already does things differently from others because it doesn't
> handle alpha, correct?  Does the patch make this situation any worse?
>

When there are multiple Images and render.option_image_nocomposite()
is false (as in the ps backend ), the images are composited
(rasterized) into a single image before it is passed to the backend.
So, AS FAR AS the images are concerned, I think the ps backend does
handle alpha correctly and the results are consistent between
backends.

And with the Andrew's patch, and if there are non-image artists
between two images, the results can be different. For example, those
non-image artists can be obscured by the foreground image in the agg
backend, but will always show up in the ps backend.
So, I think this is somewhat different issue than alpha being ignored
in the ps backend.

Regards,

-JJ

On Mon, Nov 9, 2009 at 12:16 PM, Andrew Straw <str...@as...> wrote:

> So now the question for me is what is this option_image_nocomposite is so
> that I can generalize the patch to both when it's True and False. From the

The compositing is in support of things like
pylab_examples/layer_images.py, where two images, possibly of
different sizes, are composited together

On Mon, Nov 9, 2009 at 12:12 PM, Jae-Joon Lee <lee...@gm...> wrote:
> On Mon, Nov 9, 2009 at 1:01 PM, John Hunter <jd...@gm...> wrote:
>> Your
>> patch is only applied when len(images)<=1 or
>> renderer.option_image_nocomposite(), both of which will be False when
>> using Agg with multiple images, no?
>
> I believe renderer.option_image_nocomposite() is True for the agg backend.
> So, it will work with agg.

Ahh, you're right.  Thanks.

JDH

John Hunter wrote:
> On Mon, Nov 9, 2009 at 10:21 AM, Andrew Straw <str...@as...> wrote:
>   
>> Hi All,
>>
>> I have addressed what I think is a long-standing wart: zorder is mostly
>> ignored for imshow(). (See e.g.
>> http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314
>> ) The question is whether I should apply the attached patch.
>>     
>
> Will this help with the OP's original "wart", which was the inability
> to add multiple images and move one to the top with zorder.  Your
> patch is only applied when len(images)<=1 or
> renderer.option_image_nocomposite(), both of which will be False when
> using Agg with multiple images, no?
>   
OK, sorry I linked to a motivating example that actually wasn't exactly 
the same as the use case I have -- I want a single image to play well 
with other artists' zorder. This patch does handle that scenario. I 
simply was too quick choosing this example out of the email history to 
justify the patch.

So now the question for me is what is this option_image_nocomposite is 
so that I can generalize the patch to both when it's True and False. 
 From the emails here, (my only knowledge on it so far) it seems it has 
something to do with the capabilities of the renderer rather than a 
run-time option selected by the user. I'll dig a little deeper into this 
option and see if my patch can deal with other cases, too. Stay tuned...

-Andrew

On Mon, Nov 9, 2009 at 1:01 PM, John Hunter <jd...@gm...> wrote:
> Your
> patch is only applied when len(images)<=1 or
> renderer.option_image_nocomposite(), both of which will be False when
> using Agg with multiple images, no?

I believe renderer.option_image_nocomposite() is True for the agg backend.
So, it will work with agg.

-JJ

On Mon, Nov 9, 2009 at 10:21 AM, Andrew Straw <str...@as...> wrote:
> Hi All,
>
> I have addressed what I think is a long-standing wart: zorder is mostly
> ignored for imshow(). (See e.g.
> http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314
> ) The question is whether I should apply the attached patch.

Will this help with the OP's original "wart", which was the inability
to add multiple images and move one to the top with zorder.  Your
patch is only applied when len(images)<=1 or
renderer.option_image_nocomposite(), both of which will be False when
using Agg with multiple images, no?

JDH