matplotlib-devel Mailing List for matplotlib (Page 502)

>Isn't this closely related to the idea we've tslked about a number of
>times (mostly off list) to supplant the colormap infrastructure with a
>"DiscreteColormap" or something along those lines, which mapped data
>to a set of discrete colors, using nearest neighbor or what have
>you.  Then you would have the best of both worlds: your favorite
>colors and consistency with the mpl colorbar/colormapping API.  Would
>this work?
>  
>
I don't quite understand the idea here, but the colorbar mapping is 
really only part of this.  If you make classes for each plot type, you 
could do things like make legend() a call to the PlotClass.Legend() 
method, and each plot could make it's own kind of legend.

I know this is a large architecture change, but it could be implimented 
incrimentally and I think it would give a lot of benefits in regards to 
what you could do with customizing different plot behaviours.  But, as I 
said before, I don't really have nearly the grasp of the matplotlib 
codebase that the devs do.  It doesn't look too difficult to me, but 
there are probably issues I am not aware of.  Is there any reason each 
plot type shouldn't have it's own class?

Jordan

>>>>> "Nicholas" == Nicholas Young <su...@su...> writes:

    Nicholas> Hi, I regularly use matplotlib on lots of systems I
    Nicholas> don't have root access to.  On most of these
    Nicholas> installation of gs 8.15 is quite problematic (and buggy)
    Nicholas> and as I result using TeX with matplotlib is
    Nicholas> impractical.  Additionally as all of the printers I have
    Nicholas> access to are HP made the use of embedded truetype fonts
    Nicholas> is also problematic.  The combination of these two
    Nicholas> problems has made it difficult to use mpl for anything I
    Nicholas> need to print and for which I need mathtext.

    Nicholas> As a solution I've patched the mathtext library and
    Nicholas> backend_ps in order to support mathtext based upon the
    Nicholas> standard postscript Symbol font when ps.usetex = True.
    Nicholas> A function patch to CVS is attached.

Thanks Nick -- just committed this to CVS so it will be in the next
release

Checking in lib/matplotlib/mathtext.py;
/cvsroot/matplotlib/matplotlib/lib/matplotlib/mathtext.py,v  <--
matht\
ext.py
new revision: 1.21; previous revision: 1.20
done
Checking in lib/matplotlib/backends/backend_ps.py;
/cvsroot/matplotlib/matplotlib/lib/matplotlib/backends/backend_ps.py,v
\
 <--  backend_ps.py
new revision: 1.69; previous revision: 1.68
done


JDH

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:

    Perry> Before you go off in this direction, could you outline how
    Perry> you think colormaps should work? From the sounds of it, you
    Perry> are addressing mostly cases where users have specifically
    Perry> picked colors and you would like colorbar() to work with
    Perry> the selected colors. Generally speaking, you seem to be

Isn't this closely related to the idea we've tslked about a number of
times (mostly off list) to supplant the colormap infrastructure with a
"DiscreteColormap" or something along those lines, which mapped data
to a set of discrete colors, using nearest neighbor or what have
you.  Then you would have the best of both worlds: your favorite
colors and consistency with the mpl colorbar/colormapping API.  Would
this work?

JDH

> Before you go off in this direction, could you outline how you think 
> colormaps should work? From the sounds of it, you are addressing 
> mostly cases where users have specifically picked colors and you would 
> like colorbar() to work with the selected colors. Generally speaking, 
> you seem to be concerned with discrete color sets. But colormaps were 
> primarily directed towards image display where a nearly continuous 
> range of levels might be encountered. So could you explain how you 
> would handle colormaps for images?

I think that there should essentially be 2 seperate systems, one for 
discrete color sets and one for colormaps.  I think colormaps work great 
for things like image data or continuous data where transitions between 
levels are less important than getting a general feeling of magnitude 
and structure.  Discrete contour levels are better for showing where a 
set of data exceeds threshold values.  So both should be useable, but 
currently the architecture is focused on using colormaps.

