matplotlib-devel Mailing List for matplotlib (Page 3)

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

When I run the script below, the range tuple is 

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

This is with Matplotlib v0.54.2

thanks,
S

#!/usr/bin/env python
import matplotlib
matplotlib.use( 'Agg' )
from matplotlib.matlab import *

x = [0.010331810701842871, 0.021066657441595242, 0.030855574358625324,
     0.040250726568746162, 0.050644838316290561, 0.06189415611955508,
     0.07125403603817515, 0.081941196069626396, 0.090571411794129267,
     0.10290686247291918, 0.11444331944589031, 0.1236257225395061,
     0.13473835780826723, 0.14381271569968049, 0.15290481341399415,
     0.16191929992110601, 0.17121682383712447, 0.18154558306766691,
     0.19166699839060464, 0.20041014147521002, 0.21840114667773247,
     0.22475368329468168, 0.23712042657177207, 0.24150561679187502,
     0.25777416395085717, 0.26370159485599637, 0.27115042730497135,
     0.28646842404763118, 0.2945605476107212, 0.3014844847904839,
     0.32090649437954005, 0.33474756188146532, 0.3463087158021369,
     0.35384920060301411, 0.36174596447259966, 0.37111350597671988,
     0.38500936142234621, 0.39310145975693639, 0.40090051408431981,
     0.41178548112097552, 0.42521787270909123, 0.43091391530572509,
     0.44614791389868291, 0.45494374609978966, 0.46186821556645236,
     0.47731590557971521, 0.48107399513220339, 0.4960609645338554,
     0.50293271758231672, 0.51908955994969641, 0.52754726056509504,
     0.538105663764743, 0.54695915774055104, 0.55445022367222696,
     0.56141617038929059, 0.57715732876336034, 0.58331953613820509,
     0.59203627993390995, 0.61018141394423642, 0.62628626881841487,
     0.63192539107874746, 0.6458016862544731, 0.65418149983636986,
     0.66065035611712197, 0.67079601269616063, 0.69003927324831349,
     0.70370643441733494, 0.71145337333441738, 0.72891863943192814,
     0.73620657868200012, 0.7416812708183288, 0.7543094129509258,
     0.76333622772703824, 0.77279502708216075, 0.78113840195825734,
     0.79518542174128759, 0.80283072754516693, 0.81348359069451792,
     0.82483196143668502, 0.83317823230638111, 0.84262635287300347,
     0.85060271704979107, 0.86622649392165829, 0.87378445858363607,
     0.88564073099481444, 0.89462710396172573, 0.90198905417679853,
     0.91225691885603977, 0.92314275233649545, 0.93022796091666171,
     0.94117604421861889, 0.95082199713874538, 0.96289363701352881,
     0.97353750955077867, 0.98050771299924244, 0.99071041335468191,
     1.0]

y = [
    6.8988430562808141, 6.0199122670123426, 5.4877276439939475,
    5.1709425981970805, 4.987254825650786, 4.7417327487085501,
    4.4978934463413314, 4.3250286563667935, 4.2007265350751535,
    4.0541464163597736, 3.9189273603700538, 3.8235472853454988,
    3.7164102779555512, 3.6445717916889664, 3.5480676732338021,
    3.4444786019802529, 3.3625904441222376, 3.2806471950213569,
    3.2011340640076367, 3.1510030907701263, 3.019839474428009,
    2.9822021628354816, 2.9059803156387574, 2.8856395987093051,
    2.7921865811397399, 2.7589612680359936, 2.7174335309498603,
    2.6324831804685527, 2.5900376295500123, 2.5597848772179619,
    2.4655519919224202, 2.4080342023330061, 2.357560958250656,
    2.3276036195316627, 2.2941290050680068, 2.2529601292610253,
    2.2040744982244793, 2.1752627057435507, 2.1490323132220679,
    2.1143606533996637, 2.0692410113398481, 2.0505144863177676,
    2.0051930431043892, 1.9783735967494613, 1.9567455423743982,
    1.9117142836414112, 1.9015246184270749, 1.8570312324545144,
    1.8373286819197756, 1.7930616898324281, 1.7698772818526114,
    1.7416837457846306, 1.7191776401533563, 1.6985358308203811,
    1.6826034910369574, 1.6460157936833077, 1.6312087148596748,
    1.6120311128551963, 1.5717381767713174, 1.5393408540494826,
    1.5277823839983642, 1.4990255085133, 1.482078897585539,
    1.4703127379153567, 1.4503193917059973, 1.414718900022627,
    1.3902791696828953, 1.3773840753041227, 1.3485627887870608,
    1.3368879344126419, 1.3280498048998697, 1.3087099772217325,
    1.2943614279230125, 1.2807173903668139, 1.2682285769430715,
    1.2471152061484074, 1.2357065246849019, 1.2212562025804223,
    1.2059396101922433, 1.19434578885053, 1.1818376806548032,
    1.1710070331197149, 1.150850866654737, 1.141314474700714,
    1.1268033459945574, 1.1160062947810399, 1.1072603628571882,
    1.0952161339218929, 1.082587112669787, 1.0743414397576259,
    1.0620959689501084, 1.0514270580154892, 1.0383865727621933,
    1.0270434782193152, 1.0198775771453545, 1.009374502605529,
    1.0]

