matplotlib-devel Mailing List for matplotlib

I just downloaded the 0.50 tar.gz and found the fonts folder appears to
be awol.
other than that it is working great :)
john

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
jdh...@ac... ha scritto:
> Two (possibly related) things I found surprising were the install size
> (21MB!) and an ATLAS dependency. I suspect the latter comes from a
> scipy requirment, which matplotlib does not depend on.
>
> humanos:~> sudo apt-get install python-matplotlib python-matplotlib-doc
> Reading Package Lists... Done
> Building Dependency Tree... Done
> The following extra packages will be installed:
> atlas2-base fonttools libart-2.0-2 libg2c0 libttf2 python-gdmodule
> python-pypaint python-ttfquery python2.3-numeric python2.3-numeric-ext
> python2.3-xml
> The following NEW packages will be installed:
> atlas2-base fonttools libart-2.0-2 libg2c0 libttf2 python-gdmodule
> python-matplotlib python-matplotlib-doc python-pypaint python-ttfquery
> python2.3-numeric python2.3-numeric-ext python2.3-xml
> 0 packages upgraded, 13 newly installed, 0 to remove and 150 not upgraded.
> 2 packages not fully installed or removed.
> Need to get 6099kB of archives. After unpacking 21.2MB will be used.
> Do you want to continue? [Y/n] y
>
> Is the ATLAS requirement intentional, or a vestigial dependency from
> some other package in your collection?
Ok, I have removed the python2.3-numeric-ext dependency. The new version is on
the server
- --
/Vittorio Palmisano/
Home Page: http://redclay.altervista.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAPga4pT6bvDtyXOIRApu0AKDMEXGwqhsjQHr66KsAQYGAkCqq1ACgvZob
1GiHun0m4qd+c4yZKoGScu4=
=amuJ
-----END PGP SIGNATURE-----

Todd Miller has added a TkAgg backend to CVS. As the name implies,
this is a Tkinter GUI backend which uses agg to render. One very nice
feature of this backend is that it works interactively from any python
shell, though you'll still need to set matplotlib.interactive(True).
 > python -i yourscript.py -dTkAgg
 
There may be a few minor issues to clear up, but it will be included
in the next release, so now would be a good time to test it out
(Thanks Todd!)
Also, following Paul Barrett's pointer to the BaKoMa fonts, I
implemented a TeX math parser which works with the new ft2font module
to render math text. Any text element (xlabel, ylabel, title, text,
etc) can use TeX markup, as in
xlabel(r'$\Delta_i$')
 ^
 use raw strings
The $ symbols must be the first and last symbols in the string. Eg,
you cannot do 
 r'My label $x_i$'. 
But you can change fonts, as in 
 r'\rm{My label} x_y' 
to achieve the same effect.
A large set of the TeX symbols are provided (see below). Subscripting
and superscripting are supported, as well as the over/under style of
subscripting with \sum, \int, etc.
The module uses pyparsing to parse the TeX expression, an so can
handle fairly complex TeX expressions
Eg, the following renders correctly
tex = r'$\cal{R}\prod_{i=\alpha_{i+1}}^\infty a_i\rm{sin}(2 \pi f x_i)$'
See http://nitace.bsd.uchicago.edu:8080/files/share/mathtext_demo.png
for a screenshot.
The fonts \cal, \rm, \it, and \tt are defined.
The computer modern fonts this package uses are part of the BaKoMa
fonts, which are (in my understanding) free for noncommercial use.
For commercial use, please consult the licenses in fonts/ttf and the
author Basil K. Malyshev - see also
http://www.mozilla.org/projects/mathml/fonts/encoding/license-bakoma.txt
KNOWN ISSUES:
 - some hackish ways I deal with a strange offset in cmex10
 - bbox is a bit large in vertical direction and small in horizontal direction
 - nested subscripts, eg, x_i_i not working
 - nesting fonts changes in sub/superscript groups not parsing
 - no rotations yet
 - no kerning
