matplotlib-devel Mailing List for matplotlib (Page 8)

John Hunter wrote:
> Since we already have a bug in the 98.4 release, we can anticipate 
> needing to do a bugfix release accumulating all the bugs we fix in the 
> next week (presuming we don't discover any critical bugs which would 
> require us to push out a fix earlier).  To make sure we achieve 
> maximal stability, I have created a 98.4 maintenance branch which 
> should only get bugfixes.  All other development can proceed apace on 
> the trunk.
>
>    svn co 
> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/\ 
> <https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/%5C>
>    v0_98_4_maint mpl98.4 --username=youruser --password=yourpass
>
> Mike, can you advise on the procedure for doing merges from the new 
> branch to the trunk.  In particular, what I am confused about is how 
> to inform svn-merge that I want to merge from 98.4 branch and not 91.4 
> branch.
You can add a new branch for the trunk to "track" using "svnmerge.py 
init", e.g., from a working copy of the trunk:

  > svnmerge.py init 
https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v0_98_4_maint 

  property 'svnmerge-integrated' set on '.'

After doing a "svn commit" on this, this merge tracking is available to 
everyone, so there's no need for anyone else to do the "svnmerge init".  
I'll go ahead and commit this now.

Now, the trunk is tracking two branches for merges, 0.91.x and 0.98.4.  
This means that when doing a merge, one must manually specify which 
branch to merge from using the "-S" parameter.  You can see which 
branches are available for merge using "svnmerge.py avail":

 > svnmerge.py avail
svnmerge: multiple sources found. Explicit source argument (-S/--source) 
required.
The merge sources available are:
  /branches/v0_91_maint
  /branches/v0_98_4_maint

So to merge from 0.98.4, one would type:

 > svnmerge.py --source v0_98_4_maint merge

(rather than the "svnmerge.py merge" we used to do).

The tracking for 0.91.x can be removed with the "svnmerge.py uninit" 
command, e.g.:

 > svnmerge.py --source v0_91_maint uninit

This will make merging slightly easier, (since the -S parameter is not 
required), and it is generally good practice in the long run to not keep 
extra branches lying around.  I'm happy to make this change, but thought 
I'd run it by you first -- it means we're effectively abandoning the 
0.91.x series, or at least saying any bugfixes to it will have to be 
manually brought over to 0.98.x.


Mike

Hi,

I was going to try to start working on a TextCollection class (finally!), and I 
thought it might be good to discuss some of it here before I get too far along.

Motivations:
  *Speed up and simplify drawing of multiple text objects with common properties
	by reusing a single graphics context while drawing

  *Useful for doing plots using the text representation of values (think of a
	scatter plot with numbers instead of markers). This is my particular
	use case.

  *Useful for handling tick labels

Current thoughts:
  - TextCollection will draw multiple strings (at multiple locations) with a
	common FontProperties(), rotation, linespacing, and alignment.

  - TextCollection will inherit from Text so that all of the 
getting/setting of 			these common properties is gotten "for free".  What about 
all of the new
	Fancy bbox support of text? Do we handle this in text collection as well?

  - Should TextCollection also inherit from ScalarMappable so that we can colormap
	text values?  On one hand this sounds nice and would be similar to the
	other collections.  On the other, I can see this making for a difficult
	to understand plot.  My feeling is that if there's no technical reason
	not to add a feature, give the user the power (to shoot themselves in the
	foot).

  - Create a new Axes method `text_plot()` (anyone got a better name?) that works
	like scatter, based on TextCollection. Takes x,y, and data values, as
	well as optional colormapping array.  Also takes a string or function
	that controls formatting of text as well as (optional) x0,y0 scalar
	offsets (in points/pixels) that control where the text is placed in
	relation to the x,y location.  These offsets would, for instance, allow
	one to plot city names above the dot marking the location instead of on
	top of it.

Any thoughts?  I'm especially interested in any potential pitfalls (like 
inheriting from Text).

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

We have just released a new version of matplotlib, available for download at