plot(x, y )
print axis() # why does this print [0.0, 1.0, 0.0, 1.0]?
savefig('simple_plot')



		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

On Tue, 05 Oct 2004 20:14:44 -0500, John Hunter
<jdh...@ac...> wrote:
> The work in progress claim is a bit overstated.  If you search the
> user's mailing list for polar, you'll see some code that was posted
> that essentially provides a poorman's polar plot.  It makes plot that
> roughly do the right things vis-a-vis polar, but to "do it right (tm)"
> you'll need to implement a polar axis class, derived from the Axis
> base class (eg use patch.Circle to draw the theta axis).  A polar
> transform class is defined in the _transforms module.  Among the other
> changes, you'll want to set the default transform for polar axes.

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

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

After looking at the code for transforms, though, I'm not sure if all
this is really necessary. It seems to me that I can define a polar
transform, and simply reuse all the methods already defined in the
Axes class to the all the work, is that right? I saw the PolarXY
transform in the _transforms module, but it seems to be just a stub
(matplotlib 0.63.0) -- it has no defined methods.

> If you decide you want to jump in, let me know and I'll write a more
> long winded email about what I think is involved, bearing in mind that
> I haven't actually implemented any of this code so my comments should
> be taken with a grain of salt.

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

Roberto

-- 
Roberto De Almeida <ro...@de...>
this email is: [ ] bloggable [ ] ask first [ ] private [x] nonsense

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

    Roberto> Hi, I was wondering about the status of polar plots --
    Roberto> the website says only "work underway" If no one is
    Roberto> working on this, I'm interested on implement polar plots
    Roberto> (and also imshow, pcolor, etc).

The work in progress claim is a bit overstated.  If you search the
user's mailing list for polar, you'll see some code that was posted
that essentially provides a poorman's polar plot.  It makes plot that
roughly do the right things vis-a-vis polar, but to "do it right (tm)"
you'll need to implement a polar axis class, derived from the Axis
base class (eg use patch.Circle to draw the theta axis).  A polar
transform class is defined in the _transforms module.  Among the other
changes, you'll want to set the default transform for polar axes.

If you decide you want to jump in, let me know and I'll write a more
long winded email about what I think is involved, bearing in mind that
I haven't actually implemented any of this code so my comments should
be taken with a grain of salt.  

I'm not clear about the context of your mention of imshow and pcolor;
could you elaborate?

JDH

Hi,

I was wondering about the status of polar plots -- the website says
only "work underway" If no one is working on this, I'm interested on
implement polar plots (and also imshow, pcolor, etc).

Roberto

-- 
Roberto De Almeida <ro...@de...>
this email is: [ ] bloggable [ ] ask first [ ] private [x] nonsense

Hello,

I noticed that several of the SVG files installed by
matplotlib version 0.63.4 are marked as executable:

# tar tfvvz matplotlib-0.63.4.tar.gz | grep "rwx.*\.svg"
-rwxr-xr-x jdhunter/members   3064  matplotlib-0.63.4/images/back.svg
-rwxr-xr-x jdhunter/members  14402  matplotlib-0.63.4/images/filesave.svg
-rwxr-xr-x jdhunter/members   3069  matplotlib-0.63.4/images/forward.svg
-rwxr-xr-x jdhunter/members   4888  matplotlib-0.63.4/images/hand.svg
-rwxr-xr-x jdhunter/members  11796  matplotlib-0.63.4/images/home.svg
-rwxr-xr-x jdhunter/members   5906  matplotlib-0.63.4/images/move.svg
-rwxr-xr-x jdhunter/members   8998  matplotlib-0.63.4/images/zoom_to_rect.s=
vg