I would like to add more layout commands, like \frac.
Backends: This currently works with Agg, GTKAgg and TkAgg. If David
incorporates ft2font into paint, it will be easy to add to Paint. I
think I can also add it to GTK rather straightforwardly, since it's
just a matter of rendering from the ft2font pixel buffers; ditto for
wx. PS will require more substantial work, doing the metrics and
layouts with the AFM versions of the computer modern fonts. Backends
which don't support mathtext will just render the TeX string as a
literal.
CVS is updated - or if you prefer, I uploaded a snapshot to
http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.51c.tar.gz
Let me know how it goes! I expect there will be plenty of issues
cropping up.
JDH
Allowed TeX symbols:
\Delta \Downarrow \Gamma \Im \LEFTangle \LEFTbrace \LEFTbracket
\LEFTparen \Lambda \Leftarrow \Leftbrace \Leftbracket \Leftparen
\Leftrightarrow \Omega \P \Phi \Pi \Psi \RIGHTangle \RIGHTbrace
\RIGHTbracket \RIGHTparen \Re \Rightarrow \Rightbrace \Rightbracket
\Rightparen \S \SQRT \Sigma \Sqrt \Theta \Uparrow \Updownarrow
\Upsilon \Vert \Xi \aleph \alpha \approx \ast \asymp \backslash \beta
\bigcap \bigcirc \bigcup \bigodot \bigoplus \bigotimes
\bigtriangledown \bigtriangleup \biguplus \bigvee \bigwedge \bot
\bullet \cap \cdot \chi \circ \clubsuit \coprod \cup \dag \dashv \ddag
\delta \diamond \diamondsuit \div \downarrow \ell \emptyset \epsilon
\equiv \eta \exists \flat \forall \frown \gamma \geq \gg \heartsuit
\imath \in \infty \int \iota \jmath \kappa \lambda \langle \lbrace
\lceil \leftangle \leftarrow \leftbrace \leftbracket \leftharpoondown
\leftharpoonup \leftparen \leftrightarrow \leq \lfloor \ll \mid \mp
\mu \nabla \natural \nearrow \neg \ni \nu \nwarrow \odot \oint \omega
\ominus \oplus \oslash \otimes \phi \pi \pm \prec \preceq \prime \prod
\propto \psi \rangle \rbrace \rceil \rfloor \rho \rightangle
\rightarrow \rightbrace \rightbracket \rightharpoondown
\rightharpoonup \rightparen \searrow \sharp \sigma \sim \simeq \slash
\smile \spadesuit \sqcap \sqcup \sqrt \sqsubseteq \sqsupseteq \subset
\subseteq \succ \succeq \sum \supset \supseteq \swarrow \tau \theta
\times \top \triangleleft \triangleright \uparrow \updownarrow \uplus
\upsilon \varepsilon \varphi \varphi \varrho \varsigma \vartheta
\vdash \vee \wedge \wp \wr \xi \zeta

Vittorio Palmisano <re...@em...> writes:
> Hello,
> I have updated my debian packages for Matplotlib, and I put the installation
> instructions on my page: http://anakonda.altervista.org/
Hello Vittorio,
Thanks much for doing this. I am just now taking it for a test drive
on a debian machine I have access to.
Two (possibly related) things I found surprising were the install size
(21MB!) and an ATLAS dependency. I suspect the latter comes from a
scipy requirment, which matplotlib does not depend on.
humanos:~> sudo apt-get install python-matplotlib python-matplotlib-doc
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
 atlas2-base fonttools libart-2.0-2 libg2c0 libttf2 python-gdmodule
 python-pypaint python-ttfquery python2.3-numeric python2.3-numeric-ext
 python2.3-xml
The following NEW packages will be installed:
 atlas2-base fonttools libart-2.0-2 libg2c0 libttf2 python-gdmodule
 python-matplotlib python-matplotlib-doc python-pypaint python-ttfquery
 python2.3-numeric python2.3-numeric-ext python2.3-xml
0 packages upgraded, 13 newly installed, 0 to remove and 150 not upgraded.
2 packages not fully installed or removed.
Need to get 6099kB of archives. After unpacking 21.2MB will be used.
Do you want to continue? [Y/n] y
Is the ATLAS requirement intentional, or a vestigial dependency from
some other package in your collection?
Thanks again,
JDH

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
I have updated my debian packages for Matplotlib, and I put the installation
instructions on my page: http://anakonda.altervista.org/
These are the packages I've build:
python-gdmodule 0.52
python-matplotlib 0.50-1
python-matplotlib python-matplotlib-doc 0.50-1
python-pypaint 0.3
python-ttfquery 1.0.0a1
python-matplotlib-doc is a documentation package made with pydoc.
- --
/Vittorio Palmisano/
Home Page: http://redclay.altervista.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAOPj2pT6bvDtyXOIRAjTqAJ99uxVxbH//QG32f/xC+UCURBYyYACgilk+
bLZtzF0xGJIP0KmHiJiU1Nk=
=CqiV
-----END PGP SIGNATURE-----

John Hunter wrote:
 > By the way, you mentioned math type earlier. I think it would not be
 > too difficult to use freetype to write a poor-man's latex, handling
 > subscripts, superscripts and Greek characters. We'd have to locate a
 > free font that renders Greek characters - I don't know of any but
 > haven't looked extensively. Or we could require users who want this
 > feature to come up with the core set of Microsoft fonts and use the
 > symbol font. I suspect most have access of Windows fonts that they
 > could copy to their linux boxes, but I am not sure if this is kosher.
 > Anybody know of some decent free freetype symbol fonts?
