matplotlib-devel Mailing List for matplotlib

>
> This was causing havoc in contourf; I don't see the logic of multiplying a
> previous alpha by a new one.


Consider a following example that you want to have different alpha for
edgecolor and face color (of course this does not work as of now),

Circle((1, 1), 0.5, ec=(1, 1, 1, 0.2), fc=(1, 0, 0, 1), alpha=1)

If alpha always overrides, it will override both alpha values of the
edge color and facecolor, and we can't have different alphas for edge
and face.
And, in this case, I think the alphas should be multiplied.

Similarly,

Circle((1, 1), 0.5, ec=(1, 1, 1, 0.2), fc=(1, 0, 0, 1), alpha=0.5)

I think it is natural to expect that the resulting alpha of ec to be 0.2*0.5.

For the case of contourf, the problem in my point of view is not that
the alpha is not overridden, but that contourf applies the same alpha
twice.

Whether set_alpha() method override or not would be an implementation
detail, but I guess the above cases at least make some sense.

-JJ

John Hunter wrote:
> 
> 
> On Mon, Mar 23, 2009 at 3:24 PM, Jae-Joon Lee <lee...@gm... 
> <mailto:lee...@gm...>> wrote:
> 
>     The example (e) in my previous script have a code and a text label
>     mismatched.
>     I'm attaching the corrected one.
> 
>     I took a more look on how a patch is drawn.
>     the draw() method of a patch calls draw_path method of the renderer,
>     which seems to be responsible for both "fill", and "stroke". But there
>     is only one alpha value (gc.alpha). The rgbFace is a tuple of r,g,b
>     and does not have a alpha value.
> 
>            renderer.draw_path(gc, tpath, affine, rgbFace)
> 
>     Thus, it seems that is is not possible to have different alpha for
>     "fill" and "stroke".
>     One of the easiest solution would be call the draw_path twice, each
>     for fill and stroke.
> 
> 
> I think we would pay a significant performance hit in some cases to make 
> the call twice.  Perhaps this is a good time to rethink the draw_path 
> and gc signature, since as Eric notes these have evolved over time from 
> the early days when mpl didn't have alpha at all.  One possibility would 
> be to have a facecolor/edgecolor property on the gc itself, which would 
> be rgba tuples.  Since the gc is almost entirely internal, we can revamp 
> it w/o affecting userland code, though it would be nice to support 
> legacy methods (eg gc.set_alpha could warn and then proceed to set the 
> edge and face alpha channel).  Then we would drop the rgbFace argument 
> entirely.  Obviously this would require hacking through a bunch of 
> backend code to fix, but the changes would be fairly straightforward and 
> of the busy-work variety.
> 
> JDH

It may be nearly orthogonal to the lower-level changes you are 
suggesting, John, but before I completely forget about it I would like 
to toss out a very vague idea about reform at a higher level, with 
apologies that I have not thought it through:

Maybe we need an MplColorSpec class.  At present, functions and methods 
typically accept colors and/or color arrays in a wide variety of forms. 
  This is good.  My thought is that these should then be converted by 
the accepting function or method to instances of the new class, and that 
instances of the new class should be accepted as color inputs along with 
all the old forms.  I suspect that this refactoring might, without loss 
of backwards compatibility, make it possible to considerably simplify, 
clarify, and generalize the handling of colors (again, both single 
values and arrays), and provide a less-confusing framework for setting 
and overriding defaults.  I think that as things are now, color spec 
checking and/or conversion are often done repeatedly in a single 
pipeline.  With the class, all this would happen only the first time a 
color spec is encountered.

The class might include mapping, or the present color mapping might 
yield an instance of the class; I have not thought about this aspect.

Eric

On Mon, Mar 23, 2009 at 3:24 PM, Jae-Joon Lee <lee...@gm...> wrote:

> The example (e) in my previous script have a code and a text label
> mismatched.
> I'm attaching the corrected one.
>
> I took a more look on how a patch is drawn.
> the draw() method of a patch calls draw_path method of the renderer,
> which seems to be responsible for both "fill", and "stroke". But there
> is only one alpha value (gc.alpha). The rgbFace is a tuple of r,g,b
> and does not have a alpha value.
>
>        renderer.draw_path(gc, tpath, affine, rgbFace)
>
> Thus, it seems that is is not possible to have different alpha for
> "fill" and "stroke".
> One of the easiest solution would be call the draw_path twice, each
> for fill and stroke.