As it stands, colorbar() seems perfectly usable if you are working with 
colormaps--I'm not sure about this though, because I almost never use 
colormaps in my figures.  So I wouldn't change anything about colormaps 
for images: this is an extension of the functionality, not a modification.

Jordan

On Nov 1, 2005, at 1:34 PM, Jordan Dawe wrote:

> I have been hacking away at the colorbar( ) code because I wanted a 
> more flexible colorbar facility for my figures.  However, the current 
> figure/axes architechture presents a few problems for me.  My primary 
> problem is this: I never, ever, ever use the colormap facilities in 
> matplotlib; I specify the colors of each of my contour levels with rgb 
> tuples, because I have grown super-obsessed with graphics design and I 
> want exact control of the shades displayed.  Not using colormaps 
> creates the problem that colorbar() doesn't work, as there is no 
> colormap for it to plot.
>
> Colormaps are, in my opinion, a horrible hack and one of the worst 
> parts of Matlab.  In fact, one of the main reasons I have been using 
> matplotlib is because it's much easier to turn colormaps off.  But 
> this does present a problem for automated colorbars.
>
> The solution that I am inclined to pursue is to create a set of 
> 'plot-type' objects; ie, objects called "contour", "contourf", "bar", 
> "pie", "plot", etc, which all inherit from a parent class.  These 
> objects would contain information about the levels plotted, the colors 
> of the lines, links to the PolyCollections that are currently stored 
> by the axes, etc.  This would allow colorbar() to, say, automatically 
> grab the last contourf plotted, figure out the colors, space the color 
> divisions in proportion to the data levels, and so on.  I could see if 
> the axes have a contour plot as well as a contourf, and if the data 
> levels agreed, it could plot the contour levels onto the colorbar as 
> well.  It would also allow for more flexible legends, and it wouldn't 
> neccessitate the abandonment of matlab compatibility, since colorbar() 
> would still default to searching for a colormap first.
>
> But I haven't been looking at the matplotlib code for that long, so 
> I'm not sure this is actually a good idea.  Is there an obvious 
> problem with this idea?  Is it worth me trying to start hacking 
> something together?  Thanks.
>
> Jordan

Before you go off in this direction, could you outline how you think 
colormaps should work? From the sounds of it, you are addressing mostly 
cases where users have specifically picked colors and you would like 
colorbar() to work with the selected colors. Generally speaking, you 
seem to be concerned with discrete color sets. But colormaps were 
primarily directed towards image display where a nearly continuous 
range of levels might be encountered. So could you explain how you 
would handle colormaps for images?

Perry Greenfield

I have been hacking away at the colorbar( ) code because I wanted a more 
flexible colorbar facility for my figures.  However, the current 
figure/axes architechture presents a few problems for me.  My primary 
problem is this: I never, ever, ever use the colormap facilities in 
matplotlib; I specify the colors of each of my contour levels with rgb 
tuples, because I have grown super-obsessed with graphics design and I 
want exact control of the shades displayed.  Not using colormaps creates 
the problem that colorbar() doesn't work, as there is no colormap for it 
to plot.

Colormaps are, in my opinion, a horrible hack and one of the worst parts 
of Matlab.  In fact, one of the main reasons I have been using 
matplotlib is because it's much easier to turn colormaps off.  But this 
does present a problem for automated colorbars.

The solution that I am inclined to pursue is to create a set of 
'plot-type' objects; ie, objects called "contour", "contourf", "bar", 
"pie", "plot", etc, which all inherit from a parent class.  These 
objects would contain information about the levels plotted, the colors 
of the lines, links to the PolyCollections that are currently stored by 
the axes, etc.  This would allow colorbar() to, say, automatically grab 
the last contourf plotted, figure out the colors, space the color 
divisions in proportion to the data levels, and so on.  I could see if 
the axes have a contour plot as well as a contourf, and if the data 
levels agreed, it could plot the contour levels onto the colorbar as 
well.  It would also allow for more flexible legends, and it wouldn't 
neccessitate the abandonment of matlab compatibility, since colorbar() 
would still default to searching for a colormap first.