See
AMS Fonts (Truetype)	
TTF versions of the American Mathematical Society Computer Modern fonts, 
aka the BaKoMa fonts by Boris Malyshev. The truetype versions of the AMS 
fonts are included in PCTeX.
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
 >> Alternatively, we could see which methods ttfquery requires of
 >> the ttLib.TTFont and engineer a handrolled TTFont which parses
 >> the relevant bits from the ttf files and provides these
 >> methods.
 Perry> I'll see if someone here can take a brief look at this
 Perry> approach (cutting all the wires to fonttools) to see if it
 Perry> is manageable.
I just checked a freetype2 wrapper module into CVS (and upgraded the
agg backend to work with it). The module is matplotlib.ft2font and
has no external dependencies other than the freetype2 library itself.
If someone in your group decides to take a look at cutting the wires
to fonttools, FT2Font can provide the information needed to replace
it. With a skeleton freetype2 wrapper, there is now no good reason to
parse ttf files ourselves. It is currently a minimalist wrapping,
exposing only what was needed to renderer rotated strings into a pixel
buffer for a given ttf file (the backend uses ttfquery to find the
font file and ft2font to render it).
It is easy to add new methods from the freetype2 API at
http://www.freetype.org/freetype2/docs/reference/ft2-index.html as
needed; eg, to expose the style_flags, family_name, style_name etc of
FT_FaceRec. If it looks like more work to mimic fonttools TTFont, we
can use these attributes to write our own font finder, borrowing from
the ttfquery stuff (eg, platform dirs, using the windows registry to
get system fonts) that does not require fonttools.
By the way, you mentioned math type earlier. I think it would not be
too difficult to use freetype to write a poor-man's latex, handling
subscripts, superscripts and Greek characters. We'd have to locate a
free font that renders Greek characters - I don't know of any but
haven't looked extensively. Or we could require users who want this
feature to come up with the core set of Microsoft fonts and use the
symbol font. I suspect most have access of Windows fonts that they
could copy to their linux boxes, but I am not sure if this is kosher.
Anybody know of some decent free freetype symbol fonts?
David, you can also use FT2Font to render to libart if you want -
check out _backend_agg.c and backend_agg.py for an example of how to
use the wrapper. You basically just need to add one method
"draw_text" to the image extension code, and make some minor changes
in backend_paint.py.
If you want to build agg from cvs, you will need to copy the agg2 dir
from the 0.50 src distribution into your cvs build tree. I haven't
decided yet how I want to handle the distribution of these
dependencies so I'm holding off on checking them into CVS.
JDH

What's new in matplotlib 0.50
Antigrain backend: Agg
 Adding to the growing list of image backends is Antigrain --
 http://antigrain.com. This is a backend written mostly in extension
 code and is the fastest of all the image backends. Agg supports
 freetype fonts, antialiased drawing, alpha blending, and much
 more. The windows installer contains everything you need except
 Numeric to use the agg backend out of the box; for other platforms
 see http://matplotlib.sourceforge.net/backends.html#Agg
Paint/libart backend
 David Moore wrote a backend for pypaint, a libart wrapper. libart is
 a high quality, cross platform image renderer that supports
 antialiased lines, freetype fonts, and other capabilities to soon be
 exploited. Thanks David! See
 http://matplotlib.sourceforge.net/backends.html#Paint for more
 information and install instructions
The Matplotlib FAQ
 Matplotlib now has a FAQ -- http://matplotlib.sourceforge.net/faq.html
Alpha channel attribute
 All the figure elements now have an alpha attribute to allow
 blending and translucency. Not all backends are currenly capable of
 supporting alpha - currently only Agg, but Paint should be able to
 support this soon - see the scatter screenshot for an example of
 alpha at work
 http://matplotlib.sourceforge.net/screenshots.html#scatter_demo2
Table class added
 John Gill has developed a very nice Table class and table function
 that plays well with bar charts and stacked bar charts. See example
 code and screenshot table_demo at
 http://matplotlib.sourceforge.net/screenshots.html#table_demo
New plot commands cla and clf
 Clear the current axes or figure. Useful in interactive plotting
 from a python shell
GD module on win32
 With much weeping and gnashing of teeth and help from half the
 people on this globe, built a gdmodule win32 installer. Special
 thanks to Stefan Kuzminski for putting up with my endless windows
 confusions. See the win32 quickstart at installing the GD backend -
 http://matplotlib.sourceforge.net/backends.html#GDWIN32
GD supports clipping and antialiased line drawing
 See instructions about upgrading gd and gdmodule at Installing the
 GD backend. The line object has a new 'antialiased' property, that
 if True, the backend will render the line antialiased if
 supported. Note antialiased drawing under GD is slow, so be sure to
 turn the property off set(lines, 'antialiased', False) if you
 experience performance problems. If you need performance and
 antialiasing, use the agg backend.
Wild and wonderful bar charts
 You can provide an optional argument bottom to the bar command to
 determine where the bottom of each bar is, default 0 for all. This
 enables stacked bar plots and candelstick plots --
 examples/bar_stacked.py. Thanks to David Moore and John Gill for
 suggestions and code.