https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194&release_id=646146

These "what's new" release notes, with graphs and links, are available in
html at

  http://matplotlib.sourceforge.net/users/whats_new.html

Thanks to Charlie Moad for testing and preparing the source release,
including binaries for OS X and Windows for python 2.4 and 2.5 (2.6
and 3.0 will not be available until numpy is available on those
releases).  Thanks to the many developers who contributed to this
release, with contributions from Jae-Joon Lee, Michael Droettboom,
Ryan May, Eric Firing, Manuel Metz, Jouni K. Seppaenen, Jeff Whitaker,
Darren Dale, David Kaplan, Michiel de Hoon and many others who
submitted patches


What new in 0.98.4
==============================

It's been four months since the last matplotlib release, and there are
a lot of new features and bug-fixes

Legend enhancements
--------------------

Jae-Joon has rewritten the legend class, and added support for
multiple columns and rows, as well as fancy box drawing.  See


http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.legend

http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.legend.Legend

http://matplotlib.sourceforge.net/examples/pylab_examples/legend_demo3.html


Fancy annotations and arrows
-----------------------------

Jae-Joon has added lot's of support to annotations for drawing fancy
boxes and connectors in annotations.  See



http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.annotate

http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.patches.BoxStyle

http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.patches.ArrowStyle

http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.patches.ConnectionStyle

http://matplotlib.sourceforge.net/examples/pylab_examples/annotation_demo2.html


Native OS X backend
--------------------

Michiel de Hoon has provided a native Mac OSX backend that is almost
completely implemented in C. The backend can therefore use Quartz
directly and, depending on the application, can be orders of magnitude
faster than the existing backends. In addition, no third-party
libraries are needed other than Python and NumPy. The backend is
interactive from the usual terminal application on Mac using regular
Python. It hasn't been tested with ipython yet, but in principle it
should to work there as well.  Set 'backend : macosx' in your
matplotlibrc file, or run your script with::

    > python myfile.py -dmacosx

psd amplitude scaling
-------------------------

Ryan May did a lot of work to rationalize the amplitude scaling of
:func:`~matplotlib.pyplot.psd` and friends.  The changes should
increase MATLAB (TM) compatabililty and increase scaling options.


http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.psd

http://matplotlib.sourceforge.net/examples/pylab_examples/psd_demo2.html#pylab-examples-psd-demo2

http://matplotlib.sourceforge.net/examples/pylab_examples/psd_demo3.html#pylab-examples-psd-demo3

Fill between
------------------

Added a fill_between function to make it easier to do shaded region
plots in the presence of masked data.  You can pass an *x* array and a
*ylower* and *yupper* array to fill betweem, and an optional *where*
argument which is a logical mask where you want to do the filling. See


http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.fill_between

http://matplotlib.sourceforge.net/examples/pylab_examples/fill_between.html


Lots more
-----------