But I haven't been looking at the matplotlib code for that long, so I'm 
not sure this is actually a good idea.  Is there an obvious problem with 
this idea?  Is it worth me trying to start hacking something together?  
Thanks.

Jordan

>>>>> "Jordan" == Jordan Dawe <fre...@oc...> writes:


    Jordan> Sweet, will do.  I am using the CVS version currently; I
    Jordan> just submitted a patch to the sourceforge page to make it
    Jordan> easier for me to compile, since I am running under cygwin
    Jordan> most of the time.  I have a couple of other patches I
    Jordan> intend to submit when I have a spare moment; is the
    Jordan> sourceforge page the proper place to do that?

Yes -- just send a note here describing what is in them so we can be
sure to include them.  Bunch them together where possible to save
work.

Thanks,
JDH

>
> It looks like there is no problem with simply turning off the 
> chunking.  I have made a bunch of changes in CVS, including turning 
> off the chunking by default, and allowing one to specify chunking, 
> antialiasing, and linewidth explicitly for contourf.  So, I think you 
> will find that if you use the CVS version, the problems you reported 
> will go away.  If you haven't done it before, you will find that 
> downloading and installing from CVS is very quick and easy; 
> instructions are given on the sourceforge download site.  

Sweet, will do.  I am using the CVS version currently; I just submitted 
a patch to the sourceforge page to make it easier for me to compile, 
since I am running under cygwin most of the time.  I have a couple of 
other patches I intend to submit when I have a spare moment; is the 
sourceforge page the proper place to do that?

Jordan

Jordan,

I have looked into various aspects of the problem you reported.  It 
seems to be essentially a problem with antialiasing; all artifacts go 
away in the AGG backend with antialiasing turned off, regardless of the 
linewidth, right down to zero.  With antialiasing on, however, it seems 
that a linewidth of about 0.5 with AGG (on my machine, with everything 
default) is needed to prevent the antialiasing from leaving light lines 
at polygon boundaries, regardless of whether they are the straight 
boundaries caused by chunking or the curved boundaries of the contours 
themselves.  With Postscript, as rendered by ghostscript via gv, I see 
artifacts only with a much smaller linewidth, and only at some 
magnifications.  Your ps viewers may be doing more antialiasing, and 
therefore showing artifacts over a larger range of linewidths.  There is 
probably more going on, and more to be understood, but this got me far 
enough to manage the problem for now.

It looks like there is no problem with simply turning off the chunking. 
  I have made a bunch of changes in CVS, including turning off the 
chunking by default, and allowing one to specify chunking, antialiasing, 
and linewidth explicitly for contourf.  So, I think you will find that 
if you use the CVS version, the problems you reported will go away.  If 
you haven't done it before, you will find that downloading and 
installing from CVS is very quick and easy; instructions are given on 
the sourceforge download site.  (As John notes, there may be a lag 
between developer CVS and the mirrors; make sure that what you download 
includes my changes, committed a few minutes ago.)  Alternatively, if 
you simply want to turn off chunking in 0.84, you can do it by editing 
cntr.c, approximately line 1384, change

     long nchunk = 30; /* hardwired for now */
to
     long nchunk = 0; /* hardwired for now */

and recompile/reinstall.


If you use the CVS version (or the next mpl release, whenever that comes 
out), note that the APIs for contour, contourf, and clabel have changed 
as described in API_CHANGES and as illustrated in 
examples/contour_demo.py and contourf_demo.py.

Eric