Figure backend refactored
 The figure functionality was split into a backend independent
 component Figure and a backend dependent component
 FigureCanvasBase. This completes the transition to a totally
 abstract figure interface and improves the ability the switch
 backends and a figure to multiple backends. See API_CHANGES for
 information on migrating applications to the new API at
 http://matplotlib.sourceforge.net/API_CHANGES
Tons of bug fixes and optimizations detailed at
http://matplotlib.sourceforge.net/whats_new.html

>>>>> "John" == John Hunter <jdh...@ac...> writes:
 John> * clipping appears broken: arctest.py, legend_demo.py, and
 John> so on. This used to work, right?
 John> * dotted lines are solid: see any plot with grid(True),
 John> eg, log_test.py. Ditto for dashed lines: eg, plot(t3,
 John> cos(2*pi*t3), 'r--') appears solid.
Both of these problems are arising from the select / unselect thing in
the GC. Since these changes were in response to the double gc problem
which no longer exists, I'm simply going to 'pass' in select and
unselect for the next release (which fixes both problems) above.
backend wx now passes all the tests, except the known issues.
I also added some more of the dpi scaling functionality to wx
(linewidth and markersize via the new renderer method
points_to_pixels). The last remaining area is dash size which is more
difficult since wx uses a constant for dash drawing rather than an ink
on/off approach. Does wx also support on/off? If I recall correctly,
you experimented with this but had a hard time getting it working right.
In any case the high res (eg dpi=300) wx output looks great.
There also seems to be an issue with getting the text bounding box
right with fontangles and fontweights that are not standard. To
experiment with this, uncomment 'if 0' on or around line 416 is
axis.py and run text_handles.py or text_themes.py. This will draw the
bbox around you text instance.
JDH

pypaint 0.3
-----------------
This module provides a light Python wrapper for libart written in C. It
allows you to create static images quickly. pypaint runs on both Linux and
Windows.
It only provides basic functionality at the moment - line drawing,
rectangles, polygons, arcs, fill, and simple font support (using freetype
1). The images are output in PNG format.
There will be support for a pypaint backend in the next release of
matplotlib.
pypaint is available at http://sourceforge.net/projects/pypaint. In
future, there will be a homepage up at http://pypaint.sourceforge.net
David Moore
Software Consultant
St. James Software
Phone: +27 21 424 3492
e-mail: da...@sj...
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.580 / Virus Database: 367 - Release Date: 2004年02月06日

>>>>> "David" == David Moore <da...@sj...> writes:
 David> Sorry, last email wasn't to the list. From posts you've
 David> made, it looks like you've made some changes to pypaint.
 David> Do you want those committed before a pypaint release?
 David> Apart from that, I'm just tying up some loose ends, and
 David> then I'll be able to make the release - hopefully today,
 David> but maybe only Monday if you want your changes added.
I don't have anything to add. I tried to get clipping working but
didn't succeed. I think there are two problems
 1) libart wants to paths to be counter clockwise for clipping to work
 (at least that's what I was told on the libart list), and I don't
 think all the path constructors insure this, eg draw_arc.
 2) even when the paths are constructed properly, I think there is a
 problem in libart that causes clipping artifacts.
So I think you'll be fine going with what you've got for now. It
would be great to get clipping worked out in the long run, but I don't
see any immediate solutions.
On the font front: as I mentioned earlier, I ported font.c to agg and
it's working. For high resolution images it works great. For small
images (eg, dpi=60) the fonts look pretty bad. I think this is the
same for paint and agg, at least in the comparisons I've looked at.
This isn't surprising since the font code is the same. The two areas
where small rasters come up are for web pages (which is where I assume
your interests are) and embedding in GUI applications (which is
important to me).
Is this why you want to upgrade to freetype2? From my reading of some
of the docs there, this is one thing that freetype2 does better.
JDH

On Saturday 14 February 2004 8:03 am, you wrote:
> Thanks for the pointers.
>
> On Friday 13 February 2004 9:20 pm, you wrote:
> > I made some progress!
>
> [snup]
>
> > The bug was a line I introduced when I added some more print
> > debugs
>
> I had fixed this one...
>
> > The front end change that is causing your problems is that I now pass
> > a gcedge and a gcface. I used to pass a gcface and a face color.
> > Maybe I'll revert to that.
> >
> > When I instantiate a gcedge and a gcface on the front end, you make 2
> > calls to new_gc
> >
> > def new_gc(self):
> > """
> > Return an instance of a GraphicsContextWx, and sets the current
> > gc copy """
> > DEBUG_MSG('new_gc()', 2, self)
> > self.gc = GraphicsContextWx(self.bitmap, self)
> > assert self.gc.Ok(), "wxMemoryDC not OK to use"
> > return self.gc
> >
> > I think initing 2 GCs with the same bitmap is causing the problem. If
> > you see an easy backend solution, that would be ideal. If not, I
> > could re-refactor the frontend to be like it was: pass a gcedge and a
> > facecolor.
>
> This is, indeed, illegal in wx. It sometimes works under Windows, but
> consistently fails (dramatically) under Linux (at least for wxGtk).
To be more exact about what happens, here is the synopsis:
In patches.py, Patch._draw() instantiates two gc instances
 def _draw(self, renderer, *args, **kwargs):