Here are the 0.98.4 notes from the CHANGELOG::

    Added mdehoon's native macosx backend from sf patch 2179017 - JDH

    Removed the prints in the set_*style commands.  Return the list of
    pprinted strings instead - JDH

    Some of the changes Michael made to improve the output of the
    property tables in the rest docs broke of made difficult to use
    some of the interactive doc helpers, eg setp and getp.  Having all
    the rest markup in the ipython shell also confused the docstrings.
    I added a new rc param docstring.harcopy, to format the docstrings
    differently for hardcopy and other use.  Ther ArtistInspector
    could use a little refactoring now since there is duplication of
    effort between the rest out put and the non-rest output - JDH

    Updated spectral methods (psd, csd, etc.) to scale one-sided
    densities by a factor of 2 and, optionally, scale all densities by
    the sampling frequency.  This gives better MatLab
    compatibility. -RM

    Fixed alignment of ticks in colorbars. -MGD

    drop the deprecated "new" keyword of np.histogram() for numpy 1.2
    or later.  -JJL

    Fixed a bug in svg backend that new_figure_manager() ignores
    keywords arguments such as figsize, etc. -JJL

    Fixed a bug that the handlelength of the new legend class set too
    short when numpoints=1 -JJL

    Added support for data with units (e.g. dates) to
    Axes.fill_between. -RM

    Added fancybox keyword to legend. Also applied some changes for
    better look, including baseline adjustment of the multiline texts
    so that it is center aligned. -JJL

    The transmuter classes in the patches.py are reorganized as
    subclasses of the Style classes. A few more box and arrow styles
    are added. -JJL

    Fixed a bug in the new legend class that didn't allowed a tuple of
    coordinate vlaues as loc. -JJL

    Improve checks for external dependencies, using subprocess
    (instead of deprecated popen*) and distutils (for version
    checking) - DSD

    Reimplementaion of the legend which supports baseline alignement,
    multi-column, and expand mode. - JJL

    Fixed histogram autoscaling bug when bins or range are given
    explicitly (fixes Debian bug 503148) - MM

    Added rcParam axes.unicode_minus which allows plain hypen for
    minus when False - JDH

    Added scatterpoints support in Legend. patch by Erik Tollerud -
    JJL

    Fix crash in log ticking. - MGD

    Added static helper method BrokenHBarCollection.span_where and
    Axes/pyplot method fill_between.  See
    examples/pylab/fill_between.py - JDH

    Add x_isdata and y_isdata attributes to Artist instances, and use
    them to determine whether either or both coordinates are used when
    updating dataLim.  This is used to fix autoscaling problems that
    had been triggered by axhline, axhspan, axvline, axvspan. - EF

    Update the psd(), csd(), cohere(), and specgram() methods of Axes
    and the csd() cohere(), and specgram() functions in mlab to be in
    sync with the changes to psd().  In fact, under the hood, these
    all call the same core to do computations. - RM

    Add 'pad_to' and 'sides' parameters to mlab.psd() to allow
    controlling of zero padding and returning of negative frequency
    components, respecitively.  These are added in a way that does not
    change the API. - RM

    Fix handling of c kwarg by scatter; generalize is_string_like to
    accept numpy and numpy.ma string array scalars. - RM and EF

    Fix a possible EINTR problem in dviread, which might help when
    saving pdf files from the qt backend. - JKS

    Fix bug with zoom to rectangle and twin axes - MGD

    Added Jae Joon's fancy arrow, box and annotation enhancements --
    see examples/pylab_examples/annotation_demo2.py

    Autoscaling is now supported with shared axes - EF

    Fixed exception in dviread that happened with Minion - JKS

    set_xlim, ylim now return a copy of the viewlim array to avoid
    modify inplace surprises

    Added image thumbnail generating function
    matplotlib.image.thumbnail.  See examples/misc/image_thumbnail.py
    - JDH

    Applied scatleg patch based on ideas and work by Erik Tollerud and
    Jae-Joon Lee. - MM

    Fixed bug in pdf backend: if you pass a file object for output
    instead of a filename, e.g. in a wep app, we now flush the object
    at the end. - JKS

    Add path simplification support to paths with gaps. - EF

    Fix problem with AFM files that don't specify the font's full name
    or family name. - JKS

    Added 'scilimits' kwarg to Axes.ticklabel_format() method, for
    easy access to the set_powerlimits method of the major
    ScalarFormatter. - EF

    Experimental new kwarg borderpad to replace pad in legend, based
    on suggestion by Jae-Joon Lee.  - EF

    Allow spy to ignore zero values in sparse arrays, based on patch
    by Tony Yu.  Also fixed plot to handle empty data arrays, and
    fixed handling of markers in figlegend. - EF

    Introduce drawstyles for lines. Transparently split linestyles
    like 'steps--' into drawstyle 'steps' and linestyle '--'.  Legends
    always use drawstyle 'default'. - MM

    Fixed quiver and quiverkey bugs (failure to scale properly when
    resizing) and added additional methods for determining the arrow
    angles - EF

    Fix polar interpolation to handle negative values of theta - MGD

    Reorganized cbook and mlab methods related to numerical
    calculations that have little to do with the goals of those two
    modules into a separate module numerical_methods.py Also, added
    ability to select points and stop point selection with keyboard in
    ginput and manual contour labeling code.  Finally, fixed contour
    labeling bug. - DMK

    Fix backtick in Postscript output. - MGD

    [ 2089958 ] Path simplification for vector output backends
    Leverage the simplification code exposed through path_to_polygons
    to simplify certain well-behaved paths in the vector backends
    (PDF, PS and SVG).  "path.simplify" must be set to True in
    matplotlibrc for this to work.  - MGD

    Add "filled" kwarg to Path.intersects_path and
    Path.intersects_bbox. - MGD

    Changed full arrows slightly to avoid an xpdf rendering problem
    reported by Friedrich Hagedorn. - JKS

    Fix conversion of quadratic to cubic Bezier curves in PDF and PS
    backends. Patch by Jae-Joon Lee. - JKS

    Added 5-point star marker to plot command q- EF

    Fix hatching in PS backend - MGD

    Fix log with base 2 - MGD

    Added support for bilinear interpolation in
    NonUniformImage; patch by Gregory Lielens. - EF

    Added support for multiple histograms with data of
    different length - MM

    Fix step plots with log scale - MGD

    Fix masked arrays with markers in non-Agg backends - MGD

    Fix clip_on kwarg so it actually works correctly - MGD

    Fix locale problems in SVG backend - MGD

    fix quiver so masked values are not plotted - JSW

    improve interactive pan/zoom in qt4 backend on windows - DSD

    Fix more bugs in NaN/inf handling.  In particular, path
    simplification (which does not handle NaNs or infs) will be turned
    off automatically when infs or NaNs are present.  Also masked
    arrays are now converted to arrays with NaNs for consistent
    handling of masks and NaNs - MGD and EF

