matplotlib-devel Mailing List for matplotlib

On Thursday 25 May 2006 14:30, John Hunter wrote:
> >>>>> "Eric" == Eric Firing <ef...@ha...> writes:
>
>     Eric> I see only advantages and no disadvantages whatsoever to
>     Eric> this change; am I missing something?
>
> The only potential problem with this is that a linewidth=0 is
> postscript actually means something -- it tells the rendering device
> to draw the thinnest possible line.  The change you propose could
> potentially break some code where people are relying on this.  This
> would not be the end of the world as long as we announce it.

I would be surprised if anyone is relying on this behavior. I think I remember 
reading in a book on postscript that use of this feature is discouraged.

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
    Eric> I see only advantages and no disadvantages whatsoever to
    Eric> this change; am I missing something?

The only potential problem with this is that a linewidth=0 is
postscript actually means something -- it tells the rendering device
to draw the thinnest possible line.  The change you propose could
potentially break some code where people are relying on this.  This
would not be the end of the world as long as we announce it.

Alternatively, we could support 'None' for the facecolor and edgecolor.  This
is a little difficult, unfortunately, since None is overloaded to
mean "do the default".  The hack workaround we use here is to set
'None' (the string) rather than None itself.  Ugly, yes.  

The real root of the problem is that

        renderer.draw_polygon(gc, rgbFace, tverts)

is overloaded to support edge and face drawing in one function call.
This is a hold-over from the bad-old-days where pcolor and friends use
polygons for every face, and I wanted to save the function call by
putting both edge and face drawing in one call.

One might rather have at the Artist level

    if facecolor!='None': 
        gc.set_foreground(facecolor)
        renderer.draw_polygon(gc, tverts, fill=False)

    if edgecolor!='None'
        gc.set_foreground(edgecolor)
        renderer.draw_polygon(gc, tverts, fill=False)

or have booleans in the patch object if this is too ugly.

This is cleaner in my view than using linewidth=0 but I don't feel
strongly.  However, it would require changing *every* backend.  Argg

JDH

On Thursday 25 May 2006 14:07, Eric Firing wrote:
> Darren, John, et al.,
>
> At present it is impossible to render a patch with exactly the
> dimensions specified because a boundary is required.  Present
> workarounds include setting the boundary color to the face color and
> setting a small or zero linewidth.  This is inefficient--a line is being
> rendered when it is not wanted--and imprecise, because the result of a
> very thin or zero-width line depends on the backend and output device.

My understanding is that a zero-width line in postscript will be rendered as a 
line with thickness equal to the resolution of the device. So the behavior 
does vary across backends.

> I propose that the backends be changed so that for any patch-like object
> or collection, setting the boundary linewidth to zero suppresses
> rendering of the line.
>
> I see only advantages and no disadvantages whatsoever to this change; am
> I missing something?

I don't claim to be an authority, but I can't think of any problems this might 
raise. Probably it could be done in the ps backend by simply wrapping the 
stroke commands in a check for zero line width. 

> If the proposal meets approval, I can work on it, although I don't know
> which of the backends I can quickly understand well enough (and test) to
> do this. At least the ps backend looks easy with respect to this change.
> Of course, I would be delighted to see the backend maintainers take this
> on.
>
> Comments?  Alternative proposals?

Darren, John, et al.,

At present it is impossible to render a patch with exactly the 
dimensions specified because a boundary is required.  Present 
workarounds include setting the boundary color to the face color and 
setting a small or zero linewidth.  This is inefficient--a line is being 
rendered when it is not wanted--and imprecise, because the result of a 
very thin or zero-width line depends on the backend and output device.

I propose that the backends be changed so that for any patch-like object 
or collection, setting the boundary linewidth to zero suppresses 
rendering of the line.

I see only advantages and no disadvantages whatsoever to this change; am 
I missing something?

If the proposal meets approval, I can work on it, although I don't know 
which of the backends I can quickly understand well enough (and test) to 
do this. At least the ps backend looks easy with respect to this change. 
Of course, I would be delighted to see the backend maintainers take this on.

Comments?  Alternative proposals?

Eric

Helge,

I have committed some changes to the colorbar positioning code that I 
think fix the bug you found--which was actually a difference between the 
way positioning worked in interactive mode versus in a script--and 
generally improved it.  There is a new kwarg, 'pad', to control the 
spacing.  It is a fraction of the original parent axes.  Defaults are 
0.05 for vertical axes and 0.15 for horizontal; in the latter case, it 
has to leave room for axis tick labels and the x-axis title.  I think 
you will find the defaults tolerable.

The automatic repositioning is crude; it is suitable for interactive 
use, but for production plots people will often need to explicitly size 
and position the primary axes and the colorbar axes.  It can probably be 
improved with a few tweaks here and there, but to do a much better job 
automatically would require major changes, and I don't think this should 
be a high priority. On the other hand, it is possible that redesigning 
positioning and aspect-ratio handling to take full advantage of all the 
wizardry in the transforms code would be a big step forward--but 
probably not an easy one.  I am not going to try it right now.

Thanks again for the clear bug report.

Eric

Helge Avlesen wrote:
> Hi,
> just a small wish for the new colorbar;  I think it by default may be
> positioned a bit too close to the figure,
> see examples below. (plotted by this sequence with yesterdays svn checkout)