matplotlib-devel Mailing List for matplotlib (Page 537)

Hello John,

On Tue, Oct 19, 2004 at 10:00:48AM -0500, John Hunter wrote:
> >>>>> "Jochen" =3D=3D Jochen Voss <vo...@se...> writes:
>=20
>     Jochen> None, I looked at the generated PS file out of curiosity
>     Jochen> and noticed that it does not follow the DSC conventions
>     Jochen> very well.  As this is just shuffling around comments it
>     Jochen> will probably not affect many applications.
>=20
> Are there other noncompliant things in the matplotlib ps output that
> you are aware of, other than those you already fixed?
I think the horrible ones are fixed by now.

Minor issues:

The DSC spec states (at page 18): "If there is a section in
the document that corresponds to a particular comment, that comment
*must* be used to identify that section of the document."

=46rom reading this I would guess that all the "/something { ... } bind
def" statements and the included fonts should be inside a

    %%BeginPrologue
    %%EndPrologue

block.  But I didn't check this properly.

Then page 19 "strongly suggests" to use some headers like
"%%CreationDate" and "%%Title".

Page 70 of the SDC specification states that "%%BeginFont" and
"%%EndFont" are outdated and should be replaced by "%%BeginResource"
and "%%EndResource" statements.

All the best,
Jochen
--=20
http://seehuhn.de/

>>>>> "Jochen" == Jochen Voss <vo...@se...> writes:

    Jochen> None, I looked at the generated PS file out of curiosity
    Jochen> and noticed that it does not follow the DSC conventions
    Jochen> very well.  As this is just shuffling around comments it
    Jochen> will probably not affect many applications.

Are there other noncompliant things in the matplotlib ps output that
you are aware of, other than those you already fixed?

JDH

Hello John,

On Tue, Oct 19, 2004 at 09:37:37AM -0500, John Hunter wrote:
> For my information, what ps viewers/printers were giving you trouble.
None, I looked at the generated PS file out of curiosity and
noticed that it does not follow the DSC conventions very well.
As this is just shuffling around comments it will probably
not affect many applications.

> Finally, by changing the version information to
>=20
>             pstype =3D 'PS-Adobe-3.0 EPSF-3.0'
>=20
> will we break devices that only support PS level II?
I do not think so.  It is only a change to comments and not to the
actual PostScript code.  It will only affect applications which try to
parse the DSC comments and do not understand DSC version 3.

I changed this because the document at

    http://partners.adobe.com/asn/developer/pdfs/tn/5001.DSC_Spec.pdf

which defines DSC version 3 is dated "25 September 1992", which seems
quite old to me.  If you feel more comfortable using DSC version 2 we
could either try to reverse engineer the version 2 specification using
the "Changes Since Earlier Versions" chapter in above document or try
to find a DSC 2 specification somewhere.

All the best,
Jochen
--=20
http://seehuhn.de/

I submitted the site request we discussed a couple of days ago to move
the users_guide and htdocs into the matplotlib CVS root.  This makes
'cvs co matplotlib' much faster.  I suggest you get fresh checkouts.
The three modules are

  cvs co matplotlib
  cvs co htdocs
  cvs co users_guide

I had asked them to rename htdocs and users_guide to mpl_htdocs and
mpl_users_guide but they overlooked this and I can live with it.

On a mildly related note, I just noticed that when I submitted the
site-request to have the matplotlib python tree moved into a lib
directory, all version history was lost.  Damned cvs.

JDH

>>>>> "Jochen" == Jochen Voss <vo...@se...> writes:

    Jochen> Hello,
    Jochen> On Mon, Oct 18, 2004 at 10:19:33PM +0100, Jochen Voss wrote:
    >> -%%BeginProlog +%%%%BeginProlog /inch {72 mul} def
    >> %%%%EndProlog """
    Jochen> does anybody know: is the "inch" thing actually used
    Jochen> anywhere?  Maybe it should just be removed.

No it is apparently not used anywhere.  It was a def that appeared in
my postscript book and several examples I looked at, so I threw it in
for good measure.  I just applied you PS patch, removed this, and
checked the changes into CVS.

For my information, what ps viewers/printers were giving you trouble.
We've occasionally had reports of some viewers having trouble with
matplotlib output and I would like to gather some anecdotal
information.

Finally, by changing the version information to

            pstype = 'PS-Adobe-3.0 EPSF-3.0'

will we break devices that only support PS level II?

JDH

Hello,

On Mon, Oct 18, 2004 at 10:19:33PM +0100, Jochen Voss wrote:
> -%%BeginProlog
> +%%%%BeginProlog
>  /inch {72 mul} def
>  %%%%EndProlog
>  """
does anybody know: is the "inch" thing actually used anywhere?
Maybe it should just be removed.