Since we already have a bug in the 98.4 release, we can anticipate needing
to do a bugfix release accumulating all the bugs we fix in the next week
(presuming we don't discover any critical bugs which would require us to
push out a fix earlier).  To make sure we achieve maximal stability, I have
created a 98.4 maintenance branch which should only get bugfixes.  All other
development can proceed apace on the trunk.

   svn co
https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/\
   v0_98_4_maint mpl98.4 --username=youruser --password=yourpass

Mike, can you advise on the procedure for doing merges from the new branch
to the trunk.  In particular, what I am confused about is how to inform
svn-merge that I want to merge from 98.4 branch and not 91.4 branch.

JDH

On Wed, Dec 10, 2008 at 12:36 AM, Jae-Joon Lee <lee...@gm...> wrote:

> Current SVN (r6540) raise an error for the following code.



Arg, bad timing.  Charlie released 0.98.4 hours before you found this.
Fortunately, the use case,

    fig = plt.figure()
    ax = maxes.Subplot(fig, 1, 1, 1)
    fig.add_subplot(ax)

is pretty rare, since most use the fig.add_subplot(111) construction.    In
fact, we didn't catch this because none of the examples use it in
backend_driver.

I just added a units/notes_tests.py with this example added to it.  Please
add other regression tests here as you develop.

JDH

Current SVN (r6540) raise an error for the following code.


import matplotlib.pyplot as plt
import matplotlib.axes as maxes

fig = plt.figure()
ax = maxes.Subplot(fig, 1, 1, 1)
fig.add_subplot(ax)



/Users/jjlee/.virtualenvs/default/lib/python2.5/site-packages/matplotlib/figure.pyc
in add_subplot(self, *args, **kwargs)
    687                 self._axstack.remove(ax)
    688
--> 689         a = subplot_class_factory(projection_class)(self,
*args, **kwargs)
    690         self.axes.append(a)
    691         self._axstack.push(a)

UnboundLocalError: local variable 'projection_class' referenced before
assignment


It seems that some of the code Mike recently introduced in "figure.py"
have incorrect indentation, but I'm not 100% sure.
I'm attaching a patch which seems to work for me, and It would be
great if Mike or others review it and apply.