#here=============>
 gc = renderer.new_gc() 
 gc.set_foreground(self._edgecolor)
 gc.set_linewidth(self._linewidth)
 gc.set_alpha(self._alpha)
 if self._clipOn:
 gc.set_clip_rectangle(self.bbox.get_bounds())
 if not self.fill: gcFace = None
 else:
#and here===========>
 gcFace = renderer.new_gc() 
 gcFace.set_foreground(self._facecolor)
 gcFace.set_alpha(self._alpha)
 self._derived_draw(renderer, gc, gcFace)
Each call to backend_wx.py RendererWx.new_gc() does the following:
 self.gc = GraphicsContextWx(self.bitmap, self)
 assert self.gc.Ok(), "wxMemoryDC not OK to use"
 return self.gc
But instantiating a GraphicsContextWx does:
 def __init__(self, bitmap, renderer):
 GraphicsContextBase.__init__(self)
 wxMemoryDC.__init__(self)
 DEBUG_MSG("__init__()", 1, self)
 # Make sure (belt and braces!) that existing wxDC is not selected to
 # to a bitmap.
 if GraphicsContextWx._lastWxDC != None:
#the gcEdge gets selected into a NULL bitmap here
 GraphicsContextWx._lastWxDC.SelectObject(wxNullBitmap)
 self.SelectObject(bitmap)
 self.SetPen(wxPen('BLACK', 1, wxSOLID))
 self._style = wxSOLID
 self.renderer = renderer 
 GraphicsContextWx._lastWxDC = self
You will note that in order to enforce the wx rule that no more than one 
wxMemoryDC can be selected into a bitmap, I ensure that the last wxMemoryDC 
instance activated is selected to a wxNullBitmap.
In the case of the above code, this means that the gc representing the 
rectangle has already been selected to a NULL bitmap. When you try to draw to 
this, an exception is generated within the C++ code which is not propagated 
back up to the Python layer. Unfortunately, the assert() calls don't help 
much here as each gc instance is OK when it is constructed.
I'm afraid I'd missed the significance of the change from a facecolor to a 
gcFace for fill colours.
> I'll see if I can come up with any ideas, but passing a gcedge and
> facecolor is likely to be simpler to get to work reliably.
I have thought about this, and to only other option I can think of is for me 
to select between 'currently active' gc instances as required. Obviously, 
this would probably slow backend_wx down, but I'm not yet sure what the 
performance hit will be. Let me try it...
[an hour or so later...]
Attached is a backend_wx which seems to work with most of the examples I've 
tried (Linux only - expect Windows to work as it's generally better behaved 
than wxGtk, but would be nice if someone would try it.
Some issues (for now):
- Clipping seems to be broken (c.f. arctest.py)
- Object picker demo doesn't work (haven't implemented this functionality)
- Some types of dotted lines are not working properly (c.f. subplot_demo.py)
- embedding_in_wx doesn't work - due to some of the recent API changes. I'll 
fix this one pretty soon - it shouldn't be much work.
- It's about 20% slower than the previous implementation in which only one GC 
was active at a time.
Not sure if the dotted lines and clipping are down to information being lost 
when I switch between gcs - I'll have to look into this, but the attached 
will be a good start for getting things to work on wx again.
John, I'll leave it as your call whether you want to switch the API back to 
using a facecolor instead of a gcFace. It would be better from the wx 
perspective, but there may be good reasons for doing otherwise on other 
backends. 
There are a couple of optimisations I can probably make to speed things a 
little if we stick with the current API -it should be possible to do 
something slightly more intelligent than simply selecting a bitmap at the 
start of each call, and deselecting it afterwards - although, as noted above, 
wxMemoryDC seems to be extremely fragile under wxGtk - not sure why.
I have checked the attached into CVS for now, but we may have the usual 
'mirror update' issue.
Regards
Jeremy

>>>>> "Vittorio" == Vittorio Palmisano <re...@em...> writes:
 Vittorio> I have rebuild the package with support for gtkgd. I
 Vittorio> have tried to build also the agg backend, but I can't
 Vittorio> find the source package for this library! I've found two
 Vittorio> version: one from http://antigrain.com and another from
 Vittorio> scipy cvs, but seems that there are some missing headers
 Vittorio> when I compile the backend. I have also packaged the
 Vittorio> gdmodule from
 Vittorio> http://newcenturycomputers.net/projects/gdmodule.html
 Vittorio> and the ttfquery module from
 Vittorio> http://sourceforge.net/projects/ttfquery/, all the debs
 Vittorio> are on http://anakonda.altervista.org/debian/