All the best,
Jochen
--=20
http://seehuhn.de/

Hello,

I had a look at the backend_ps.py file and found that the generated
PostScript has some problems.  The appended patch tries to bring the
generated output a little bit closer to the behaviour described in the
"PostScript Language Document Structuring Conventions Specification"
as found at

    http://partners.adobe.com/asn/developer/pdfs/tn/5001.DSC_Spec.pdf

I hope this helps,
Jochen
-- 
http://seehuhn.de/

Arrg!

OK, reading the docstring for axes, I find out that the 3rd and 4th 
argument are width and height, (not right and top).  This all works 
fine.  I was confused...

Cheers!
Andrew

Andrew Straw wrote:

> Hi All,
>
> I get what I consider to be a bug.  (I think) the following code 
> should produce a 10 row, 6 column figure with identical plots.  
> However, this code (with current CVS matplotlib), displays a 10 row, 6 
> column figure with plots of apparently varying x and y limits...
>
> Even adding "set(gca(),'xlim',(1,3)); set(gca(),'ylim',(4,6))" does 
> not help.
>
> Am I confused, or is this a bug?
>
> Cheers!
> Andrew
>
> #!/usr/bin/env python
>
> from matplotlib.matlab import *
>
> n_rows = 10
> n_cols = 6
>
> row_height = 1.0/n_rows
> col_width = 1.0/n_cols
>
> figure()
> for row in range(n_rows):
>    for col in range(n_cols):
>        axes([ col*col_width, row*row_height,
>                    (col+1)*col_width, (row+1)*row_height ])
>        plot([1,2,3],[4,5,6])
> show()
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi All,

I get what I consider to be a bug.  (I think) the following code should 
produce a 10 row, 6 column figure with identical plots.  However, this 
code (with current CVS matplotlib), displays a 10 row, 6 column figure 
with plots of apparently varying x and y limits...

Even adding "set(gca(),'xlim',(1,3)); set(gca(),'ylim',(4,6))" does not 
help.

Am I confused, or is this a bug?

Cheers!
Andrew

#!/usr/bin/env python

from matplotlib.matlab import *

n_rows = 10
n_cols = 6

row_height = 1.0/n_rows
col_width = 1.0/n_cols

figure()
for row in range(n_rows):
    for col in range(n_cols):
        axes([ col*col_width, row*row_height,
                    (col+1)*col_width, (row+1)*row_height ])
        plot([1,2,3],[4,5,6])
show()

Hello John,

On Sat, Oct 16, 2004 at 09:09:22AM -0500, John Hunter wrote:
> these, and your previous bugs, have been fixed in
> CVS and the site problems should be fixed on the sf site as well.
Thanks!  One more thing: two of the example lack the usual
python file header.  This can be fixed with the following patch:

Index: matplotlib_icon.py
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/matplotlib/matplotlib/examples/matplotlib_icon.py,v
retrieving revision 1.5
diff -u -r1.5 matplotlib_icon.py
--- matplotlib_icon.py  10 Aug 2004 15:04:27 -0000      1.5
+++ matplotlib_icon.py  16 Oct 2004 21:39:15 -0000
@@ -1,3 +1,4 @@
+#!/usr/bin/env python
 """
 make the matplotlib svg minimization icon
 """
Index: print_stdout.py
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/matplotlib/matplotlib/examples/print_stdout.py,v
retrieving revision 1.1
diff -u -r1.1 print_stdout.py
--- print_stdout.py     28 Sep 2004 14:56:56 -0000      1.1
+++ print_stdout.py     16 Oct 2004 21:39:15 -0000
@@ -1,3 +1,4 @@
+#!/usr/bin/env python
 # print png to standard out
 # usage: python print_stdout.py > somefile.png
 import sys

I hope this helps,
Jochen
--=20
http://seehuhn.de/