I think we would pay a significant performance hit in some cases to make the
call twice.  Perhaps this is a good time to rethink the draw_path and gc
signature, since as Eric notes these have evolved over time from the early
days when mpl didn't have alpha at all.  One possibility would be to have a
facecolor/edgecolor property on the gc itself, which would be rgba tuples.
Since the gc is almost entirely internal, we can revamp it w/o affecting
userland code, though it would be nice to support legacy methods (eg
gc.set_alpha could warn and then proceed to set the edge and face alpha
channel).  Then we would drop the rgbFace argument entirely.  Obviously this
would require hacking through a bunch of backend code to fix, but the
changes would be fairly straightforward and of the busy-work variety.

JDH

Jae-Joon Lee wrote:

> 
> Thanks for the explanation.
> I personally think that the default behavior for setting alpha is
> better to be multiplying with the previous one, instead of overriding.

This was causing havoc in contourf; I don't see the logic of multiplying 
a previous alpha by a new one.

> We may introduce override keyword in set_alpha method to to force the
> override. I think it should be considered a bug If there are more than
> one alpha defaults involved. Just a thought.

Yes, it is a bug, but I don't think another kwarg in set_alpha will 
necessarily solve it.

Eric


> And, yes, dealing with the dpi is always confusing!
> 
> -JJ
> 
> 
> ------------------------------------------------------------------------
> 

The example (e) in my previous script have a code and a text label mismatched.
I'm attaching the corrected one.

I took a more look on how a patch is drawn.
the draw() method of a patch calls draw_path method of the renderer,
which seems to be responsible for both "fill", and "stroke". But there
is only one alpha value (gc.alpha). The rgbFace is a tuple of r,g,b
and does not have a alpha value.

        renderer.draw_path(gc, tpath, affine, rgbFace)

Thus, it seems that is is not possible to have different alpha for
"fill" and "stroke".
One of the easiest solution would be call the draw_path twice, each
for fill and stroke.


>
> I can't look at this specifically now, but I suspect it is a side effect of
> the way that alpha support has evolved, resulting in a confusing mess.  Some
> things are RGB, others are RGBA; alpha defaults get set in various places,
> and there is no clear way of keeping track of what is just a default and
> should be overridden, versus what has been set deliberately and should *not*
> be overridden. I dimly remember looking into it a few months ago, thinking
> that it could be cleaned up with some simple changes, but failing.  I really
> wish we could make some sweeps through the mpl code base and systematically
> clean up some of these messes.  I don't know how many there are, but
> certainly more than one. Dpi is another area of perennial confusion, for
> example.
>
> Eric
>
>

Thanks for the explanation.
I personally think that the default behavior for setting alpha is
better to be multiplying with the previous one, instead of overriding.
We may introduce override keyword in set_alpha method to to force the
override. I think it should be considered a bug If there are more than
one alpha defaults involved. Just a thought.
And, yes, dealing with the dpi is always confusing!

-JJ

Jae-Joon Lee wrote:
> Hi,
> 
> When drawing a patch, the alpha value of its edgeolor is ignored. The
> following command draw a circle whose edgecolor has alpha=1, instead
> of 0.1.
> 
> 
> gca().add_patch(Circle((0.5, 0.5), 0.3,
>                        ec=(1,0,0,0.1), fc="none"))
> 
> 
> Attached is a little test script and its output.
> It seems that the edgecolor always has an alpha value of the face color.
> I'm not sure if this behavior is intended, but I personally think this
> is a bug.

Jae-Joon,

I can't look at this specifically now, but I suspect it is a side effect 
of the way that alpha support has evolved, resulting in a confusing 
mess.  Some things are RGB, others are RGBA; alpha defaults get set in 
various places, and there is no clear way of keeping track of what is 
just a default and should be overridden, versus what has been set 
deliberately and should *not* be overridden. I dimly remember looking 
into it a few months ago, thinking that it could be cleaned up with some 
simple changes, but failing.  I really wish we could make some sweeps 
through the mpl code base and systematically clean up some of these 
messes.  I don't know how many there are, but certainly more than one. 
Dpi is another area of perennial confusion, for example.

Eric

I'm definitely not smarter than you, but I had looked at backend_cairo 
more recently :)  I've done the merge.

Cheers,
Mike