Probably the executable flag for these files should just
be cleared.

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

Yeah, now I remember installing those fonts a while ago so I could put
symbols in my diagrams in inkscape...

For embedding, we need SVG fonts.  Would it be kosher to just use this:

http://xml.apache.org/batik/ttf2svg.html

or its equivalent to convert the BaKoMa fonts to SVG, and then include
the resulting SVG fonts in the matplotlib package?

Jared

> Hmm, this is strange and intriguing.  I notice that you do not embed
> the fonts in your svg document, which is presumably why most viewers
> can't handle it.  I confirmed that librsvg, which gqview uses, can't
> render the fonts either.  The question is, why can Inkscape do it?  I
> downloaded Inkscape and did a recursive grep through their src as well
> as a find in the root of their src tree and found no references to
> 'computer modern' or cmex, etc....  Did you have to set some path in
> inkscape to see your cm fonts, or did you put them in some standard
> place?  Anyone have any ideas how inkscape manages to pull off this
> trick?

>     Jared> John, are there any more features still missing from the
>     Jared> SVG backend?
> 
> That almost does it.  I think we need an option to embed the fonts
> directly into the svg document like we do for PS, because I think
> viewers that have the cm* fonts built in will be the exception rather
> than the rule.  Fernando Perez has some colleagues who are interested
> in embedding clickable tags in svg, but I haven't heard much from
> them.
> 
> But overall SVG is in fine shape.

>>>>> "Jared" == Jared Wahlstrand <wah...@um...> writes:

    Jared> Hello, The attached patches implement mathtext for SVG. The
    Jared> output looks pretty good when viewed by Inkscape, but not
    Jared> the Adobe SVG viewer (it shows the wrong symbols and then
    Jared> moments later crashes Mozilla, at least on my system).  It
    Jared> hasn't been thoroughly tested for all of the possible
    Jared> symbols.

Hmm, this is strange and intriguing.  I notice that you do not embed
the fonts in your svg document, which is presumably why most viewers
can't handle it.  I confirmed that librsvg, which gqview uses, can't
render the fonts either.  The question is, why can Inkscape do it?  I
downloaded Inkscape and did a recursive grep through their src as well
as a find in the root of their src tree and found no references to
'computer modern' or cmex, etc....  Did you have to set some path in
inkscape to see your cm fonts, or did you put them in some standard
place?  Anyone have any ideas how inkscape manages to pull off this
trick?

    Jared> I had to add a math_parse_s_ft2font_svg() to mathtext.py,
    Jared> which basically does the same thing as
    Jared> math_parse_s_ft2font() but returns something different.  I
    Jared> tried to just modify the latter function to take a
    Jared> "usingSVG=True" argument and ran into all sorts of bizarre
    Jared> problems, probably associated with the caching, and gave
    Jared> up.  Perhaps someone can figure out how to do this more
    Jared> elegantly.

Probably the best way to do this is to subclass BakomaTrueTypeFonts
and override the just methods you need.

    Jared> John, are there any more features still missing from the
    Jared> SVG backend?

That almost does it.  I think we need an option to embed the fonts
directly into the svg document like we do for PS, because I think
viewers that have the cm* fonts built in will be the exception rather
than the rule.  Fernando Perez has some colleagues who are interested
in embedding clickable tags in svg, but I haven't heard much from
them.

But overall SVG is in fine shape.

Many thanks!
JDH

Hello,

The attached patches implement mathtext for SVG. The output looks pretty
good when viewed by Inkscape, but not the Adobe SVG viewer (it shows the
wrong symbols and then moments later crashes Mozilla, at least on my
system).  It hasn't been thoroughly tested for all of the possible
symbols.

I had to add a math_parse_s_ft2font_svg() to mathtext.py, which
basically does the same thing as math_parse_s_ft2font() but returns
something different.  I tried to just modify the latter function to take
a "usingSVG=True" argument and ran into all sorts of bizarre problems,
probably associated with the caching, and gave up.  Perhaps someone can
figure out how to do this more elegantly.

John, are there any more features still missing from the SVG backend?

Cheers,

Jared

My system is set up so that when I am logged into root (via su) the root user 
cannot access the X display. I like this behavior but it means that I cannot 
install matplotlib as the root user (I can use sudo) because setup.py wants 
to import pygtk and wxPython both of which try to connect to the X display.