Wow, amazing work. 
You may want to look at the header of matplotlib.backends.backend_agg
- this includes some install instructions, where to get agg, etc...
However, that may not be necessary.
I have built a new sdist that has all the prereqs for agg built in
(fonttools, ttfquery, and agg2). You just have to set BUILD_AGG in
setup.py and it should build, as long as your compiler is fairly
recent. I'll leave it to you whether you want to use debian to get
fontools and ttfquery, or use the ones included with matplotlib. I
stripped all the fluff out of those 3 packages and with everything
included the sdist is still under a megabyte.
 http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.50p.tar.gz
I used this to build an all-in-one win32 installer, which will be nice
because now win32 users with Numeric can make PS and PNG plots out of
the box (zlib, libpng, freetype are statically built in).
I'm going to upload the snapshot if you want to experiment with it. I
should warn you though: I forgot yesterday that there is still a
critical bug in wx that must be repaired. Thus there will be one more
revision following this one. (Sorry)
JDH

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John Hunter ha scritto:
>
> I have a couple of favors to ask of you. The 0.50e release on the web
> site that you built against was an alpha release of the 0.50 series
> and a fair number of features, optimizations and bug fixes have been
> added since then. The current snapshot has been well tested and is in
> good shape - would you be willing to build the package one more time
> against it?
>
> http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.50m.tar.gz
>
> Now a couple of questions. I need to update the debian section of the
> web site. Could you write something explaining how a relatively
> novice debian user would go about getting python-matplotlib? Ie, what
> would they need to put in /etc/apt/sources.list, what commands would
> they need to issue from the shell, which of the backends are
> installed, etc... How do you handle the various backends, eg, gd, wx,
> pygtk and so on.
>
> Just to give you an idea of how much has changed since the 0.50e alpha
> release, in addition to the aforementioned bugs and optimizations,
> there are 2 new backends (paint and agg), a new Table class, and a new
> matlab function table to interface to it, and several examples. Note
> if you do rebuild, there is a src dir you'll want to include.
>
I have rebuild the package with support for gtkgd.
I have tried to build also the agg backend, but I can't find the source package
for this library! I've found two version: one from http://antigrain.com and
another from scipy cvs, but seems that there are some missing headers when I
compile the backend.
I have also packaged the gdmodule from
http://newcenturycomputers.net/projects/gdmodule.html and the ttfquery module
from http://sourceforge.net/projects/ttfquery/, all the debs are on
http://anakonda.altervista.org/debian/
I can write some documentation about debian packages required, once I've tested
them, but only for the next weekend, bye
- --
/Vittorio Palmisano/
Home Page: http://redclay.altervista.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFALOhdpT6bvDtyXOIRAiQGAKDDQCrh0sELN09vI2dKYVfTKZ9H4ACgr8o2
ezklwMSi/Ke3zY5kK8DWwsI=
=SX+C
-----END PGP SIGNATURE-----

Almost all of the backends (save postscript) either support freetype
or are capable or supporting it. We need a good cross-platform
freetype font finder package. Right now, we have fonttools and
TTFQuery, which get the job done. But they bring a lot of extra
installation overhead.
For the postscript backend, I wrote a standalone AFM parser which has
worked well - the alternative was to require fonttools, which is
larger than all of matplotlib combined. I would like to have the same
for TTF files - a small, free standing module with no extrinsic
dependencies that we can ship with matplotlib.
A introduction to the ttf specification can be found here
http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter08.
We don't need much out of these files: things like character sizes,
kerning distances, etc, are already handled by the freetype extension
modules, eg, paint.font (which I also used for agg). 
What we need is for someone to identify the relevant *.ttf dirs on the
major platforms (you can extract most of this information from
TTFQuery), and parse enough of the ttf file to get family name, font
style, weight, etc.... You could either pull out the relevant bits
from fonttools and ttfquery or just roll your own. Ideally, you
should be able to take a matplotlib.text.Text instance and returns the
ttf file which is the closest match for you on your system, falling
back on Vera (which ships with matplotlib) as the default.
I notice on
http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter08#3054f18b
there is a field for "Postscript name for the font" which would be
nice to incorporate for backend switching (saving PS from GTK,
etc...).
Anyway, it would be a very useful addition to matplotlib, and would
speed the process of standardizing fonts across the backends.
JDH

Attached is a new version of backend_ps.py with two new functions,
landscape() and portrait().
Someone who actually understands post-script should check these fixes
out -- I know next to nothing about it, but the fixes seem to do the
trick, although I'm sure there is some other incantation I'm supposed to
put in the postscript so that viewers realise it is landscape and show
it that way.
Also attached is a new version of axis.py with a very minor mod to
format_tickval that ensures that the plot doesn't end up with labels
like: 199999999 in the case where the tickloc is just a shade under a
whole number.
John
On Tue, 2004年02月10日 at 15:05, John Hunter wrote: 
> >>>>> "John" == John Gill <jn...@eu...> writes:
> 
> John> I have some plots I'd like to print out and they would make
> John> better use of the paper if they were done landscape.
> 
> John> Can the postscript backend do this?
> 
> Hi John,
> 
> I haven't had time to take a close look at this. My initial
> suggestions is to experiment with the paper size
> 
> import matplotlib
> matplotlib.use('PS')
> import matplotlib.backends.backend_ps as backend_ps
> backend_ps.defaultPaperSize = 11,8.5 # default is 8.5, 11
> 
> You may also have to specify a landscape portrait at print time, or
> rotate it.
> 
> I'll take a closer look later.
> 
> JDH
> 