Jordan Dawe wrote:
> Eric Firing wrote:
> 
>> Jordan,
>>
>> Thanks, now I see the problem and where it is coming from.  In 
>> contour.py, near the bottom, in the contourf method, change the 
>> linewidth from 1 to 0.01, so the line reads:
>>             col = PolyCollection(nlist, linewidths=(0.01,))
>>
>> I think this will be OK; based on the comment below the line, I think 
>> I found that using a linewidth of zero was problematic, so I probably 
>> simply used 1 thinking it was small enough not to matter.
>>
>> I will need to make a corresponding change in the CVS version so that 
>> it will get into the next release.  I'll do that this evening.
>>
> Sorry about this, but that patch doesn't seem to work.  When I open the 
> eps files generated with this change implimented, I get the artifact 
> problem mentioned in the comment; fine lines at the boundaries of the 
> contouring engine's subdomains.  In fact, I get the artifacts at 
> linewidths as large as 0.5.
> 
> Jordan

On Friday 28 October 2005 9:57 am, Darren Dale wrote:
> I was wondering, has anyone looked into extending numerix to handle the new
> scipy? All scipy tests now pass on my 32bit system, but there is some
> incompatibility between new scipy and mpl. For example:
>
> from pylab import *
> from scipy import *
> plot(linspace(-1,1,100))
> show()

For those who are not on the scipy-dev list, Travis just informed me that 
upgrading to Numeric 24 will solve the problem I reported. I was working with 
23.8, the new version seems to have solved my problem.

Darren

Jordan,

Evidently the reason we see different things is because the result with 
linewidth < 1 is renderer-dependent; ghostview (which I am using) and 
Illustrator handle the same file differently.

To be sure we are agreeing on the phenomenon: Initially, with 
linewidth=1 in the contourf polygon generation, there was no problem 
with the subregion boundaries, but the polygons were a bit too large, so 
that thin line contours did not land exactly on the boundaries.  Setting 
linewidth=0.01 fixes that problem, but introduces renderer-dependent 
artifacts at the subregion boundaries.

The real solution, or part of it, may be in the backend (ps at least, 
maybe others): I think that we want to be able to specify a polygon with 
a zero-width boundary, such that it is filled but not stroked. 
Alternatively, it may be that the problem is one of rounding in the 
conversion of floating point vertices to integers in the renderer, in 
which case removing the boundary line entirely won't help at all.

The division of the domain by cntr.c into subregions is controllable by 
a parameter; I can expose that parameter to the python level (this 
weekend, not this minute).  Then setting it to a sufficiently large 
value will take care of the grid problem; and maybe it will have no bad 
side-effects.  According to the comment in the contouring code, the 
reason for subdividing is that renderers bog down when filling polygons 
with too many vertices.  It may be that this is no longer a problem; 
that comment may date from an earlier era.

Eric

Jordan Dawe wrote:
> Yeah, I see artifacts in the eps file you sent me.  I'm looking at it in 
> Illustrator CS, and the artifacts show up in Adobe Acrobat 6.0 as well.  
> They also show up when I take the eps and do a 'convert example.eps 
> example.png' on it.  The resulting png is attached.
> 
> The artifacts tend to change when I zoom in, so I'm guessing some of it 
> is related to the renderer in Illustrator, but I'm still worried they 
> will show up when they go to press.  When the linewidth =1.0, the 
> artifacts don't show up at all, so I know it's possible to get rid of them.
> 
> I'm willing to hunt through and try to fix this problem, but where would 
> it show up?  In the PS render code?  In the polygon handers?  I know a 
> fair bit of python, but I don't know my way around matplotlib very well...
> 
> Also, do you see any problems with me trying to make the cntr.c code 
> output one polygon per simply-connected region?  Cause the current 
> "divide the fig up into 48 smaller areas" thing is annoying as hell when 
> you're working with eps.  Matlab's renderer does this, why can't this one?
> 
> Jordan
> 
> ------------------------------------------------------------------------
> 

I was wondering, has anyone looked into extending numerix to handle the new 
scipy? All scipy tests now pass on my 32bit system, but there is some 
incompatibility between new scipy and mpl. For example:

from pylab import *
from scipy import *
plot(linspace(-1,1,100))
show()