>>>>> "Jochen" == Jochen Voss <vo...@se...> writes:

    Jochen> Hello, the matplotlib tutorial at

    Jochen>     http://matplotlib.sourceforge.net/tutorial.html

Thanks Jochen -- these, and your previous bugs, have been fixed in
CVS and the site problems should be fixed on the sf site as well.

JDH

Hello,

the matplotlib tutorial at

    http://matplotlib.sourceforge.net/tutorial.html

states

    If you are new to python, I recommend reading as much of the
    _python tutorial_ and _numeric python manual_ as possible before
    working with matplotlib.

"Python tutorial" and "numeric python manual" are links which both
point to the web page

    http://lists.sourceforge.net/mailman/listinfo/matplotlib-users

This is probably not where they were ment to be pointing to.
I think the link targets should be changed to be

    http://docs.python.org/tut/tut.html

and

    http://www.pfdubois.com/numpy/html2/numpy.html

respectively.

I hope this helps,
Jochen
--=20
http://seehuhn.de/

Hello,

I produced a set of alternative Debian packages for matplotlib
version 0.63.4.  These are based on Vittorio Palmisano's packages,
but include the following changes:

   * I fixed the dependencies and build-dependencies.  The package
     should now build fine on build-daemons and such.
   * I only build the gtkagg backend, to keep the list of dependencies
     slim.
   * I made the package build without an X-server connection.
   * The package does no longer install duplicates of the Vera* TTF
     font files but uses the ones from ttf-bitstream-vera instead.
     This reduces the binary package size by several 100kb.
   * The example scripts in the -doc package are executable.

You can find my packages on my homepage at

    http://seehuhn.de/debian/

Comments and suggestions are very welcome.

Vittorio: fell free to incorporate all these changes into your
packages as you see fit.

All the best,
Jochen
--=20
http://seehuhn.de/

John,

Everything you write concurs with my experience with CVS, including 
that on SourceForge.  IIRC, you may be able to create a new top-level 
CVS directory in the /cvsroot/matplotlib repository without a support 
request, but it's been a long time.

On Oct 13, 2004, at 2:26 PM, John Hunter wrote:

>
> I want to move the users_guide and the htdocs out of the tree that
> people get when they say
>
>> cvs -d:pserver:ano...@cv...:/cvsroot/matplotlib login
>
>> cvs -z3 -d:pserver:ano...@cv...:/cvsroot/matplotlib 
>> co matplotlib
>
> because these directories are huge, with lots of image data for the
> users guide and web pages: 21MB for htdocs and 37MB for the users
> guide, and 99.9% of the world's sane population are not interested in
> these directories.
>
> If I move them to the root (by root, I mean the same directory in
> which the matplotlib directory resides along with CVSROOT at
> http://cvs.sourceforge.net/viewcvs.py/matplotlib/), by submitting a sf
> site request, then people could get them by doing, for example
>
> cvs -z3 -d:pserver:ano...@cv...:/cvsroot/matplotlib
> co mpl_htdocs
>
> Is this correct?  What is the proper way to refer to the directory in
> which both matplotlib and CVSROOT reside in the link above -
> /cvsroot/matplotlib?  I don't want to bungle the sf admin request.
>
> JDH
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on 
> ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give 
> us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I want to move the users_guide and the htdocs out of the tree that
people get when they say

  > cvs -d:pserver:ano...@cv...:/cvsroot/matplotlib login
 
  > cvs -z3 -d:pserver:ano...@cv...:/cvsroot/matplotlib co matplotlib

because these directories are huge, with lots of image data for the
users guide and web pages: 21MB for htdocs and 37MB for the users
guide, and 99.9% of the world's sane population are not interested in
these directories.

If I move them to the root (by root, I mean the same directory in
which the matplotlib directory resides along with CVSROOT at
http://cvs.sourceforge.net/viewcvs.py/matplotlib/), by submitting a sf
site request, then people could get them by doing, for example

cvs -z3 -d:pserver:ano...@cv...:/cvsroot/matplotlib
co mpl_htdocs

Is this correct?  What is the proper way to refer to the directory in
which both matplotlib and CVSROOT reside in the link above -
/cvsroot/matplotlib?  I don't want to bungle the sf admin request.

JDH

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:

    Andrew> Anyhow, changing all occurrences of self.legend to
    Andrew> self._legend in Axes.py fixes my problem, but perhaps
    Andrew> there are subtleties I'm not aware of?  If I don't hear
    Andrew> any objections, I'll commit these changes in a day or two.

Arggg,

Yesterday I was writing the section of the users guide in which I
described the Artist containment hierarchy (Figure contains Axes which
contain lines, legends, etc...) and decided it would be most useful
for the diagram to have attribute names as well as class types.  In
the process, I made all of the Artist attributes "public" by removing
the leading underscore.  I tried to check for method name clashes but
clearly missed this one.  Most of the attributes are lists and are
plural (lines, patches, tables).  But there is only one legend per
axes (we could change this).  So the alternatives are: 1) support
multiple legends or 2) easier, just rename it; how about "thelegend"
or "legend_"