>
> On the topic of releases: David, my target date is early next week.
> Do you think you can get pypaint up by then?
>
> Thanks again,
> JDH
>
Hi John,
Sorry, last email wasn't to the list. From posts you've made, it looks like
you've made some changes to pypaint. Do you want those committed before a
pypaint release? Apart from that, I'm just tying up some loose ends, and
then I'll be able to make the release - hopefully today, but maybe only
Monday if you want your changes added.
thanks,
David Moore
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.580 / Virus Database: 367 - Release Date: 2004年02月06日

>>>>> "Vittorio" == Vittorio Palmisano <re...@em...> writes:
 Vittorio> Ok, I have fixed this problems, now "lintian -i
 Vittorio> python-matplotlib_0.50-1_i386.changes" doesn't say
 Vittorio> nothing. I have updated the files on my repository, bye
Hi Vittorio, thanks a bunch for doing this. A lot of people have
asked for this, and there's been incremental progress here and there,
but I'm glad to see you got everything done.
I have a couple of favors to ask of you. The 0.50e release on the web
site that you built against was an alpha release of the 0.50 series
and a fair number of features, optimizations and bug fixes have been
added since then. The current snapshot has been well tested and is in
good shape - would you be willing to build the package one more time
against it?
 http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.50m.tar.gz
Now a couple of questions. I need to update the debian section of the
web site. Could you write something explaining how a relatively
novice debian user would go about getting python-matplotlib? Ie, what
would they need to put in /etc/apt/sources.list, what commands would
they need to issue from the shell, which of the backends are
installed, etc... How do you handle the various backends, eg, gd, wx,
pygtk and so on.
Just to give you an idea of how much has changed since the 0.50e alpha
release, in addition to the aforementioned bugs and optimizations,
there are 2 new backends (paint and agg), a new Table class, and a new
matlab function table to interface to it, and several examples. Note
if you do rebuild, there is a src dir you'll want to include.
On the topic of releases: David, my target date is early next week.
Do you think you can get pypaint up by then? 
Thanks again,
JDH

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jochen Voss ha scritto:
> Hi Vittorio,
>
>
> Thank you for the package. I had a short look at it.
> Some comments:
>
> 1) Somehow the python-matplotlib-0.50/build directory sneaked
> into your diff file. You should remove it from your sources
> and rebuilt your package.
>
> 2) You should check your package with lintian.
> Calling "lintian -i python-matplotlib_0.50-1_i386.changes"
> gives a lot of useful hints.
>
> I hope this helps,
> Jochen
Ok, I have fixed this problems, now "lintian -i
python-matplotlib_0.50-1_i386.changes" doesn't say nothing.
I have updated the files on my repository, bye
- --
/Vittorio Palmisano/
Home Page: http://redclay.altervista.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFALBMapT6bvDtyXOIRAotMAKCKjRsSkEqW1+ZghHsbPTPSkxiK5gCfcse1
nTVo7VRSpn42CrynvFDGNKY=
=yfL1
-----END PGP SIGNATURE-----

Hi Vittorio,
On Thu, Feb 12, 2004 at 11:14:19PM +0100, Vittorio Palmisano wrote:
> I've made a Debian package for matplotlib and I've put it at:
> http://anakonda.altervista.org/debian/
Thank you for the package. I had a short look at it.
Some comments:
1) Somehow the python-matplotlib-0.50/build directory sneaked
 into your diff file. You should remove it from your sources
 and rebuilt your package.
2) You should check your package with lintian.
 Calling "lintian -i python-matplotlib_0.50-1_i386.changes"
 gives a lot of useful hints.
I hope this helps,
Jochen
--=20
http://seehuhn.de/

Hello,
I've made a Debian package for matplotlib and I've put it at:
http://anakonda.altervista.org/debian/
I've read some specification for dependencies from http://bugs.debian.org/206691,
this is my first package and so there are some (many?) things to fix.
I think that the package may also include the api documentation generated with pydoc.
-- 
/Vittorio Palmisano/
Home Page: http://redclay.altervista.org