-JJ

On Mon, Dec 8, 2008 at 5:31 PM, John Hunter <jd...@gm...> wrote:
> On Thu, Dec 4, 2008 at 12:38 PM, Charlie Moad <cw...@gm...> wrote:
>> Works for me.  Let's aim for Saturday night so we have Sunday to test
>> it out.  Doable?
>
> I've been working on a number of docstring fixes, and several other
> changes and last-minute bug fixes have been coming in.  I think we
> need to give these a day to settle, so let's hold off until tomorrow
> before trying to push out the release, so we can do further testing/

As far as I am concerned, the current head is tested and ready to go.
I am at svn r6535 so Charlie, go with that revision number when you do
the release, unless you hear otherwise here.  If someone has any other
fixes that need to go in before he does the release, we will need to
do a new round of testing.

JDH

On Thu, Dec 4, 2008 at 12:38 PM, Charlie Moad <cw...@gm...> wrote:
> Works for me.  Let's aim for Saturday night so we have Sunday to test
> it out.  Doable?

I've been working on a number of docstring fixes, and several other
changes and last-minute bug fixes have been coming in.  I think we
need to give these a day to settle, so let's hold off until tomorrow
before trying to push out the release, so we can do further testing/

Thanks,
JDH

On Mon, Dec 8, 2008 at 4:19 PM, Ryan May <rm...@gm...> wrote:
> Hi,
>
> Was just looking through the examples and noticed that pylab_examples/dashtick.py
> does not work here for me on SVN head.
>
> Traceback (most recent call last):
>   File "dashtick.py", line 61, in <module>
>     test_dashticklabel()
>   File "dashtick.py", line 40, in test_dashticklabel
>     fontsize=FONTSIZE,
>   File "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/pyplot.py",
> line 162, in setp
>     ret = _setp(*args, **kwargs)
>   File "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/artist.py",
> line 982, in setp
>     func = getattr(o,funcName)
> AttributeError: 'Text' object has no attribute 'set_dashrotation'
>
> I'm clueless on this code, so this is just an FYI.

TextWithDash is still used on the maintenance branch for tick labels,
but no longer on the trunk.  I suspect it did not work with the
arbitrary projections Michael developed support for and he removed it,
but Michael can confirm.  The code is poorly maintained, so I am happy
to see it no longer in the core tick labeling.  I have removed the
example from svn.

On Mon, Dec 8, 2008 at 4:29 PM, Ryan May <rm...@gm...> wrote:
> Hi,
>
> It looks like some tabs have crept into the CHANGELOG file.  Is anyone opposed to
> me changing them to the equivalent (8) spaces?  It messes up my editor, which is
> set to display them as 4 spaces, and makes it think that tabs are the proper way
> to indent.
>
> Ryan
>

I'm afraid that most of those tabs (if not all) are inserted by me.
I somehow presumed my editor (emacs with change-log-mode)
automatically convert tabs to equivalent number of spaces.
And, yes, go ahead.

-JJ

Hi,

Was just looking through the examples and noticed that pylab_examples/dashtick.py 
does not work here for me on SVN head.

Traceback (most recent call last):
   File "dashtick.py", line 61, in <module>
     test_dashticklabel()
   File "dashtick.py", line 40, in test_dashticklabel
     fontsize=FONTSIZE,
   File "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/pyplot.py", 
line 162, in setp
     ret = _setp(*args, **kwargs)
   File "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/artist.py", 
line 982, in setp
     func = getattr(o,funcName)
AttributeError: 'Text' object has no attribute 'set_dashrotation'

I'm clueless on this code, so this is just an FYI.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Ryan May wrote:
> Hi,
> 
> It looks like some tabs have crept into the CHANGELOG file.  Is anyone opposed to 
> me changing them to the equivalent (8) spaces?  It messes up my editor, which is 
> set to display them as 4 spaces, and makes it think that tabs are the proper way 
> to indent.
> 
> Ryan
> 

By all means, tabs are bugs, kill them dead!