Ryan May wrote:
> Checked in on the branch.  I'm seeing some merge conflicts on
> backend_cairo.py at the moment, so I'll let someone smarter than me merge to
> trunk. :)
>
> Good find.
>
> Ryan
>
> On Mon, Mar 23, 2009 at 1:01 PM, Sandro Tosi <mo...@de...> wrote:
>
>   
>> Hi all,
>> I found a really nice typo:
>>
>>     
>> $ svn diff
>> Index: doc/users/screenshots.rst
>> ===================================================================
>> --- doc/users/screenshots.rst   (revision 7000)
>> +++ doc/users/screenshots.rst   (working copy)
>> @@ -82,7 +82,7 @@
>>  ==========
>>
>>  The :func:`~matplotlib.pyplot.pie` command
>> -uses a matlab(TM) compatible syntax to produce py charts.  Optional
>> +uses a matlab(TM) compatible syntax to produce pie charts.  Optional
>>  features include auto-labeling the percentage of area, exploding one
>>  or more wedges out from the center of the pie, and a shadow effect.
>>  Take a close look at the attached code that produced this figure; nine
>> <<<
>>
>> Indeed pronunciation is the same, but the result is quite funny :)
>>
>> Cheers,
>> --
>> Sandro Tosi (aka morph, morpheus, matrixhasu)
>> My website: http://matrixhasu.altervista.org/
>> Me at Debian: http://wiki.debian.org/SandroTosi
>>
>>
>> ------------------------------------------------------------------------------
>> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
>> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
>> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
>> software that enables intelligent coding and step-through debugging.
>> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>     
>
>
>
>   
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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,

When drawing a patch, the alpha value of its edgeolor is ignored. The
following command draw a circle whose edgecolor has alpha=1, instead
of 0.1.


gca().add_patch(Circle((0.5, 0.5), 0.3,
                       ec=(1,0,0,0.1), fc="none"))


Attached is a little test script and its output.
It seems that the edgecolor always has an alpha value of the face color.
I'm not sure if this behavior is intended, but I personally think this
is a bug.

Regards,

-JJ

Checked in on the branch.  I'm seeing some merge conflicts on
backend_cairo.py at the moment, so I'll let someone smarter than me merge to
trunk. :)

Good find.

Ryan

On Mon, Mar 23, 2009 at 1:01 PM, Sandro Tosi <mo...@de...> wrote:

> Hi all,
> I found a really nice typo:
>
> >>>
> $ svn diff
> Index: doc/users/screenshots.rst
> ===================================================================
> --- doc/users/screenshots.rst   (revision 7000)
> +++ doc/users/screenshots.rst   (working copy)
> @@ -82,7 +82,7 @@
>  ==========
>
>  The :func:`~matplotlib.pyplot.pie` command
> -uses a matlab(TM) compatible syntax to produce py charts.  Optional
> +uses a matlab(TM) compatible syntax to produce pie charts.  Optional
>  features include auto-labeling the percentage of area, exploding one
>  or more wedges out from the center of the pie, and a shadow effect.
>  Take a close look at the attached code that produced this figure; nine
> <<<
>
> Indeed pronunciation is the same, but the result is quite funny :)
>
> Cheers,
> --
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
>
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>



-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from: Norman Oklahoma United States.

Hi all,
I found a really nice typo:

>>>
$ svn diff
Index: doc/users/screenshots.rst
===================================================================
--- doc/users/screenshots.rst	(revision 7000)
+++ doc/users/screenshots.rst	(working copy)
@@ -82,7 +82,7 @@
 ==========

 The :func:`~matplotlib.pyplot.pie` command
-uses a matlab(TM) compatible syntax to produce py charts.  Optional
+uses a matlab(TM) compatible syntax to produce pie charts.  Optional
 features include auto-labeling the percentage of area, exploding one
 or more wedges out from the center of the pie, and a shadow effect.
 Take a close look at the attached code that produced this figure; nine
<<<

Indeed pronunciation is the same, but the result is quite funny :)

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Hi Jae-Joon,