It seems to me that it is unnecessary to connect to the display to compile the 
matplotlib extensions, rather the import gtk command exists to test to see if 
the pygtk package is installed. If I am wrong then this does not matter. I 
thought that the build procedure would be more robust is it was not necessary 
to import the whole pygtk and wxPython packages in order to test for their 
presence. Is there a standard way to test for the presence of a package 
without actually importing it? I know that I could temporarily export a 
display for the root user - but I don't want to and I don't think it should 
be necessary if it is not required.

I have been thinking about ways to test for packages without importing them. 
Would it be possible to test for the offending packges by importing 
subpackages that do not connect to the X server? For example in the case of 
pygtk 'gobject' can be imported successfully when no X display is available. 
(This works on my system because pygtk-2.0 is part of the python path - I did 
not put it there so I assume that is standard - if not this procedure would 
require that the appropriate directory was appended to then removed from the 
python path.)

The disadvantages that I can see are that it would make the build procedure 
dependant on the naming of subpackages within a package and it would not 
actually check for a working installation just the presence of a certain 
package. I guess it depends how great the demand is to be able to install 
matplotlib from an environment that does not have a X display.

Cheers
Chris

Dear Mr. Horton:

I am investigating options for creating 2D contour plots for the freely
distributable Matplotlib package (http://matplotlib.sourceforge.net/).
The Matplotlib license requires all the software to be free for
noncommercial and commercial distribution.

I had the idea to try to implement marching squares for this package.  We
know the marching cubes algorithm is patented, but what about the 2D
marching squares?  Can my implementation be used in this freely
distributed package without obtaining a license grant?

Thanks,
Curtis

      * * * * * * * * * * * * * * * * * * * * * * * * * * * *
    *   Curtis S. Cooper, Graduate Research Assistant         *
   *    Lunar and Planetary Laboratory, University of Arizona  *
   *    http://www.lpl.arizona.edu/~curtis/		       *
   *    Kuiper Space Sciences, Rm. 318                         *
    *   1629 E. University Blvd.,                             *
     *  Tucson, AZ 85721        * * * * * * * * * * * * * * *
      * Wk: (520) 621-1471     *
       * * * * * * * * * * * *

John Hunter <jdh...@ac...> writes:

| 
| Do you have any thoughts on how we might do labels with your code?

2 ways:

1) automatically: define a coarser(user defined coarseness) mesh on
   the function to be labelled, and add the labels in the vertices of
   this mesh. the angle of each label can easily be found from the
   closest contour line segment. this method avoids clusters of labels
   effectively, but will not be good in areas with high variability.

2) manually: let the user point and click on contours, I implemented
   this for use with gist that you could take a look at (clabel below).
   matlab also does this, and I think this is the best way for real
   publication quality. I have never seen automatic routines that do
   labelling well. TECPLOT is close but not quite there.

   I also attached a routine to do this for 2D stretched coordinates (see
   the contour plots with labels on
      http://www.ii.uib.no/~avle/python.html 
   for examples) which is called vclabel

| 
| If we decide to go with your routines, at least for the time being
| until we can "do it right", would you be willing to contribute your
| code to matplotlib under the matplotlib license (PSF inspired, free
| for commercial and noncommercial reuse)?

sure, no problem.

Helge