Darren

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> Jordan, Strange, I did test the change and it worked fine
    Eric> with your example on my system.  I will email you the result
    Eric> in a separate message so as not to clog the list.  Then you
    Eric> can tell me if you see the problem in that file.  Maybe I am
    Eric> misunderstanding something.

Could be a CVS version problem -- make sure you are both working on
the same CVS file(s) and the same test script. Historically,
non-developer CVS tends to lag...

JDH

Jordan,

Strange, I did test the change and it worked fine with your example on 
my system.  I will email you the result in a separate message so as not 
to clog the list.  Then you can tell me if you see the problem in that 
file.  Maybe I am misunderstanding something.

Eric



Jordan Dawe wrote:
> Eric Firing wrote:
> 
>> Jordan,
>>
>> Thanks, now I see the problem and where it is coming from.  In 
>> contour.py, near the bottom, in the contourf method, change the 
>> linewidth from 1 to 0.01, so the line reads:
>>             col = PolyCollection(nlist, linewidths=(0.01,))
>>
>> I think this will be OK; based on the comment below the line, I think 
>> I found that using a linewidth of zero was problematic, so I probably 
>> simply used 1 thinking it was small enough not to matter.
>>
>> I will need to make a corresponding change in the CVS version so that 
>> it will get into the next release.  I'll do that this evening.
>>
> Sorry about this, but that patch doesn't seem to work.  When I open the 
> eps files generated with this change implimented, I get the artifact 
> problem mentioned in the comment; fine lines at the boundaries of the 
> contouring engine's subdomains.  In fact, I get the artifacts at 
> linewidths as large as 0.5.
> 
> Jordan
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Eric Firing wrote:

> Jordan,
>
> Thanks, now I see the problem and where it is coming from.  In 
> contour.py, near the bottom, in the contourf method, change the 
> linewidth from 1 to 0.01, so the line reads:
>             col = PolyCollection(nlist, linewidths=(0.01,))
>
> I think this will be OK; based on the comment below the line, I think 
> I found that using a linewidth of zero was problematic, so I probably 
> simply used 1 thinking it was small enough not to matter.
>
> I will need to make a corresponding change in the CVS version so that 
> it will get into the next release.  I'll do that this evening.
>
Sorry about this, but that patch doesn't seem to work.  When I open the 
eps files generated with this change implimented, I get the artifact 
problem mentioned in the comment; fine lines at the boundaries of the 
contouring engine's subdomains.  In fact, I get the artifacts at 
linewidths as large as 0.5.

Jordan

Hi