Eric

Hi,

It looks like some tabs have crept into the CHANGELOG file.  Is anyone opposed to 
me changing them to the equivalent (8) spaces?  It messes up my editor, which is 
set to display them as 4 spaces, and makes it think that tabs are the proper way 
to indent.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Mon, Dec 8, 2008 at 12:30 PM, John Hunter <jd...@gm...> wrote:
> On Mon, Dec 8, 2008 at 10:49 AM, Jae-Joon Lee <lee...@gm...> wrote:
>
>> On the other hand, I think it would also good if we allow a dictionary
>> for the "fancybox" argument, like "bbox" in text. But maybe not in
>> this release.
>
> I would prefer not to change the meaning of the fancybox once we
> release it, if we can help it.  The best two choices are:
>
>  * add support now for the dict before the release (handling the rc
> to accept a dict may require a little extra work)
>
>  * keeping fancybox as is but adding an optional fancyprops dict later
>
> I can go either way, but I am disinclined to intentionally change the
> semantics of fancybox once we have released it we can help it
>

I see your point.
Let's keep it simple and leave it as is.
I guess there might not be much need of customization as most of users
will be happy with the default behavior.

Regards,

-JJ

On Mon, Dec 8, 2008 at 10:49 AM, Jae-Joon Lee <lee...@gm...> wrote:

> On the other hand, I think it would also good if we allow a dictionary
> for the "fancybox" argument, like "bbox" in text. But maybe not in
> this release.

I would prefer not to change the meaning of the fancybox once we
release it, if we can help it.  The best two choices are:

  * add support now for the dict before the release (handling the rc
to accept a dict may require a little extra work)

  * keeping fancybox as is but adding an optional fancyprops dict later

I can go either way, but I am disinclined to intentionally change the
semantics of fancybox once we have released it we can help it

On Mon, Dec 8, 2008 at 10:27 AM, John Hunter <jd...@gm...> wrote:
>
> I'm inclined to agree with you -- this could also be an rc option, so
> those who like the rounding can get them by default.  I would be happy
> to have rectangle by default, with liberal use of rounding in the
> gallery example code so people can easily  find how to turn them on.
> A legend section for the docs is still on my list of things to do.
> I'll implement the rc param "legend.fancybox" and make False
> (rectangle) the default, and we can always change the after default if
> JJ weighs in.
>

legend.fancybox=False as the default is good.

Just in case, the legend class still creates FancyBboxPatch(but with a
rectangle style) even if fancybox=False. But, I presume that the
auto-pixel-alignment works in this case.

On the other hand, I think it would also good if we allow a dictionary
for the "fancybox" argument, like "bbox" in text. But maybe not in
this release.

Regards,

-JJ

John Hunter wrote:
> On Mon, Dec 8, 2008 at 9:39 AM, Michael Droettboom <md...@st...> wrote:
>
>   
>> The gc param would be the easy part -- I was thinking the difficult would be
>> going through all the cases and making sure it's doing the right thing, and
>> making sure axes and ticks etc. still look nice.  Though I suppose having
>> the flag be yes/no/auto (where auto is the current behavior) would be the
>> easiest route.
>>     
>
> I wasn't thinking clearly.  I was thinking you would be applying the
> fix only for the legend implementation, but there is no clean way to
> do this since the backends don't know anything about legends.  Yes,
> doing this for all the artists is definitely too ambitious at this
> stage of the release.
>   
I think this also dovetails nicely with another update I've been meaning 
to make -- to use a GC (or something like it) for images and collections 
as well.  As it stands now, any new property to collections needs to be 
added as a new argument to every backend (as was recently done for 
hyperlink support).  Stuffing everything in an object should make it 
more easily extensible.

But that's not before the release... ;)

Mike

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

This should now be fixed in SVN.  Couldn't see any regressions in the 
documentation examples, but may be worth another set of eyes before the 
release.

Mike