def clabel(z,clevels,opa=1,col='black',meth='std',digits=1):
    """
    clabel(z,clevels,opa=1,col='black')
    
    At the point where the mouse is clicked, print the contour level
    from clevels that are closest to the interpolated value in this
    point. Meant to be useful for labeling contour lines manually...
    
    optional arguments:
    opa=0 : Transparent text.
    opa=1 : Erase background under label
    col='white'  : text color.
    meth= 'std'   bilinear interpo on a std grid, might give error near coast
          'grid'  values not given cellcentered but on corners of cells. 
          'bigrid' values taken from a bilinearly interpol fine mesh from
	  futil.contour
          'cell'  takes value from cell directly

    Helge Avlesen <av...@ii...>
    
    """
    
    print """
    Insert contour levels by left clicking, middle button display
    values, right button finishes.
    """
    
    button=0
    while button<>3:    
        mus=gist.mouse()                   
        button=mus[9]

	if meth=='bigrid':
	    i=int(2*mus[0])+1 ; j=int(2*mus[1])+1
	    x=2*mus[0]-i+1     ;  y=2*mus[1]-j+1
	elif meth=='std':
	    i=int( mus[0] );  j=int( mus[1] )
	    x=mus[0]-i     ;  y=mus[1]-j
	elif meth=='grid':	    
	    xm=mus[0]+0.5 ; ym=mus[1]+0.5
	    i=int( xm );  j=int( ym )
	    x=xm-i     ;  y=ym-j
        elif meth=='cell':
            print mus[0], mus[1]
            i=int(round(mus[0])) ; j=int(round(mus[1]))

        if meth=='cell':
            val=z[i,j]
            print val,i,j
        else:
            # bilinear interpolation to find value        
            a00=z[i,j] 
            a10=z[i+1,j]-a00 
            a01=z[i,j+1]-a00 
            a11=z[i+1,j+1]-(a00+a10+a01) 
            val=a00 + a10*x + a01*y + a11*x*y
            print val,i,j,x,y            

        if button==1:                    
            # compare this value to the selected levels
            diff= abs( clevels-val )  

            # use the closest
            label=fpformat.fix( clevels[  Numeric.argmin(diff) ], digits )

            gist.plt(label, mus[0], mus[1], opaque=opa, tosys=1, \
                     height=8, justify="CH", color=col )



def vclabel(z,sx,sy,clevels,opa=1,col='black',digits=1):
    """
    manual(z,clevels,opa=1,col='black')
    
    At the point where the mouse is clicked, print the contour level
    from clevels that are closest to the interpolated value in this
    point. Meant to be useful for labeling contour lines manually...

    sx[i,j],sy[i,j] is the x,z coordinate of point z[i,j]. if [:,1]
    denotes the top layer, [:,kb-1] the bottom (common in
    oceanography) j_is_down will be true. (z is always positive in
    the upward direction, but the indice j may go downwards)
    
    optional arguments:
    opa=0 : Transparent text.
    opa=1 : Use background color for text.
    col='white'  : text color.
    digits: number of decimals in label

    Helge Avlesen <av...@ii...>
    
    """
    
    print """
    Insert contour levels by left clicking, middle button display
    depth, right button finishes.
    """
    kb=z.shape[1]
    im=z.shape[0]

    j_is_down=0    
    if sy[0,0]>sy[0,1]:
        j_is_down=1
    
    button=0
    while button<>3:
        mus=gist.mouse()
        button=mus[9]
       
	# bisection search for the indices
        i=hbisect( sx[:,0], mus[0] )
        if i<0 or i>im-1:
            print 'outside:',i
            continue
        
        x=(mus[0]-sx[i,0])/(sx[i+1,0]-sx[i,0])
        
        if j_is_down:
            finn=hbisect( (1.-x)*sy[i,::-1] + x*sy[i+1,::-1] , mus[1] )
            j=kb-2-finn
            if finn<0 or finn>kb-1:
                print 'outside',i,finn
                continue
       
            xa=Numeric.array((sx[i,j+1]+x*(sx[i+1,j+1]-sx[i,j+1]),\
                              sy[i,j+1]+x*(sy[i+1,j+1]-sy[i,j+1])))
            
            if mus[1]-xa[1]<0:
                print 'below'
                continue
            
            xb=Numeric.array((sx[i,j]+x*(sx[i+1,j]-sx[i,j]),\
                              sy[i,j]+x*(sy[i+1,j]-sy[i,j])))
        
            y=(((mus[0]-xa[0])**2 + (mus[1]-xa[1])**2 )\
               /((xb[0]-xa[0])**2 + (xb[1]-xa[1])**2 ))**0.5
                
            # bilinear interpolation to find value
        
            a1=z[i,j+1] 
            a2=z[i+1,j+1]-a1 
            a3=z[i,j]-a1	
            a4=z[i+1,j]-(a1+a2+a3) 
            val=a1 + a2*x + a3*y + a4*x*y
        else:
            print 'increasing j upwards not yet implemented'
            continue
            
        print 'x,y=',x,y,' i,j=',i,j, 'val=',val

        if button==1:                    
            # compare this value to the selected levels
            diff= abs( clevels-val )  

            # use the closest
            label=fpformat.fix( clevels[  Numeric.argmin(diff) ], 1)

            if opa==1:
                label=' '+label+' '

            gist.plt(label, mus[0], mus[1], opaque=opa, tosys=1, \
                     height=8, justify="CH", color=col )