On Sun, Mar 22, 2009 at 8:55 PM, Jae-Joon Lee <lee...@gm...> wrote:
> Hi Eric,
>
> Have you find a solution for your problem?
> I recently encountered a similar problem.
> In my case, the images (I'm rasterizing the pcolormesh) are in wrong
> size if the output dpi is other than 72.
> And I guess this is related with the changes Jouni made in revision 6730.
>
> So, can you see if you have a correct output with dpi=72?
> If that's the case, can you try the attached patch and see if it
> solves your problem (should work with dpi other than 72).


I hadn't found a solution (other than rendering to svg), so thanks for
waking up this thread. I can confirm that I get the correct output
when I set dpi=72.


> I don't quite like my solution but it seems to work.
> It passes over the figure instance when initializing the
> MixedRenderer, and let the renderer change the dpi of the figure when
> changing the backend.
> I hope some other developer who better understands the dpi thing take
> a look and come up with a better solution.

I'll try to take a look at this later this afternoon. I agree that
someone with more knowledge should take a look. The SVG backend seems
to just ignore the dpi setting and forces 72 dpi across the board,
which is why I was able to use it as a workaround.

Thanks,
Eric

>
> Regards,
>
> -JJ
>
>
> On Thu, Feb 19, 2009 at 4:01 PM, Eric Bruning <eri...@gm...> wrote:
>> I just updated to the latest svn, and unveiled a bug that's evident
>> when using mixed-mode rendering in the PDF backend. I'm suspect I'm
>> the only one running my patch that enables set_rasterized on a
>> per-artist basis, so I'm the only one that's seeing it. :) Artists
>> that are left in vector mode are plotted correctly, while artists that
>> are rasterized are squished down toward the lower left corner of the
>> axes.
>>
>> Looking at the svn log, I suspect it's the changes to the path
>> simplification code (r6847) doing something funky at the transforms
>> level. Is that the right place to start looking? Any tips on how to
>> track this down?
>>
>> Thanks,
>> Eric
>>
>>
>> Sample code to reproduce the problem:
>>
>> import numpy
>> from matplotlib.pyplot import subplot, get_cmap, scatter, colorbar, show
>> basecolors = get_cmap('gist_yarg')
>> colormap, normer = basecolors, None #LogNorm()
>> x = y = c = numpy.arange(10) +1
>> dummy = scatter(x,y,c=c,cmap=colormap)#, norm=normer)
>> cbar = colorbar(dummy)#, spacing='proportional',ticks=isolevels.levels)
>> dummy.set_rasterized(True)
>> dummy.figure.savefig('raster_test.pdf')
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>> -Strategies to boost innovation and cut costs with open source participation
>> -Receive a $600 discount off the registration fee with the source code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>

Perhaps a merge failed on lib/matplotlib/mathtext.py?  If you know you 
don't have any local changes to that file that you need, you can just 
remove it and "svn up" again.  I can't see a reason why this is a 
repository-side problem... no properties have changed on that file for a 
long time.

Mike

Nils Wagner wrote:
> Hi all,
>
> I cannot install matplotlib from recent svn.
>
> python setup.py install --prefix=$HOME/local
> ============================================================================
> BUILDING MATPLOTLIB
>              matplotlib: 0.98.6svn
>                  python: 2.5.1 (r251:54863, Dec 21 2007, 
> 09:21:07)  [GCC
>                          3.4.6 20060404 (Red Hat 3.4.6-3)]
>                platform: linux2
>
> REQUIRED DEPENDENCIES
>                   numpy: 1.4.0.dev6708
>               freetype2: 9.7.3
>
> OPTIONAL BACKEND DEPENDENCIES
>                  libpng: 1.2.7
>                 Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
>                wxPython: 2.8.9.1
>                          * WxAgg extension not required 
> for wxPython >= 2.8
>                    Gtk+: no
>                          * Building for Gtk+ requires 
> pygtk; you must be able
>                          * to "import gtk" in your 
> build/install environment
>         Mac OS X native: no
>                      Qt: no
>                     Qt4: no
>                   Cairo: no
>
> OPTIONAL DATE/TIMEZONE DEPENDENCIES
>                datetime: present, version unknown
>                dateutil: matplotlib will provide
>                    pytz: 2008c
>
> OPTIONAL USETEX DEPENDENCIES
>                  dvipng: no
>             ghostscript: 7.07
>                   latex: 3.14159
>                 pdftops: 3.00
>
> [Edit setup.cfg to suppress the above messages]
> ============================================================================
> pymods ['pylab']
> packages ['matplotlib', 'matplotlib.backends', 
> 'matplotlib.projections', 'mpl_toolkits', 
> 'matplotlib.sphinxext', 'matplotlib.numerix', 
> 'matplotlib.numerix.mlab', 'matplotlib.numerix.ma', 
> 'matplotlib.numerix.linear_algebra', 
> 'matplotlib.numerix.random_array', 
> 'matplotlib.numerix.fft', 'matplotlib.delaunay', 
> 'dateutil', 'dateutil/zoneinfo']
> running install
> running build
> running build_py
> creating build
> creating build/lib.linux-x86_64-2.5
> copying lib/pylab.py -> build/lib.linux-x86_64-2.5
> creating build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/hatch.py -> 
> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/widgets.py -> 
> build/lib.linux-x86_64-2.5/matplotlib
> error: can't copy 'lib/matplotlib/mathtext.py': doesn't 
> exist or not a regular file
>   
> Nils
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> 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 all,