I don't think 1) is really necessary because we already support
multiple figure legends, so you can place multiple legends around or
over an axes manually in the rare cases where you need this.

JDH

Hello again,

there is a minor problem with the INSTALL file.
It looks like it should contain instructions how to
compile and install the package, but actually it doesn't.
Maybe something like

    To compile and install the package type

      python ./setup.py build
      python ./setup.py install

could be added to the file.  Are the above commands the correct
ones?

All the best,
Jochen
--=20
http://seehuhn.de/

Hello again,

the README file of the current CVS version of matplotlib
contains the text

  ... A summary of the goals of matplotlib and the progress so far can
  be found here.

I think this changed meaning while being copied from the web page.
Maybe it should be replaced by

  ... A summary of the goals of matplotlib and the progress so far can
  be found in the file GOALS.

I hope this helps,
Jochen
--=20
http://seehuhn.de/

Hi,

In class Axes (current CVS), there is an instance variable self.legend 
as well as a method legend().  For some reason, this seems to work most 
of the time, but I found this problem when I did something like:

ax = subplot(111)
ax.legend(lines,titles)

(A "cannot call NoneType"-type error occurs).

Anyhow, changing all occurrences of self.legend to self._legend in 
Axes.py fixes my problem, but perhaps there are subtleties I'm not aware 
of?  If I don't hear any objections, I'll commit these changes in a day 
or two.

Cheers!
Andrew

Hello,

the license/ subdirectory of the current CVS version of
matplotlib contains the file LICENSE_TTFQUERY.  If I understand
things correctly ttfquery is no longer included or used in
matplotlib, and the license file could be removed.

I hope this helps,
Jochen
--=20
http://seehuhn.de/

Hello,

there is a bug in the lib/matplotlib/font_manager.py file,
which prevents fonts under /usr/share/fonts from being detected:
the callback function for os.path.walk should have three
arguments, but in the current code only has one.

This can be fixed with the following patch:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
diff -u -r1.4 font_manager.py
--- font_manager.py     30 Sep 2004 19:33:05 -0000      1.4
+++ font_manager.py     13 Oct 2004 21:22:13 -0000
@@ -64,7 +64,7 @@
     # common application, not really useful
     "/usr/lib/openoffice/share/fonts/truetype/",
     # documented as a good place to install new fonts...
-    "/usr/share/fonts",
+    "/usr/share/fonts/",
     # okay, now the OS X variants...
     "~/Library/Fonts/",
     "/Library/Fonts/",
@@ -132,12 +132,12 @@
     else:
         fontpaths =3D []
         #def add(arg, directory, files):
-        def add(directory):
+        def add(arg,directory,files):
             fontpaths.append(directory)
         for fontdir in X11FontDirectories:
             try:
                 if os.path.isdir(fontdir):
-                    os.path.walk(fontdir, add, ())
+                    os.path.walk(fontdir, add, None)
             except (IOError, OSError, TypeError, ValueError):
                 pass
         return fontpaths
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

I hope this helps,
Jochen
--=20
http://seehuhn.de/