John Hunter schrieb:
>>>>>>"Fernando" =3D=3D Fernando Perez <Fer...@co...> writ=
es:
>=20
>=20
>     Fernando> I think we're doing pretty good, except that people can
>     Fernando> always kill themselves by running true WX/GTK apps via
>     Fernando> @run.  IPython is really not made for this, it can only
>     Fernando> handle gracefully show() calls from pure matplotlib
>     Fernando> scripts, not full-blown GUI apps.  But I think we have a
>     Fernando> very reasonable environment at this point for most usage
>     Fernando> cases.
>=20
> It's looks like about 90% of your problems result from trying to cross
> GUI backends within IPython.  Is this fair to say?

Well, not quite.  As I mentioned, I put in a matplotlib.use() wrapper whi=
ch=20
traps invalid switches, so it's not a problem if a use() call is made.  C=
ould=20
you add such a call to this one please? :

// OK with GTKAgg backend. It needs a use('GTKAgg') call to be safe for o=
ther
backends.
run dynamic_image_gtkagg.py


It's only when native GUI examples are run that things crash badly.  Note=
 that=20
some of the segfaults occur from plain python:

// these are OK with gtkagg, but they segfault wxagg.  The segfault happe=
ns
from a normal command line as well (no ipython).

run system_monitor.py
run dynamic_demo.py

And I also have these:
// these two run but segfault on exit under ipython.  They run OK from a =
cmd line.
run dynamic_demo_wx.py
run dynamic_image_wxagg.py

I suspect these two are messing something up badly enough that if python =
quits=20
right away, you don't see the problem, but since ipython continues to run=
 the=20
interpreter, the problem appears.  Since these are segfaults, I'm very mu=
ch=20
willing to blame the wx code in there, and not ipython (which is 100% pur=
e,=20
unpolluted python :)

> As far as I'm concerned I don't have a problem with these cases.
> Caveat emptor -- the user should be forewarned and expect disaster if
> they try and run GUI specific examples from ipython.  Perhaps you
> should say pylab only supports pure matlab interface matplotlib at
> this point.
>=20
>>From your end I see why it's a concern - you don't want any run
> command to break or freeze ipython.  If you have any ideas on what we
> should do I'll be happy to help on the matplotlib end, but I don't
> have any off the top of my head.

Yes, this is the real nasty.  If you think that the ipython+matplotlib=20
combination is going to be a common one in the future for scientists, it =
may=20
be worth protecting the examples against disaster (given they tend to be =
what=20
people run to first).  If you are willing to pay the price of 12 lines of=
 code=20
per example, you could put this snippet at the beginning of _every_ embed=
ded=20
example:

# Detect if we are inside IPython and bail if so.  Threading problems
# make it very difficult to safely run full GTK/WX apps inside IPython.
try:
     __IPYTHON__
     msg =3D ("This script can NOT be run inside IPython.\n\n"
            "It embeds matplotlib into a complete GUI application, and\n"
            "for a number of reasons this is (and probably will remain)\n=
"
            "unsupported from inside IPython.\n\n"
            "You can run it from the command line as a regular python scr=
ipt.\n")
     raise RuntimeError,msg
except NameError:
     pass

This will make sure that users get a meaningful error message inside ipyt=
hon=20
instead of a bizarre lockup or segfault.


> I'll comment on some of the non cross-GUI problems below....
>=20
>     Fernando> // These don't run with LANG=3D=3Dde_DE.UTF-8, but are OK
>     Fernando> with en_US.UTF-8 run date_demo_convert.py run
>     Fernando> date_demo1.py run date_demo2.py run date_demo_rrule.py
>     Fernando> run finance_demo.py
>=20
> Do they run from the shell with LANG=3D=3Dde_DE.UTF-8?  Any idea what i=
s
> going wrong?

Yes, the problem has nothing to do with ipython, it also happens with pla=
in=20
python.  Note that the broken ones are:

// These don't run with LANG=3D=3Dde_DE.UTF-8, but are OK with en_US.UTF-=
8
run date_demo1.py
run date_demo2.py
run finance_demo.py

I think my original list had more by mistake.  Here's a traceback (form=20
ipython, so you get better details):

In [5]: run date_demo1.py
-------------------------------------------------------------------------=
--
ValueError                                Traceback (most recent call las=
t)

/home/fperez/code/python/pylab/examples/date_demo1.py
      26 yearsFmt =3D DateFormatter('%Y')
      27