I cannot install matplotlib from recent svn.

python setup.py install --prefix=$HOME/local
============================================================================
BUILDING MATPLOTLIB
             matplotlib: 0.98.6svn
                 python: 2.5.1 (r251:54863, Dec 21 2007, 
09:21:07)  [GCC
                         3.4.6 20060404 (Red Hat 3.4.6-3)]
               platform: linux2

REQUIRED DEPENDENCIES
                  numpy: 1.4.0.dev6708
              freetype2: 9.7.3

OPTIONAL BACKEND DEPENDENCIES
                 libpng: 1.2.7
                Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
               wxPython: 2.8.9.1
                         * WxAgg extension not required 
for wxPython >= 2.8
                   Gtk+: no
                         * Building for Gtk+ requires 
pygtk; you must be able
                         * to "import gtk" in your 
build/install environment
        Mac OS X native: no
                     Qt: no
                    Qt4: no
                  Cairo: no

OPTIONAL DATE/TIMEZONE DEPENDENCIES
               datetime: present, version unknown
               dateutil: matplotlib will provide
                   pytz: 2008c

OPTIONAL USETEX DEPENDENCIES
                 dvipng: no
            ghostscript: 7.07
                  latex: 3.14159
                pdftops: 3.00

[Edit setup.cfg to suppress the above messages]
============================================================================
pymods ['pylab']
packages ['matplotlib', 'matplotlib.backends', 
'matplotlib.projections', 'mpl_toolkits', 
'matplotlib.sphinxext', 'matplotlib.numerix', 
'matplotlib.numerix.mlab', 'matplotlib.numerix.ma', 
'matplotlib.numerix.linear_algebra', 
'matplotlib.numerix.random_array', 
'matplotlib.numerix.fft', 'matplotlib.delaunay', 
'dateutil', 'dateutil/zoneinfo']
running install
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.5
copying lib/pylab.py -> build/lib.linux-x86_64-2.5
creating build/lib.linux-x86_64-2.5/matplotlib
copying lib/matplotlib/hatch.py -> 
build/lib.linux-x86_64-2.5/matplotlib
copying lib/matplotlib/widgets.py -> 
build/lib.linux-x86_64-2.5/matplotlib
error: can't copy 'lib/matplotlib/mathtext.py': doesn't 
exist or not a regular file
  
Nils

Hi Eric,

Have you find a solution for your problem?
I recently encountered a similar problem.
In my case, the images (I'm rasterizing the pcolormesh) are in wrong
size if the output dpi is other than 72.
And I guess this is related with the changes Jouni made in revision 6730.

So, can you see if you have a correct output with dpi=72?
If that's the case, can you try the attached patch and see if it
solves your problem (should work with dpi other than 72).

I don't quite like my solution but it seems to work.
It passes over the figure instance when initializing the
MixedRenderer, and let the renderer change the dpi of the figure when
changing the backend.
I hope some other developer who better understands the dpi thing take
a look and come up with a better solution.

Regards,

-JJ


On Thu, Feb 19, 2009 at 4:01 PM, Eric Bruning <eri...@gm...> wrote:
> I just updated to the latest svn, and unveiled a bug that's evident
> when using mixed-mode rendering in the PDF backend. I'm suspect I'm
> the only one running my patch that enables set_rasterized on a
> per-artist basis, so I'm the only one that's seeing it. :) Artists
> that are left in vector mode are plotted correctly, while artists that
> are rasterized are squished down toward the lower left corner of the
> axes.
>
> Looking at the svn log, I suspect it's the changes to the path
> simplification code (r6847) doing something funky at the transforms
> level. Is that the right place to start looking? Any tips on how to
> track this down?
>
> Thanks,
> Eric
>
>
> Sample code to reproduce the problem:
>
> import numpy
> from matplotlib.pyplot import subplot, get_cmap, scatter, colorbar, show
> basecolors = get_cmap('gist_yarg')
> colormap, normer = basecolors, None #LogNorm()
> x = y = c = numpy.arange(10) +1
> dummy = scatter(x,y,c=c,cmap=colormap)#, norm=normer)
> cbar = colorbar(dummy)#, spacing='proportional',ticks=isolevels.levels)
> dummy.set_rasterized(True)
> dummy.figure.savefig('raster_test.pdf')
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>