I have found a problem when using external color information to color 
the arrows in a quiver-plot. I found that the norm-option does not 
affect the output. Here is the code I chanegd to fix this problem (3 
lines, marked with a #PI).

Pierre

--- fragment of file axes.py: ---

    def quiver(self, U, V, *args, **kwargs ):
        """
        QUIVER( X, Y, U, V )
        QUIVER( U, V )
        QUIVER( X, Y, U, V, S)
        QUIVER( U, V, S )
        QUIVER( ..., color=None, width=1.0, cmap=None,norm=None )

        Make a vector plot (U, V) with arrows on a grid (X, Y)

        The optional arguments color and width are used to specify the 
color and width
        of the arrow. color can be an array of colors in which case the 
arrows can be
        colored according to another dataset.

        If cm is specied and color is None, the colormap is used to give 
a color
        according to the vector's length.

        If color is a scalar field, the colormap is used to map the 
scalar to a color
        If a colormap is specified and color is an array of color 
triplets, then the
        colormap is ignored

        width is a scalar that controls the width of the arrows

        if S is specified it is used to scale the vectors. Use S=0 to 
disable automatic
        scaling.
        If S!=0, vectors are scaled to fit within the grid and then are 
multiplied by S.


        """
        if not self._hold: self.cla()
        do_scale = True
        S = 1.0
        if len(args)==0:
            # ( U, V )
            U = asarray(U)
            V = asarray(V)
            X,Y = meshgrid( arange(U.shape[1]), arange(U.shape[0]) )
        elif len(args)==1:
            # ( U, V, S )
            U = asarray(U)
            V = asarray(V)
            X,Y = meshgrid( arange(U.shape[1]), arange(U.shape[0]) )
            S = float(args[0])
            do_scale = ( S != 0.0 )
        elif len(args)==2:
            # ( X, Y, U, V )
            X = asarray(U)
            Y = asarray(V)
            U = asarray(args[0])
            V = asarray(args[1])
        elif len(args)==3:
            # ( X, Y, U, V )
            X = asarray(U)
            Y = asarray(V)
            U = asarray(args[0])
            V = asarray(args[1])
            S = float(args[2])
            do_scale = ( S != 0.0 )

        assert U.shape == V.shape
        assert X.shape == Y.shape
        assert U.shape == X.shape

        arrows = []
        N = sqrt( U**2+V**2 )
        if do_scale:
            Nmax = maximum.reduce(maximum.reduce(N))
            U *= (S/Nmax)
            V *= (S/Nmax)
            N /= Nmax

        alpha = kwargs.get('alpha', 1.0)
        width = kwargs.get('width', 0.25)
        norm = kwargs.get('norm', None)
        cmap = kwargs.get('cmap', None)
        vmin = kwargs.get('vmin', None)
        vmax = kwargs.get('vmax', None)
        color = kwargs.get('color', None)
        shading = kwargs.get('shading', 'faceted')

        C = None
        I,J = U.shape
    colorarrayflag = False #PI
        if color is not None and not looks_like_color(color):
            clr = asarray(color)
            if clr.shape==U.shape:
                C = array([ clr[i,j] for i in xrange(I)  for j in 
xrange(J)])
        colorarrayflag = True #PI
            elif clr.shape == () and color:
                # a scalar (1, True,...)
                C = array([ N[i,j] for i in xrange(I)  for j in xrange(J)])
            else:
                color = (0.,0.,0.,1.)
        elif color is None:
            color = (0.,0.,0.,1.)
        else:
            color = colorConverter.to_rgba( color, alpha )


        arrows = [ Arrow(X[i,j],Y[i,j],U[i,j],V[i,j],0.1*S ).get_verts()
                   for i in xrange(I) for j in xrange(J) ]
        collection = PolyCollection(
            arrows,
            edgecolors = 'None',
            facecolors = (color,),
            antialiaseds = (0,),
            linewidths = (width,),
            )
        if C is not None:
            collection.set_array( C )
        else:
            collection.set_facecolor( (color,) )
        collection.set_cmap(cmap)
        collection.set_norm(norm)
        if norm is not None and colorarrayflag==False: # PI
            collection.set_clim( vmin, vmax )
        self.add_collection( collection )
        lims = asarray(arrows)
        _max = maximum.reduce( maximum.reduce( lims ))
        _min = minimum.reduce( minimum.reduce( lims ))
        self.update_datalim( [ tuple(_min), tuple(_max) ] )
        self.autoscale_view()
        return arrows

Jordan,

The correction--using a small linewidth for the patch boundary (which is 
the same color as the patch)--has been committed to CVS.  Thanks for 
pointing out the problem.

Eric

Jordan Dawe wrote:
> Eric Firing wrote:
> 
>> Jordan,
>>
>> Would you send a simple example script and sample plot, please?  If I 
>> understand correctly what you are trying to do, it should work.
> 
> 
> Ok, I stuck an example on my webserver.  The script (heavily copied from 
> contour_demo.py):
> 
> http://freedryk.dyndns.org:8080/matplotlib/example.py
> 
> The eps output:
> 
> http://freedryk.dyndns.org:8080/matplotlib/example.eps
> 
> And, in case it's easier for you, the eps output converted into pdf:
> 
> http://freedryk.dyndns.org:8080/matplotlib/example.pdf
> 
> The problem can be seen by zooming into one of the contour lines.  There 
> is about a .25 pica space between the contour lines and the filled 
> contours.  This doesn't occur if you use a 1 pica line, but I don't like 
> thick lines...
> 
> Jordan
> 

Eric Firing wrote:

> Jordan,
>
> Would you send a simple example script and sample plot, please?  If I 
> understand correctly what you are trying to do, it should work.

Ok, I stuck an example on my webserver.  The script (heavily copied from 
contour_demo.py):

http://freedryk.dyndns.org:8080/matplotlib/example.py

The eps output:

http://freedryk.dyndns.org:8080/matplotlib/example.eps

And, in case it's easier for you, the eps output converted into pdf:

http://freedryk.dyndns.org:8080/matplotlib/example.pdf

The problem can be seen by zooming into one of the contour lines.  There 
is about a .25 pica space between the contour lines and the filled 
contours.  This doesn't occur if you use a 1 pica line, but I don't like 
thick lines...

Jordan

Jordan,

Would you send a simple example script and sample plot, please?  If I 
understand correctly what you are trying to do, it should work.

Thanks.

Eric

Jordan Dawe wrote:
> Hi, I hope this is the proper place to send this message.  I'm using 
> matplotlib to make contourf plots with contour overlays.  My problem is 
> that I want to be able to use .25 pica lines for the overlaid contours, 
> but since contourf demands a linethickness of 1. to avoid artifacts (due 
> to the simply-connected domain contour algorhithm), the .25 contours 
> don't actually fit the contourf right; there will be a thin line of 
> color from the next contour around the contourf before the .25 pica line 
> appears.  This annoys me to no end.
> 
> Currently I'm fixing it by plotting everything 4x larger than normal and 
> then shrinking the eps files down in Illustrator, but this is not an 
> ideal solution, since (for example) all the axis labels are in the wrong 
> position at this size.  My question is, how hard would it be to fix the 
> contour code so that contourf's linethickness argument could be 
> changed?  Where in the codebase would I look to start hacking?  In the 
> contouring code?  In the python code that accepts the contour algorithm 
> output?  I don't want to spend hours hunting through the code for the 
> right place to start modifying things...
> 
> Jordan
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi, I hope this is the proper place to send this message.  I'm using 
matplotlib to make contourf plots with contour overlays.  My problem is 
that I want to be able to use .25 pica lines for the overlaid contours, 
but since contourf demands a linethickness of 1. to avoid artifacts (due 
to the simply-connected domain contour algorhithm), the .25 contours 
don't actually fit the contourf right; there will be a thin line of 
color from the next contour around the contourf before the .25 pica line 
appears.  This annoys me to no end.

Currently I'm fixing it by plotting everything 4x larger than normal and 
then shrinking the eps files down in Illustrator, but this is not an 
ideal solution, since (for example) all the axis labels are in the wrong 
position at this size.  My question is, how hard would it be to fix the 
contour code so that contourf's linethickness argument could be 
changed?  Where in the codebase would I look to start hacking?  In the 
contouring code?  In the python code that accepts the contour algorithm 
output?  I don't want to spend hours hunting through the code for the 
right place to start modifying things...

Jordan

On Oct 8, 2005, at 12:30 AM, Steve Chaplin wrote:
> I share Ted's concern. I think a 'well-behaved child widget' does not
> know anything about its parent (or grandparent). Its added to a
> container widget and expands/shrinks (depending on its resize policy) 
> to
> use the space that the container widget gives it. So the container
> widget dictates the size of the child widget, not the other way round.

I'm also concerned about the resizable-children approach, and not just 
because it sounds scary.  The result is a FigureCanvas widget that is 
strongly coupled to its parent widget.  This poses a thorny problem for 
me because my WxMPL library subclasses FigureCanvasWxAgg and encourages 
people to embed that class directly in their own Panels, Frames, and 
whatnot.

> If you use the GUI to resize the canvas, you resize the gtk.Window and
> the gtk.Window resizes the canvas. It seems reasonable to use the same
> process to resize from a script - resize the gtk.Window and let the
> Gtk.Window resize the canvas.

I agree that this is a much more reasonable approach, and feel that its 
also more robust.  This brings me to the point of this email: is this 
now the officially blessed way of implementing interactive GUI figure 
resizing?

Ken

On Wed, 2005-10-19 at 15:28 -0500, John Hunter wrote:
> It looks like I was a bit confused about how to best include the
> kerning information, and was experimenting by treating it as a
> fraction of the width of an "m".  You may want to try some
> alternatives.  But this is where you would start hacking.

I've made some improvements and I think the result looks as good as it's
going to using the Symbol font and without a suitable font for \cal; a
revised patch is attached.  In the patch I've refactored the kerning in
mathtext.py and removed all kerning information from TrueType the font
classes (as it wasn't being used anyway) by renaming the relevant
get_kern functions.

Nick

>>>>> "Nicholas" == Nicholas Young <su...@su...> writes:

    Nicholas> On Wed, 2005-10-19 at 12:08 -0500, John Hunter wrote:
    >> Hi this looks very nice!  I have to run now but I'll give you a
    >> quick tip.  kerning controls the inter-letter spacing, and your
    >> Fonts class has to override "get_kern"; the base class always
    >> returns 0

    Nicholas> I had missed this function - but as far as I can see it
    Nicholas> isn't actually called in the majority of cases (only
    Nicholas> where set_font is called on the parent GroupElement -
    Nicholas> which doesn't always happen in any of the common cases
    Nicholas> I've tried).  Am I missing something?

The Group element is the only place kerning is set, but groups are the
right place.  Eg \rm{hi mom} is a group.  I just took a look and
noticed I commented out the place where the kern is set

    def advance(self):
        'get the horiz advance'
        return self.metrics.advance # how to handle cm units?+ self.kern*self.widthm

It looks like I was a bit confused about how to best include the
kerning information, and was experimenting by treating it as a
fraction of the width of an "m".  You may want to try some
alternatives.  But this is where you would start hacking.

JDH

        

On Wed, 2005-10-19 at 12:08 -0500, John Hunter wrote:
> Hi this looks very nice!  I have to run now but I'll give you a quick
> tip.  kerning controls the inter-letter spacing, and your Fonts class
> has to override "get_kern"; the base class always returns 0

I had missed this function - but as far as I can see it isn't actually
called in the majority of cases (only where set_font is called on the
parent GroupElement - which doesn't always happen in any of the common
cases I've tried).  Am I missing something?

Nick

>>>>> "Nicholas" == Nicholas Young <su...@su...> writes:

    Nicholas> Hi, I regularly use matplotlib on lots of systems I
    Nicholas> don't have root access to.  On most of these
    Nicholas> installation of gs 8.15 is quite problematic (and buggy)
    Nicholas> and as I result using TeX with matplotlib is
    Nicholas> impractical.  Additionally as all of the printers I have
    Nicholas> access to are HP made the use of embedded truetype fonts
    Nicholas> is also problematic.  The combination of these two
    Nicholas> problems has made it difficult to use mpl for anything I
    Nicholas> need to print and for which I need mathtext.

Hi this looks very nice!  I have to run now but I'll give you a quick
tip.  kerning controls the inter-letter spacing, and your Fonts class
has to override "get_kern"; the base class always returns 0

    def get_kern(self, font, symleft, symright, fontsize, dpi):
        """
        Get the kerning distance for font between symleft and symright.

        font is one of tt, it, rm, cal or None

        sym is a single symbol(alphanum, punct) or a special symbol
        like \sigma.

        """
        return 0


For an afm class instance, you can call get_kern_distance to get the
kerning distance between two characters.


    >>> from afm import AFM
    >>> fh = file('ptmr8a.afm')
    >>> afm = AFM(fh)
    >>> afm.get_kern_dist('A', 'y')
    -92.0

and if I recall correctly this has to be corrected by a factor of
1000.

JDH