John Hunter wrote:
> On Mon, Dec 8, 2008 at 8:16 AM, Michael Droettboom <md...@st...> wrote:
>   
>> I don't think it's a rendering bug.  The entire first row of data is 0.0 and
>> -0.0, which maps to red.  The real solution would be to map 0 and -0.0 to
>> different colors, but that's insane ;)
>>
>> The rendering bug that bothers me, however, is the misalignment of the ticks
>> to the colors in the color bar.  I'm sure it's somehow related to the
>> pixel-rounding in the Agg backend.  I'll see if I can find an obvious fix
>> for this.  If it looks questionable, I'll wait until after the release.
>>     
>
> Since this would be a bug-fix, I prefer to get it in before the
> release, if possible:-)  So if you have time to look at it, that would
> be great.  Charlie doesn't usually have time during the day to do the
> builds, so it would be tonight at the earliest, which should give us a
> little time to test any changes.
>
> Thanks,
> JDH
>   

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

On Mon, Dec 8, 2008 at 9:39 AM, Michael Droettboom <md...@st...> wrote:

> The gc param would be the easy part -- I was thinking the difficult would be
> going through all the cases and making sure it's doing the right thing, and
> making sure axes and ticks etc. still look nice.  Though I suppose having
> the flag be yes/no/auto (where auto is the current behavior) would be the
> easiest route.

I wasn't thinking clearly.  I was thinking you would be applying the
fix only for the legend implementation, but there is no clean way to
do this since the backends don't know anything about legends.  Yes,
doing this for all the artists is definitely too ambitious at this
stage of the release.

JDH

John Hunter wrote:
> On Mon, Dec 8, 2008 at 9:13 AM, Michael Droettboom <md...@st...> wrote:
>   
>> This may also be an argument for finally making the auto-pixel-alignment
>> code programmatic, rather than automatic.  As it works now, it
>> automatically pixel-aligns when there are a) no curves and b) only
>> rectilinear axis-aligned line segments.  If the pixel alignment was
>> instead controlled from Python as a flag, then the legend code could
>> explicitly say it wants the legend patch to be pixel-aligned, even if it
>> has rounded corners.  But that's perhaps too deep of a change to make
>> for the impending release and should have to wait for next time.
>>     
>
> This sounds fairly benign (gc param?) so I could go either way: before or after.
>   
The gc param would be the easy part -- I was thinking the difficult 
would be going through all the cases and making sure it's doing the 
right thing, and making sure axes and ticks etc. still look nice.  
Though I suppose having the flag be yes/no/auto (where auto is the 
current behavior) would be the easiest route.

Mike

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

On Mon, Dec 8, 2008 at 9:13 AM, Michael Droettboom <md...@st...> wrote:
> I think Jae-Joon's new figure refactoring is really great, and is a huge
> improvement over the old code.
>
> I do, however, have one concern.  Since the legend border is no longer a
> simple rectangle, the Agg backend's auto-pixel-alignment routine is no
> longer kicking in, and the border ends up looking fairly fuzzy.  It's
> particularly striking when the axes rectangle is always so clean and
> sharp now.  As nice as the rounded edges are, the fuzziness makes it
> feel like a bit of a regression to me.  Aesthetically, I also feel it's
> a bit out of place to use rounded corners in one case but not elsewhere
> in a document (typical LaTeX templates, for instance, don't use rounded
> corners.)
>
> Should it perhaps be a regular rectangle by default, with rounded
> corners as an option?

I'm inclined to agree with you -- this could also be an rc option, so
those who like the rounding can get them by default.  I would be happy
to have rectangle by default, with liberal use of rounding in the
gallery example code so people can easily  find how to turn them on.
A legend section for the docs is still on my list of things to do.
I'll implement the rc param "legend.fancybox" and make False
(rectangle) the default, and we can always change the after default if
JJ weighs in.

> This may also be an argument for finally making the auto-pixel-alignment
> code programmatic, rather than automatic.  As it works now, it
> automatically pixel-aligns when there are a) no curves and b) only
> rectilinear axis-aligned line segments.  If the pixel alignment was
> instead controlled from Python as a flag, then the legend code could
> explicitly say it wants the legend patch to be pixel-aligned, even if it
> has rounded corners.  But that's perhaps too deep of a change to make
> for the impending release and should have to wait for next time.