>>>>> "Roberto" == Roberto De Almeida <ral...@gm...> writes:

    Roberto> Yes, my idea is to do it "properly", but I'm still
    Roberto> getting myself familiar with the code.

    Roberto> My original plan was to create a class
    Roberto> PolarSubplot(PolarAxes), in the same way that Subplot
    Roberto> derives from Axes. I would then create the PolarAxes
    Roberto> class, implementing all the necessary methods, like
    Roberto> plot(), imshow(), etc. That's why I mentioned imshow()
    Roberto> and pcolor(), because my idea is to implement not only
    Roberto> line plots, but specially pseudo color plots on the polar
    Roberto> axes.

    Roberto> After looking at the code for transforms, though, I'm not
    Roberto> sure if all this is really necessary. It seems to me that
    Roberto> I can define a polar transform, and simply reuse all the
    Roberto> methods already defined in the Axes class to the all the
    Roberto> work, is that right? 

I believe creating a PolarAxes is the way to go.  I would probably
also derive specialized Axis classes as well to handle the r and theta
axis, using a matplotlib.patches.Circle rather than a
matplotlib.lines.Line2d for the theta axis and grid lines.  You would
probably also need to add a rotation property to the ticks class, do
that the ticks could be placed normal to the theta axis.  I could help
out here - it might call for a new line style, one along the lines of
'_', '|' (which the current ticks use) but that could be rotated.

Once you get the axis, transformations and grids set up right, yes, I
believe you will be able to reuse many of the plotting methods.  I'm
fairly certain some work will need to be done to make images, pcolors
and other plots work with though.  But the basic plot and friends
should work without modification.

    Roberto> I saw the PolarXY transform in the _transforms module,
    Roberto> but it seems to be just a stub (matplotlib 0.63.0) -- it
    Roberto> has no defined methods.

Yes and no.  The PolarXY class defines in _transforms.h

  // the api forward and inverse functions; theta in radians
  std::pair<double, double>  operator()(const double& r, const double& theta ) {
    return std::pair<double, double>( r*cos(theta), r*sin(theta) );
  }


What is missing is a NonseparableTransformation class, developed along
the lines of the SeparableTransformation, which utilizes a FuncXY
rather than funcx and funcy.  If you are not comfortable with c++ and
the pycxx extension generator package, I would be happy to add this
part.  The polar axes would set a NonseparableTransformation with the
FuncXY set to PolarXY.

    Roberto> A few more details would be great. As I said, I'm still
    Roberto> looking at the code and getting used to how things
    Roberto> work. I would be very happy to contribute with
    Roberto> matplotlib, it's a fantastic work and something that was
    Roberto> missing in the Python world for quite a long time.

Great - I've been a bit out of the loop over the last week and will be
playing catch-up this week, but will try and get the transform stuff
into CVS for you ASAP so you can work on this.

Thanks,
JDH

>>>>> "Stefan" == Stefan Kuzminski <pon...@ya...> writes:

    Stefan> When I run the script below, the range tuple is [0.0, 1.0,
    Stefan> 0.0, 1.0]
 
    Stefan> but the data has an actual range more like [ 0, 6.8, 0,
    Stefan> 1], the plot looks correct, which is good, but the range
    Stefan> tuple is wrong.  It seems to work fine with simple data
    Stefan> examples but breaks with this data..

    Stefan> This is with Matplotlib v0.54.2

It works under 0.63 - it prints

[0.0, 1.0, 1.0, 7.0]

JDH

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:

    Paul> John,

    Paul> Is the following a line a bug in backend_tkagg.py?  Note the
    Paul> method __init5B__.  As it stands, I get a traceback with
    Paul> this piece of code.  When I change it to __init__, it works
    Paul> fine.  I see you changed this line on Oct 1.  If it is in
    Paul> error, I submit a patch.


    Paul>      Tk.Frame.__init5B__(self, master=self.figman.window,
    Paul> width=width, height=height, borderwidth=2)

Clearly a bug.  I would have guessed that Clara started banging on my
keyboard while I was trying to change her, but she wasn't born yet.
Can you commit the fix?

JDH

John,

Is the following a line a bug in backend_tkagg.py?  Note the method 
__init5B__.  As it stands, I get a traceback with this piece of code.  
When I change it to __init__, it works fine.  I see you changed this 
line on Oct 1.  If it is in error, I submit a patch.


     Tk.Frame.__init5B__(self, master=self.figman.window,
                          width=width, height=height,
                          borderwidth=2)

 -- Paul

-- 
Paul Barrett, PhD      Space Telescope Science Institute
Phone: 410-338-4475    ESS/Science Software Branch
FAX:   410-338-4767    Baltimore, MD 21218