---> 28 quotes =3D quotes_historical_yahoo(
      29     'INTC', date1, date2)
      30 if not quotes:

/usr/local/lib/python2.3/site-packages/matplotlib/finance.py in=20
quotes_historical_yahoo(ticker, date1, date2)
      61         if len(vals)!=3D7: continue
      62         datestr =3D vals[0]
---> 63         dt =3D datetime.date(*time.strptime(datestr, '%d-%b-%y')[=
:3])
      64         d =3D date2num(dt)
      65         open, high, low, close =3D  [float(val) for val in vals[=
1:5]]

/usr/src/build/394694-i386/install/usr/lib/python2.3/_strptime.py in=20
strptime(data_string, format)
     422     found =3D format_regex.match(data_string)
     423     if not found:
--> 424         raise ValueError("time data did not match format:  data=3D=
%s=20
fmt=3D%s" %
     425                          (data_string, format))
     426     if len(data_string) !=3D found.end():

ValueError: time data did not match format:  data=3D31-Mar-04  fmt=3D%d-%=
b-%y
WARNING: Failure executing file: <date_demo1.py>

The problem is that under different locales, dates come out formatted=20
differently.  You seem to have hardcoded format expectations which break =
in=20
the face of non-US locales.

>     Fernando> run print_stdout.py
>=20
> This is an example script to show how to print png to stdout from agg.
> Perhaps this fails because ipython doesn't really expect a png coming
> in from stdout?  The header of that file states

Well, running it again I'm getting this:

Exception in thread Thread-1:
Traceback (most recent call last):
   File "/usr/src/build/394694-i386/install/usr/lib/python2.3/threading.p=
y",=20
line 436, in __bootstrap
     self.run()
   File "/home/fperez/code/python/IPython/Shell.py", line 527, in run
     self.IP.mainloop()
   File "/home/fperez/code/python/IPython/iplib.py", line 948, in mainloo=
p
     self.interact(banner)
   File "/home/fperez/code/python/IPython/iplib.py", line 1036, in intera=
ct
     line =3D self.raw_input(prompt)
   File "/home/fperez/code/python/IPython/iplib.py", line 1263, in raw_in=
put
     return self.prefilter(raw_input(prompt),
IOError: [Errno 9] Ung=FCltiger Dateideskriptor

Pehaps you could add (if you decide that you like that idea) the __IPYTHO=
N__=20
trap code to this as well, so that all examples are made ipython-friendly=
.  In=20
this one, the message could additionally show this:

   print png to standard out
   usage: python print_stdout.py > somefile.png

so users know what to do straight away.

> Thanks for the detailed notes.

No prob.  I'm a big believer that good examples are what helps most new u=
sers,=20
so I'm trying to make sure that out-of-the-box, things run as smoothly as=
=20
possible for all those scientists who are just dying to start using matpl=
otlib=20
  with ipython :)

Best,

f

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

    >> Hi again,
    >> 
    >> Yes, I had the thought that using C for the algorithm would be
    >> easier as well.  There are actually some very well-written
    >> marching squares contouring algorithms in C already out there.
    >> I will try to find such an implementation and point you to it
    >> or send you the source code.
    >> 
    Perry> Thanks, that would be helpful. In my search I didn't come
    Perry> across many.  Keep in mind the license needs to be
    Perry> compatible with that of matplotlib.

Of course, in addition to the license, there is the patent issue.  I
believe marching squares is patented.  I know marching cubes is.

  http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=4,710,876.WKU.&OS=PN/4,710,876&RS=PN/4,710,876

I checked the header of vtkMarchingSquares.cxx which states

  Program:   Visualization Toolkit
  Module:    $RCSfile: vtkMarchingSquares.cxx,v $
 
  Copyright (c) Ken Martin, Will Schroeder, Bill Lorensen
  All rights reserved.
  See Copyright.txt or http://www.kitware.com/Copyright.htm for details.
 
 
     THIS CLASS IS PATENTED UNDER UNITED STATES PATENT NUMBER 4,710,876
     "System and Method for the Display of Surface Structures Contained
     Within the Interior Region of a Solid Body".
     Application of this software for commercial purposes requires
     a license grant from GE. Contact:

but the patent number they reference which is linked above begins with

  A method and apparatus for displaying *three dimensional surface
  images* includes the utilization of a case table for rapid retrieval
  of surface approximation information.

emphasis mine.  So I don't know for sure what the patent status of the
2D algorithm is.

JDH