This sounds fairly benign (gc param?) so I could go either way: before or after.

JDH

I think Jae-Joon's new figure refactoring is really great, and is a huge 
improvement over the old code.

I do, however, have one concern.  Since the legend border is no longer a 
simple rectangle, the Agg backend's auto-pixel-alignment routine is no 
longer kicking in, and the border ends up looking fairly fuzzy.  It's 
particularly striking when the axes rectangle is always so clean and 
sharp now.  As nice as the rounded edges are, the fuzziness makes it 
feel like a bit of a regression to me.  Aesthetically, I also feel it's 
a bit out of place to use rounded corners in one case but not elsewhere 
in a document (typical LaTeX templates, for instance, don't use rounded 
corners.)

Should it perhaps be a regular rectangle by default, with rounded 
corners as an option?

This may also be an argument for finally making the auto-pixel-alignment 
code programmatic, rather than automatic.  As it works now, it 
automatically pixel-aligns when there are a) no curves and b) only 
rectilinear axis-aligned line segments.  If the pixel alignment was 
instead controlled from Python as a flag, then the legend code could 
explicitly say it wants the legend patch to be pixel-aligned, even if it 
has rounded corners.  But that's perhaps too deep of a change to make 
for the impending release and should have to wait for next time.

Mike

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

On Mon, Dec 8, 2008 at 8:16 AM, Michael Droettboom <md...@st...> wrote:
> I don't think it's a rendering bug.  The entire first row of data is 0.0 and
> -0.0, which maps to red.  The real solution would be to map 0 and -0.0 to
> different colors, but that's insane ;)
>
> The rendering bug that bothers me, however, is the misalignment of the ticks
> to the colors in the color bar.  I'm sure it's somehow related to the
> pixel-rounding in the Agg backend.  I'll see if I can find an obvious fix
> for this.  If it looks questionable, I'll wait until after the release.

Since this would be a bug-fix, I prefer to get it in before the
release, if possible:-)  So if you have time to look at it, that would
be great.  Charlie doesn't usually have time during the day to do the
builds, so it would be tonight at the earliest, which should give us a
little time to test any changes.

Thanks,
JDH

John Hunter <jd...@gm...> writes:

> I think the version check is a good idea, so people won't get the  
> annoying warning.  Could you add this?
> 
> Sent from my iPhone
> 
> On Dec 7, 2008, at 2:22 PM, "Jae-Joon Lee" <lee...@gm...> wrote:
> 
> > I'm currently using numpy 1.1.1 and np.histogram behave differently
> > depending on the "new" value.
> > ubuntu interpid and debian sid has numpy 1.1.1.1 and I presume that
> > this different behavior is still there.
> > So, as far as we're going to support numpy 1.1 and later, we may
> > better not to drop the "new" silently.

Debian lenny (which is currently in freeze and will be the next
stable) has numpy 1.1 at present. 

It is possible that the package maintainers will try to get a later
version in - but you should check before relying on it. 

Chris

I don't think it's a rendering bug.  The entire first row of data is 0.0 
and -0.0, which maps to red.  The real solution would be to map 0 and 
-0.0 to different colors, but that's insane ;)

The rendering bug that bothers me, however, is the misalignment of the 
ticks to the colors in the color bar.  I'm sure it's somehow related to 
the pixel-rounding in the Agg backend.  I'll see if I can find an 
obvious fix for this.  If it looks questionable, I'll wait until after 
the release.

Cheers,
Mike

John Hunter wrote:
> In the examples/pylab_examples/custom_cmap.py example, I am seeing a
> pixel red border, eg colored red on the top border of the middle
> subplot, where it looks like it should be blue.  Image attached.  Is
> this an artifact of the breakpoint of the colormap, or a true
> rendering bug?
>
> JDH
>   
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.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