On Tue, 2004年02月10日 at 16:30, John Hunter wrote:
> I just made a minor change in the backend API. The faceColor argument
> (formerly a color arg) for draw_rectangle, draw_arc, etc... is now a
> graphics context instance. I updated all the backends in CVS. 
> 
Hi John,
I'm working with Perry Greenfield's group on a Tkinter/Paint backend for
matplotlib. I noticed today that the paint facecolor had changed to
black. Looking into it, there were a few more edits to
backend_paint.py needed as a result of the interface change above. I
also noticed that the paint version of draw_polygons needed a little
code to get it working. Attached is a patch for both.
Regards,
Todd
-- 
Todd Miller <jm...@st...>

The agg backend
 Features that are implemented
 * capstyles and join styles
 * dashes
 * linewidth 
 * lines, rectangles, ellipses, polygons
 * clipping to a rectangle
 * output to RGBA and PNG
 * alpha blending
 * DPI scaling - (dashes, linewidths, fontsizes, etc)
 * freetype1
 TODO:
 * use ttf manager to get font - right now I just use Vera
 INSTALLING 
 Grab the latest matplotlib from
 http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.50l.tar.gz
 REQUIREMENTs
 python2.2+
 Numeric 22+
 agg2 (see below)
 freetype 1
 libpng
 libz ?
 
 Install AGG2 (cut and paste below into xterm should work)
 wget http://www.antigrain.com/agg2.tar.gz
 tar xvfz agg2.tar.gz
 cd agg2
 make
 (Optional) if you want to make the examples:
 cd examples/X11
 make
 Installing backend_agg
 Edit setup.py: change aggsrc to point to the agg2 src tree and
 replace if 0: with if 1: in the backend_agg section
 Then just do the usual thing: python setup.py build
 Please let me know if you encounter build problems, and tell me
 platform, gcc version, etc... Currently the paths in setupext.py
 assume as linux like filesystem (eg X11 include dir, location of
 libttf, etcc) so you may need to tweak these. 
 Using agg backend
 python somefile.py -dAgg 
 or
 import matplotlib
 matplotlib.use('Agg')
 
Let me know how it works out! Note also that backend agg is the first
backend to support alpha blending; see scatter_demo2.py.
JDH

John,
Thanks for all the fixes. Having data_table as matplotlib.matlab.table
is good + also on the axes.
I've attached my latest demo script -- was in the process of trying to
simplify the example for you, but have been a bit busy the last couple
of days.
I split the colour generating stuff into colours.py -- might be useful
to have this sort of thing available somewhere in matplotlib.
Re: the numbers in the table not matching up in the demo. The numbers I
put in the table are the total height of the columns, not just the
incremental heights (the place where I use these things are to show loss
statistics at different return periods + the users want to see the full
numbers not the incremental stuff). I've just re-read this para and it
is about as clear as mud, so yell if it isn't making sense alongside the
picture.
John
On Wed, 2004年02月11日 at 19:07, John Hunter wrote:
> >>>>> "John" == John Gill <jn...@eu...> writes:
> 
> >> If I could impose on you one more time. I would like to add a
> >> table screenshot to the web page. Something along the lines of
> >> the first table example you sent (with the stacked bar chart)
> >> but using data_table to build the table. The code should be as
> >> simple as possible since we want to emphasize the ease of use.
> >> Do you have some data you can use to make a table that can be
> >> displayed on the web? I have a data dir in the examples dir
> >> that I use to distribute data.
> 
> In anticipation of the 0.50 release, I did some reorganization of the
> table code to make it more consistent with other matplotlib commands.
> Eg,, data_table is now an axes function axes.table and at
> matplotlib.matlab command "table".
> 
> 
> 
> ______________________________________________________________________
> 
> I tried to adapt your various examples into a single demo using the
> new table command. It works ok, but the numbers in the table don't
> seem to always correspond to the respective sizes of the table. I
> don't fully have my head around the example - perhaps you can advise?
> 
> 
> 
> ______________________________________________________________________
> 
> Thanks!
> 
> JDH

On Tuesday 10 February 2004 9:30 pm, John Hunter wrote:
> Unfortunately Jeremy, there now appears to be a bug in wx. I can't
> tell if it was something I did or something that was there already,
> because with wx swallowing the exceptions, I can't find it! I also
> added a few more debug print messages to functions that don't have
> them already, but still couldn't track it down. Sorry for the
> trouble.
I have found the location of the error, but have not yet determined how the 
problem arises:
Basically, when savefig() is called by the script, the first draw_rectangle() 
call fails an assert gc.OK() statement. I have not determined why Python is 
not receiving the AssertException - my conjecture is that the call to gc.Ok() 
is causing an exception in the C++ code - I will probably have to use a debug 
version of the wx libraries and a debugger to verify this.
The stack frame when the exception is raised is:
__main__ #40
matplotlib.matlab.savefig #798
matplotlib.backends.backend_wx #812
matplotlib.artist.draw #86
matplotlib.figure._draw #65
matplotlib.artist.draw #86
matplotlib.patches._draw #76
matplotlib.patches._derived_draw #154
matplotlib.backends.backend_wx #403
I'll let you know how I get on...
Jeremy