matplotlib-devel Mailing List for matplotlib (Page 550)

Hi John,
I have some proposed changes to the way matplotlib handles fonts. The suggested 
changes are along the lines of the W3C Cascading Style Sheet, Level 1 (CSS1; 
http://www.w3.org/TR/1999/REC-CSS1-19990111) document. Note that there is also 
a Level 2 and 2.1 document.
For fonts, HTML/XML documents can specify 5 font properties for font matching 
purposes. They are: font-family, font-style, font-variant, font-weight, and 
font-size. The font_family property is a list of prioritized font names. The 
nicer fonts are listed first, e.g. ['Lucida Grande', Verdana, Geneva, Lucida, 
Arial, Helvetica, sans-serif]. The first font name is apparently a very elegent 
sans-serif font that is common on Mac OS X. Verdana is common to Windows and 
Helvetica is common on UNIX/Linux. font-style can be normal, italic, or 
oblique; font-variant is normal or small-caps; font-weight has many options, 
e.g. normal, semi-bold, bold, etc.; and font-size also has many options, e.g. 
small, medium, large, smaller, larger, 10pt, 12pt, etc. The CSS1 document also 
gives a font matching algorithm in case your system doesn't have the exact font 
available.
The Text object in matplotlib has several similar attributes to the CSS1 font 
properties, so it would seem that you were aware of this approach. They are 
fontname, fontangle, fontweight, and fontsize. Given the similarities, my 
suggestion is to replace fontname with fontfamily and allow it to be a list of 
prioritized fonts. I also suggest replacing fontangle with fontstyle, adding 
fontvariant, and using the CSS1 options for these attributes.
The fontfamily approach makes it more likely that the more elegant fonts will be 
used by matplotlib and that if none of the recommended fonts are available, at 
least some font closely resembling the requested one will be used, i.e. some 
type of sans-serif font will be used if requested, instead of a serif font.
The CSS1 options for font weights are: [normal=400, bold=700, 100, 200, 300, 
400, 500, 600, 700, 800, 900, bolder, and lighter]. The latter two are relative 
values. It appears that newer fonts will use these numerical values to indicate 
their font weight, instead of using a descriptive names which are not uniform 
across font foundries.
Like the CSS1 options for font weight, the size options are: [xx-small, x-small, 
small, medium, large, x-large, xx-large, smaller, larger], plus point sizes. 
One of the benefits of using a name option for size is that the sizes are all 
relative to the medium size, which can be 10pt, 12pt, 14pt, etc. This would 
make it easy to change all the fonts in a plot just by changing the definition 
of the medium font from 12pt to 14pt.
As a final suggestion, we could have the Text object initialize the fontfamily 
attribute to a sans-serif font list, e.g. the one given above, since that seems 
to be a popular font family for many users.
Please let me know what you think about this suggestion and if you have any 
changes to the design.
 -- 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:
 
 Perry> Todd and I just talked about this. There are two possible
 Perry> approaches, one of which should work and the other which we
 Perry> would have to think about. The simpler approach is to write
 Perry> a C extension using the Numeric API. As long as a small,
 Perry> rarely-used, subset of the Numeric API is not used (the
 Perry> UFunc API and some type conversion stuff in the type
 Perry> descriptor) 
OK, I'll start with plain vanilla Numeric along the lines Todd sent me
earlier, and we can do the (apparently straightforward)
numarray/numeric port when we have a prototype.
 Perry> I agree that this is the drawback. On the other hand,
 Perry> processor memory has grown much faster than image display
 Perry> memory. With a full screen image of 1024x1280 pixels, we
 Perry> are only talking about 5MB or so for a 32-bit deep
 Perry> display. Converting rgba all to floats means 20MB, while
 Perry> large is not overwhelming these days, and that is the worst
 Perry> case for interactive cases. I suppose it would be a bigger
 Perry> concern for non-interactive situations (e.g. PDF). But it
 Perry> would seem that in doing this simpler approach, we would
 Perry> have something that works sooner, and then we could think
 Perry> about how to handle cases where someone wants to generate a
 Perry> 4Kx4K PDF image (which is going to be one big PDF
 Perry> file!). I'd let's not let extreme cases like this drive the
 Perry> first implementation.
Agreed. If noone has any objections I think I'll start with rgba32 as
the common rendering format for the image module and we can special
case the smaller (grayscale UInt8 or UInt16) and larger (rgba floats)
cases after a prototype implementation.
I'm imagining an interface like
Frontend:
 im = image.fromarray(A) # NxM 
 im = image.fromarray(A, colormap) # NxM colormapped images
 im = image.fromarray(A) # NxMx3, no format needed
 im = image.fromarray(A) # NxMx4, no format needed
 im = image.fromfile('somefile.png')
 im.set_interpolate(image.BILINEAR)
 im.set_aspect_ratio(image.CONSTRAINED)
Backend:
 
 def draw_image(im):
 # Ascaled is width x height x 4 resampled using interpolation
 # and aspect constraints from above
 Ascaled = im.resize(viewport.width, viewport.height)
 renderer.draw_from_rgba(Ascaled, etc1, etc2)
 Perry> Well, I was just referring to the image file support that
 Perry> PIL supplies; the rest of PIL seems mostly redundant with
 Perry> matplotlib and array capabilities (if I remember right, I
 Perry> haven't really used PIL much). How much image file format
 Perry> support is built into agg?
Almost none, except for the raw (or almost raw) image types (ppm,
bmp). PNG, I have more or less figured out; borrowing the read/write
capabilities for other image format from PIL is a good idea.
JDH

John Gill writes:
> Any other thoughts welcome...
>
> Not really related to images but...=20
>
> I've been thinking a bit about mapplotlib (no, that is not a typo).
>=20
> Quite often I find myself with numbers for different parts of the =
world=20
> that I want to map, shading regions different colours according to the =
> numbers.
>
> In fact, one of my early experiments with python and wxPython was to=20
> produce such a beast, but I'm not terribly happy with what I produced.
>
> matplotlib has lots of the goodies that mapplotlib would require: it =
has=20
> axes you can zoom and scroll, is great a drawing coloured polygons and =
can=20
> do legends.
>
> The problem I've tended to run into with mapping projects has been =
getting=20
> shape files that aren't distributed under a restrictive licence.
>=20
> Anyway, is there any interest out there in a mapplotlib?
>
> John=20
Well, sort of though on our part the interest is more in plotting
things on a map of the sky than the Earth (though occasionally, we
need to do that also). For us the biggest issue is handling all
the possible map coordinate projections. I would assume that is
also something you would have to worry about. We've given some
thought about how to do that sort of thing (as well as do thing
like polar plots). This would be a generalization of the matplotlib
transform mechanism. It isn't a real high priority for us yet.
The image stuff that John is talking about is much higher priority.
But if you have any thoughts of expanding on matplotlib for this
and are planning to use something other than simple rectangular
coordinates, I'd be interested in understanding how you will handle
map projections.
Perry

> > > Andrew> 2) It's pretty clear that a lot of the TkAgg stuff was
> > > Andrew> taken directly out of PIL. 
> 
> This was news to me, but Perry confirmed it.
> 
By the way, I'd like to thank Andrew Straw for pointing this out.
I originally looked at how PIL handled blitting images to Tkinter
as a possible way of doing it for Chaco/Kiva, and it seemed to
work fine. But it didn't get used for Chaco/Kiva so it sat there
a while (and the license issue "to-do" faded from my memory)
until it I realized that it could be used for matplotlib/Tk/agg
when I gave it to Todd to use. By then I forgot to mention that
it was taken from PIL so I'm glad you noticed that.
Perry 

>
> Hi Perry,
> You may not be aware that, although not officially supported, Lundh
> provided the following sample code (which I have used successfully to read
> bmp files and do fft's on them) for converting PIL to/from Numeric arrays
> via strings. It is quite fast. I think I probably found it in an email
> archive,
> Gary Ruben
>
Thanks for showing the code. I guess what I was referring to was
that native support by PIL would eliminate unnecessary memory copies
which occur when fromstring and tostring are used. But as I argue
in a previous message, I'm not currently worried that much about
that, but it seems that it would be nice if it weren't necessary
to go through that copying (from PIL image to string to array
rather than directly from PIL image to array)
[And I *meant* to check the spelling of Fredrik's name; I have a hard
time remembering the correct spelling :-) ]
Perry

John Hunter writes:
> Sorry for the confusion. I meant that I was considering using
> antigrain to load/store/scale/convert/process the pixel buffers in an
> image module in the same way that PIL could be used, and that this has
> nothing per se to do with backend_agg. By "backends", I meant the
> same old backends we already have, backend_gd, backend_wx, backend_ps,
> etc..., each of which would implement a new method draw_image to
> render the image object to its respective canvases/displays. Whether
> this image object is PIL based or Agg based under the hood is an open
> question.
> 
> I hope I this clarifies rather than muddies the waters....
> 
OK, I understand what you meant.
> Perry> But initially, reading images into arrays seems like the
> Perry> most flexible and straightforward thing to do.
> 
> Agreed - I like the idea of making the user deal with endianess, etc,
> in loading the image data into arrays, and passing those to image
> module. Todd, is it reasonably straightforward to write extension
> code that is Numeric/numarray neutral for rank 2 and rank 3 arrays?
>
Todd and I just talked about this. There are two possible approaches,
one of which should work and the other which we would have to think
about. The simpler approach is to write a C extension using the
Numeric API. As long as a small, rarely-used, subset of the Numeric
API is not used (the UFunc API and some type conversion stuff
in the type descriptor) then numarray can use the same code with
only a change to the include file (which could be handled by an
#ifdef) Then the same C extension code could be use with either
Numeric or numarray. The catch is that it must be compiled to be
used with one or the other. I was thinking that the way around that
would be to do 2 things: have setup.py build for Numeric, numarray,
*or* both depending on what it found installed on the system. The
respective C extension modules would have different names (e.g.,
_image_Numeric.so/dll or _image_numarray.so/dll). There would also
be a wrapper module that uses numerix to determine which of these
C extensions to import. This is a bit clumsy (having to layer a 
module over it a la numerix, but it means only having one C source
file to handle both.
It might be possible for us to fiddle with numarray's structure 
definition so that the same compiled C code works with Numeric
and numarray arrays, but given that the API functions will generate
one or the other for creation, I'm not sure this is workable.
We will give it some thought.
My inclination is to use the first approach as a conservative but
workable solution.
> Perry> These arrays are passed to matplotlib rendering methods or
> Perry> functions and the dimensionality will tell the rendering
> Perry> engine how to interpret it. The question is how much the
> Perry> engine needs to know about the depth and representation of
> Perry> the display buffer and how much of these details are
> Perry> handled by agg (or other backends)
> 
> One thing that the rest of matplotlib tries to do is insulate as much
> complexity from the backends as possible. For example, the backends
> only know one coordinate system (display) and the various figure
> objects transform themselves before requesting, for example,
> draw_lines or draw_text. Likewise, the backends don't know about
> Line2D objects or Rectangle objects; the only know how to draw a line
> from x1, y1 to x2, y2, etc...
> 
> This suggests doing as much work as possible in the image module
> itself. For example, if the image module converted all image data to
> an RGBA array of floats, this would be totally general and the
> backends would only have to worry about one thing vis-a-vis images:
> dumping rgba floats to the canvas. Nothing about byte-order, RGB
> versus BGR, grayscale, colormaps and so on. Most or all of these
> things could be supported in the image module: the image module scales
> the image, handles the interpolation, and converts all pixel formats
> to an array of rgba floats. Then the backend takes over and renders.
> An array of RGBA UInt16s would probably suffice for just about
> everything, however.
> 
> The obvious potential downside here is performance and memory. You
> might be in a situation where the user passes in UInt8, the image
> module converts to floats, and the backend converts back to UInt8 to
> pass to display. Those of you who deal with image data a lot: to what
> extent is this a big concern? My first reaction is that on a
> reasonably modern PC, even largish images could be handled with
> reasonable speed.
> 
I agree that this is the drawback. On the other hand, processor 
memory has grown much faster than image display memory. With
a full screen image of 1024x1280 pixels, we are only talking about
5MB or so for a 32-bit deep display. Converting rgba all to floats
means 20MB, while large is not overwhelming these days, and that is
the worst case for interactive cases. I suppose it would be a bigger
concern for non-interactive situations (e.g. PDF). But it would seem
that in doing this simpler approach, we would have something that
works sooner, and then we could think about how to handle cases where
someone wants to generate a 4Kx4K PDF image (which is going to be
one big PDF file!). I'd let's not let extreme cases like this 
drive the first implementation.
> On the subject of PIL versus agg for the workhorse under the image
> module hood: I agree with the positive points things about PIL that
> you and Andrew brought up (stability, portability, wide user base,
> relevant functionality already implemented). In favor of agg I would
> add
> 
Well, I was just referring to the image file support that PIL supplies;
the rest of PIL seems mostly redundant with matplotlib and array
capabilities (if I remember right, I haven't really used PIL much).
How much image file format support is built into agg?
Perry 

Hi Perry,
You may not be aware that, although not officially supported, Lundh
provided the following sample code (which I have used successfully to read
bmp files and do fft's on them) for converting PIL to/from Numeric arrays
via strings. It is quite fast. I think I probably found it in an email
archive,
Gary Ruben
-PilConvert.py-
#
# convert between numarrayal arrays and PIL image memories
#
# fredrik lundh, october 1998
#
# fr...@py...
# http://www.pythonware.com
#
import numarray
import Image
def image2array(im):
 if im.mode not in ("L", "F"):
 raise ValueError, "can only convert single-layer images"
 if im.mode == "L":
 a = numarray.fromstring(im.tostring(), numarray.UInt8)
 else:
 a = numarray.fromstring(im.tostring(), numarray.Float32)
 a.shape = im.size[1], im.size[0]
 return a
def array2image(a):
 if a.typecode() == numarray.UInt8:
 mode = "L"
 elif a.typecode() == numarray.Float32:
 mode = "F"
 else:
 raise ValueError, "unsupported image mode"
 return Image.fromstring(mode, (a.shape[1], a.shape[0]), a.tostring())
-ffts.py-
import PilConvert
import Image
from numarray import *
from numarray.fft import *
def doFft(im):
 nim = PilConvert.image2array(im)
 im_fft = abs(real_fft2d(nim))
 im_fft = log(im_fft + 1) # convert levels for display
 scale = 255. / max(im_fft.flat)
 im_fft = (im_fft * scale).astype(UInt8)
 imo = PilConvert.array2image(im_fft)
 return imo
im = Image.open('rm.bmp')
imo = doFft(im)
imo.save('rm_fourier.bmp', 'BMP')
*********** REPLY SEPARATOR ***********
On 9/03/2004 at 17:58 Perry Greenfield wrote:
> John Hunter writes:
> 
> > I'm starting to think about adding image support and wanted to get
> > some input about what it should include and how it should be designed.
> > The ideas are still pretty nascent but here is where I was planning to
> > start.
> > 
> > Create an image extension built around agg (not backend_agg). This
> > would be a free standing extension not tied to any of the backends
> > with the responsibility of loading image data from a variety of
> > sources into a pixel buffer, and resizing it to a desired pixel size
> > (dependent on the axes window) with customizable interpolation.
> > 
> I guess I'm confused by terminology. What do you intend "backend"
> to mean for images. A common interface for reading different
> image formats? Speaking of which...
> 
> > Inputs: what file formats should be supported? 
> > 
> > * I can do PNG rather easily since I already had to interface agg
> > with png for save capabilities in backend_agg.
> > 
> I guess I would argue for what you refer to below, that the
> functionality to read image formats should be decoupled, at least
> initially, from the plotting (display?) package. In fact, initially
> it may make sense just to use PIL for that functionality alone until
> we understand better what really needs to be integrated into the 
> display package. (The main drawback of PIL is that it doesn't support
> either Numeric or numarray, and Lundt isn't inclined to support
> either unless either is part of the Python Standard Library. It
> may turn out that we could add it to PIL, or extract from PIL
> the image file support component for our purposes. I suspect that
> that stuff is pretty stable). But initially, reading images into
> arrays seems like the most flexible and straightforward thing to
> do.
> 
> > * As for raw pixel data, should we try to support
> > grayscale/luminance, rgb and rgba with the platform dependent byte
> > ordering problems, or leave it to the user to load these into a
> > numeric/numarray and init the image with that? Should we follow
> > PILs lead here and just provide a fromstring method with format
> > strings?
> > 
> I haven't given this a great deal of thought, but again, arguing
> for simplicity, that the array representations should be simple.
> For example, nxm dim array implies luminance, nxmx3 implies
> rgb, nxmx4 implies rgba. The I/O module always fills the arrays
> in native byte order. I suppose that some thought should be given
> to the default array type. One possibility is to use Float32 with
> normalized values (1.0=max), but it is probably important to keep
> integer values from some image formats (like png). Floats give
> the greatest flexibility and independence from the display hardware,
> if sometimes wasteful of memory. The second type to support would be
> UInt8 (I admit I could be stupidly overlooking something).
> 
> These arrays are passed to matplotlib rendering methods
> or functions and the dimensionality will tell the rendering engine
> how to interpret it. The question is how much the engine needs to
> know about the depth and representation of the display buffer
> and how much of these details are handled by agg (or other backends)
> 
> 
> > * What raw types should be supported: 8 bit luminance, 16 bit
> > luminance, 8 bit rgb, 8bit rgba, 16 bit rgb or rgba?
> > 
> > Resizing: Generally the axes viewport and the image dimensions will
> > not agree. Several possible solutions - perhaps all need to be
> > supported:
> > 
> > * a custom axes creation func that fits the image when you just want
> > to view and draw onto single image (ie no multiple subplots).
> > 
> > * resize to fit, resize constrained aspect ratio, plot in current
> > axes and clip image outside axes viewlim
> > 
> > * with resizing, what pixel interpolation schemes are critical? agg
> > supports several: nearest neighbor, blinear, bicubic, spline,
> > sinc.
> >
> Here again I would argue that the resizing functions could be separated 
> into a separate module until we understand better how they should
> be integrated into the interface. So for now, require a user to
> apply a resampling function to an image. Something like this might
> be a good initial means of handling images.
> 
> im = readpng("mypicture.png") # returns a rgb array (nxmx3) unless alpha
> # is part of png files (I'm that ignorant).
> rebinned_im = bilinear(im, axisinfo...)
> 
> Then use rebinned_im for a pixel-to-pixel display in the plot canvas
> (with appropriate offset and clipping). This isn't quite as convenient
> as one step from file to display, but it should get us some flexible 
> functionality faster and doesn't restrict more integrated means of
> displaying images. There are other approaches to decoupling that are
> probably more object oriented.
> 
> I'll think more about this (and you can clarify more what you mean
> as well if I'm confused about what you are saying).
> 
> Perry 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
------------------------------------
Gary Ruben gr...@bi...
<http://users.bigpond.net.au/gazzar>

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
 >> Create an image extension built around agg (not backend_agg).
 >> This would be a free standing extension not tied to any of the
 >> backends with the responsibility of loading image data from a
 >> variety of sources into a pixel buffer, and resizing it to a
 >> desired pixel size (dependent on the axes window) with
 >> customizable interpolation.
 Perry> I guess I'm confused by terminology. What do you intend
 Perry> "backend" to mean for images. A common interface for
 Perry> reading different image formats? Speaking of which...
Sorry for the confusion. I meant that I was considering using
antigrain to load/store/scale/convert/process the pixel buffers in an
image module in the same way that PIL could be used, and that this has
nothing per se to do with backend_agg. By "backends", I meant the
same old backends we already have, backend_gd, backend_wx, backend_ps,
etc..., each of which would implement a new method draw_image to
render the image object to its respective canvases/displays. Whether
this image object is PIL based or Agg based under the hood is an open
question.
I hope I this clarifies rather than muddies the waters....
 Perry> But initially, reading images into arrays seems like the
 Perry> most flexible and straightforward thing to do.
Agreed - I like the idea of making the user deal with endianess, etc,
in loading the image data into arrays, and passing those to image
module. Todd, is it reasonably straightforward to write extension
code that is Numeric/numarray neutral for rank 2 and rank 3 arrays?
 Perry> These arrays are passed to matplotlib rendering methods or
 Perry> functions and the dimensionality will tell the rendering
 Perry> engine how to interpret it. The question is how much the
 Perry> engine needs to know about the depth and representation of
 Perry> the display buffer and how much of these details are
 Perry> handled by agg (or other backends)
One thing that the rest of matplotlib tries to do is insulate as much
complexity from the backends as possible. For example, the backends
only know one coordinate system (display) and the various figure
objects transform themselves before requesting, for example,
draw_lines or draw_text. Likewise, the backends don't know about
Line2D objects or Rectangle objects; the only know how to draw a line
from x1, y1 to x2, y2, etc...
This suggests doing as much work as possible in the image module
itself. For example, if the image module converted all image data to
an RGBA array of floats, this would be totally general and the
backends would only have to worry about one thing vis-a-vis images:
dumping rgba floats to the canvas. Nothing about byte-order, RGB
versus BGR, grayscale, colormaps and so on. Most or all of these
things could be supported in the image module: the image module scales
the image, handles the interpolation, and converts all pixel formats
to an array of rgba floats. Then the backend takes over and renders.
An array of RGBA UInt16s would probably suffice for just about
everything, however.
The obvious potential downside here is performance and memory. You
might be in a situation where the user passes in UInt8, the image
module converts to floats, and the backend converts back to UInt8 to
pass to display. Those of you who deal with image data a lot: to what
extent is this a big concern? My first reaction is that on a
reasonably modern PC, even largish images could be handled with
reasonable speed.
On the subject of PIL versus agg for the workhorse under the image
module hood: I agree with the positive points things about PIL that
you and Andrew brought up (stability, portability, wide user base,
relevant functionality already implemented). In favor of agg I would
add
 * we're already distributing agg so negligible code bloat; PIL is
 largish and not the easiest install. Distributing fonttools has
 been a mess that I don't want to repeat.
 * impressive suite of pixel conversion funcs, interpolators, filters
 and transforms built in
 * easy and efficient integration with backend_agg, which the GUIs
 are converging around. 
 * numeric/numarray support from the ground up
Downsides
 * less portable - requires modern c++ compiler
 * more up front work (but most is already done in C++ and just needs
 exposing)
JDH

<snipped lots of interesting discussion...>
> I guess I would argue for what you refer to below, that the
> functionality to read image formats should be decoupled, at least
> initially, from the plotting (display?) package. In fact, initially
> it may make sense just to use PIL for that functionality alone until
> we understand better what really needs to be integrated into the
> display package. (The main drawback of PIL is that it doesn't support
> either Numeric or numarray, and Lundt isn't inclined to support
> either unless either is part of the Python Standard Library. It
> may turn out that we could add it to PIL, or extract from PIL
> the image file support component for our purposes. I suspect that
> that stuff is pretty stable). But initially, reading images into
> arrays seems like the most flexible and straightforward thing to
> do.
Disclaimer: I surely don't understand all of the requirements for 
matplotlib imaging.
I would also suggest PIL, sticking as much as possible to the 
pure-Python interface. I suggest this because some OSs (well, Mac OS X 
is what I'm thinking of) are supposed to have native image-handling 
routines which are fine-tuned to their hardware and unlikely to be beat 
by some multi-platform project. (For example, I've heard that Apple's 
PNG handling is faster and better than libpng.) If someone modified PIL 
to take advantage of these platform-specific features, we would reap 
the benefits. Then again, this argument assumes someone will someday 
do that.
>> * As for raw pixel data, should we try to support
>> grayscale/luminance, rgb and rgba with the platform dependent byte
>> ordering problems, or leave it to the user to load these into a
>> numeric/numarray and init the image with that? Should we follow
>> PILs lead here and just provide a fromstring method with format
>> strings?
>>
> I haven't given this a great deal of thought, but again, arguing
> for simplicity, that the array representations should be simple.
> For example, nxm dim array implies luminance, nxmx3 implies
> rgb, nxmx4 implies rgba. The I/O module always fills the arrays
> in native byte order. I suppose that some thought should be given
> to the default array type. One possibility is to use Float32 with
> normalized values (1.0=max), but it is probably important to keep
> integer values from some image formats (like png). Floats give
> the greatest flexibility and independence from the display hardware,
> if sometimes wasteful of memory. The second type to support would be
> UInt8 (I admit I could be stupidly overlooking something).
I think the format string idea is a good one. An nxm dim array could 
be luminance, alpha, or possibly colormapped -- it's not necessarily 
known in advance what data type it is, although a guess would probably 
be right 99% of the time.
I also vote use a floating-point representation whenever possible. 
It's clear that 8 bits per color aren't enough for many purposes.
<snipped more interesting discussion...>

John Hunter writes:
> I'm starting to think about adding image support and wanted to get
> some input about what it should include and how it should be designed.
> The ideas are still pretty nascent but here is where I was planning to
> start.
> 
> Create an image extension built around agg (not backend_agg). This
> would be a free standing extension not tied to any of the backends
> with the responsibility of loading image data from a variety of
> sources into a pixel buffer, and resizing it to a desired pixel size
> (dependent on the axes window) with customizable interpolation.
> 
I guess I'm confused by terminology. What do you intend "backend"
to mean for images. A common interface for reading different
image formats? Speaking of which...
> Inputs: what file formats should be supported? 
> 
> * I can do PNG rather easily since I already had to interface agg
> with png for save capabilities in backend_agg.
> 
I guess I would argue for what you refer to below, that the
functionality to read image formats should be decoupled, at least
initially, from the plotting (display?) package. In fact, initially
it may make sense just to use PIL for that functionality alone until
we understand better what really needs to be integrated into the 
display package. (The main drawback of PIL is that it doesn't support
either Numeric or numarray, and Lundt isn't inclined to support
either unless either is part of the Python Standard Library. It
may turn out that we could add it to PIL, or extract from PIL
the image file support component for our purposes. I suspect that
that stuff is pretty stable). But initially, reading images into
arrays seems like the most flexible and straightforward thing to
do.
> * As for raw pixel data, should we try to support
> grayscale/luminance, rgb and rgba with the platform dependent byte
> ordering problems, or leave it to the user to load these into a
> numeric/numarray and init the image with that? Should we follow
> PILs lead here and just provide a fromstring method with format
> strings?
> 
I haven't given this a great deal of thought, but again, arguing
for simplicity, that the array representations should be simple.
For example, nxm dim array implies luminance, nxmx3 implies
rgb, nxmx4 implies rgba. The I/O module always fills the arrays
in native byte order. I suppose that some thought should be given
to the default array type. One possibility is to use Float32 with
normalized values (1.0=max), but it is probably important to keep
integer values from some image formats (like png). Floats give
the greatest flexibility and independence from the display hardware,
if sometimes wasteful of memory. The second type to support would be
UInt8 (I admit I could be stupidly overlooking something).
These arrays are passed to matplotlib rendering methods
or functions and the dimensionality will tell the rendering engine
how to interpret it. The question is how much the engine needs to
know about the depth and representation of the display buffer
and how much of these details are handled by agg (or other backends)
> * What raw types should be supported: 8 bit luminance, 16 bit
> luminance, 8 bit rgb, 8bit rgba, 16 bit rgb or rgba?
> 
> Resizing: Generally the axes viewport and the image dimensions will
> not agree. Several possible solutions - perhaps all need to be
> supported:
> 
> * a custom axes creation func that fits the image when you just want
> to view and draw onto single image (ie no multiple subplots).
> 
> * resize to fit, resize constrained aspect ratio, plot in current
> axes and clip image outside axes viewlim
> 
> * with resizing, what pixel interpolation schemes are critical? agg
> supports several: nearest neighbor, blinear, bicubic, spline,
> sinc.
>
Here again I would argue that the resizing functions could be separated 
into a separate module until we understand better how they should
be integrated into the interface. So for now, require a user to
apply a resampling function to an image. Something like this might
be a good initial means of handling images.
im = readpng("mypicture.png") # returns a rgb array (nxmx3) unless alpha
 # is part of png files (I'm that ignorant).
rebinned_im = bilinear(im, axisinfo...)
Then use rebinned_im for a pixel-to-pixel display in the plot canvas
(with appropriate offset and clipping). This isn't quite as convenient
as one step from file to display, but it should get us some flexible 
functionality faster and doesn't restrict more integrated means of
displaying images. There are other approaches to decoupling that are
probably more object oriented.
I'll think more about this (and you can clarify more what you mean
as well if I'm confused about what you are saying).
Perry 

>>>>> "John" == John N S Gill <jn...@eu...> writes:
 John> Quite often I find myself with numbers for different parts
 John> of the world that I want to map, shading regions different
 John> colours according to the numbers.
 John> The problem I've tended to run into with mapping projects
 John> has been getting shape files that aren't distributed under a
 John> restrictive licence.
I've experimented with this a bit using shapefiles from the national
atlas (I think they are distributed under a permissive license).
thuban has a nice python interface for reading shape files and their
associated db files. I've held off on pursuing this functionality
until we get an efficient path/polygon extension, which has been
discussed a number of times but is still on the TODO list. 
The example below renders the US map from 2000 polygons, and is slow
for interactive use with that many polygons.
 http://nitace.bsd.uchicago.edu:8080/files/share/map.png
For nice map navigation, you would probably want a better navigation
toolbar (hand pan, zoom to region) which was discussed many moons ago
but has also languished due to lack of time -
http://sourceforge.net/mailarchive/message.php?msg_id=6542965
Here's some example code:
# shapefile from
# http://edcftp.cr.usgs.gov/pub/data/nationalatlas/statesp020.tar.gz
# shapefile lib from http://thuban.intevation.org
import shapelib, dbflib, shptree
from matplotlib.patches import Polygon
from matplotlib.matlab import *
filename = 'statesp020.shp'
dbfile = 'statesp020.dbf'
shp = shapelib.ShapeFile(filename)
numShapes, type, smin, smax = shp.info()
ax = gca()
dpi = ax.dpi
bbox = ax.bbox
transx = ax.xaxis.transData
transy = ax.yaxis.transData
left=[]; right=[]; bottom=[]; top=[]
db = dbflib.open(dbfile)
# just get the main polys for each state
seen = {}
for i in range(numShapes):
 rec = db.read_record(i)
 state = rec['STATE']
 area = rec['AREA']
 obj = shp.read_object(i)
 verts = obj.vertices()[0]
 if seen.has_key(state):
 have, tmp = seen[state]
 if area>have:
 seen[state] = area, verts
 else:
 seen[state] = area, verts 
 
for state, tup in seen.items(): 
 area, verts = tup
 poly = Polygon(dpi, bbox, verts,
 fill=False,
 transx=transx, transy=transy)
 x = [tx for tx, ty in verts]
 y = [ty for tx, ty in verts]
 ax.xaxis.datalim.update(x)
 ax.yaxis.datalim.update(y)
 ax.add_patch(poly)
set(gca(), 'xlim', ax.xaxis.datalim.bounds())
set(gca(), 'ylim', ax.yaxis.datalim.bounds())
savefig('map', dpi=150)
axis('Off')
show() 

 
> Any other thoughts welcome...
 
Not really related to images but... 
I've been thinking a bit about mapplotlib (no, that is not a typo).
Quite often I find myself with numbers for different parts of the world
that I want to map, shading regions different colours according to the
numbers.
In fact, one of my early experiments with python and wxPython was to
produce such a beast, but I'm not terribly happy with what I produced.
matplotlib has lots of the goodies that mapplotlib would require: it
has axes you can zoom and scroll, is great a drawing coloured polygons
and can do legends.
The problem I've tended to run into with mapping projects has been
getting shape files that aren't distributed under a restrictive licence.
Anyway, is there any interest out there in a mapplotlib?
John

I'm starting to think about adding image support and wanted to get
some input about what it should include and how it should be designed.
The ideas are still pretty nascent but here is where I was planning to
start.
Create an image extension built around agg (not backend_agg). This
would be a free standing extension not tied to any of the backends
with the responsibility of loading image data from a variety of
sources into a pixel buffer, and resizing it to a desired pixel size
(dependent on the axes window) with customizable interpolation.
Inputs: what file formats should be supported? 
 * I can do PNG rather easily since I already had to interface agg
 with png for save capabilities in backend_agg.
 * As for raw pixel data, should we try to support
 grayscale/luminance, rgb and rgba with the platform dependent byte
 ordering problems, or leave it to the user to load these into a
 numeric/numarray and init the image with that? Should we follow
 PILs lead here and just provide a fromstring method with format
 strings?
 * What raw types should be supported: 8 bit luminance, 16 bit
 luminance, 8 bit rgb, 8bit rgba, 16 bit rgb or rgba?
Resizing: Generally the axes viewport and the image dimensions will
not agree. Several possible solutions - perhaps all need to be
supported:
 
 * a custom axes creation func that fits the image when you just want
 to view and draw onto single image (ie no multiple subplots).
 * resize to fit, resize constrained aspect ratio, plot in current
 axes and clip image outside axes viewlim
 * with resizing, what pixel interpolation schemes are critical? agg
 supports several: nearest neighbor, blinear, bicubic, spline,
 sinc.
Backends:
 I am thinking about using the same approach as in ft2font. Have the
 image backend provide the load/resize/interpolate methods and fill a
 pixel buffer of appropriate size and letting the backends do
 whatever they want with it. Agg can blend the image with the
 drawing buffer, gtk can draw from an rgba buffer. Not sure about PS
 yet. paint and wx can use their respective APIs to copy the pixel
 buffer.
Any other thoughts welcome...
JDH

John,
Attached is a new version of table.py where I have added some methods to
allow auto-scaling of the fonts used in the tables. 
The code simply shrinks the fontsize until it finds a value that fits.
John

>>>>> "Todd" == Todd Miller <jm...@st...> writes:
 Todd> JDH... do you have any idea where to put it?
I created a dir in CVS "license" which contains
 LICENSE - the matplotlib license
 LICENSE_PAINT - not really required anymore since font.cpp is no
 longer used
 LICENSE_PIL - you can refer to this in the appropriate tkagg src
 files
I also made a committed of couple of minor changes earlier to the
tkagg src that Andrew suggested to me that enable it to build cleanly
on OS X. With the current CVS setup.py and setupext.py, I can build
all the backends on linux, win32 and darwin, which is *a good thing*
:-).
JDH

On Mon, 2004年03月08日 at 17:41, Andrew Straw wrote:
> Hi matplotlib developers,
> 
> John has rightly directed me to the developers list with the following 
> email. So now, after subscribing, I have a couple of suggestions for 
> the developer of the TkAgg backend. (John Miller?)
I'm *Todd* Miller. My SF login is jaytmiller.
> 
> Begin forwarded message:
> 
> > From: John Hunter <jdh...@ac...>
> > Date: Tue Mar 9, 2004 2:52:33 AM Australia/Adelaide
> > To: Andrew Straw <str...@as...>
> > Subject: Re: TkAgg backend issues
> >
> >>>>>> "Andrew" == Andrew Straw <str...@as...> writes:
> >
> > Andrew> Hi John, A couple more quick notes:
> >
> > Andrew> 1) It might be very useful to put the following comment in
> > Andrew> setupext.py in the add_tk_flags section so that idiots
> > Andrew> like me don't build the TkAgg backend against tk8.4, even
> > Andrew> though their Tkinter uses 8.3!
> >
> > Andrew> # Make sure you use the Tk version given by
> > Andrew> Tkinter.TkVersion # or else you'll build for a wrong
> > Andrew> version of the Tcl # interpreter (leading to nasty
> > Andrew> segfaults).
OK. I added this to setupext.py. Thanks for the suggestion.
> >
> > Andrew> 2) It's pretty clear that a lot of the TkAgg stuff was
> > Andrew> taken directly out of PIL. 
This was news to me, but Perry confirmed it.
> Therefore, we need to live up
> > Andrew> to their (not very challenging) license conditions: we
> > Andrew> have to include their copyright notice and their
> > Andrew> permissions as specified in Imaging-1.1.x/README.
> >
Here's what I think we have to include:
--------------------------------------------------------------------
Software License
--------------------------------------------------------------------
The Python Imaging Library is
Copyright (c) 1997-2002 by Secret Labs AB
Copyright (c) 1995-2002 by Fredrik Lundh
By obtaining, using, and/or copying this software and/or its
associated documentation, you agree that you have read, understood,
and will comply with the following terms and conditions:
Permission to use, copy, modify, and distribute this software and its
associated documentation for any purpose and without fee is hereby
granted, provided that the above copyright notice appears in all
copies, and that both that copyright notice and this permission notice
appear in supporting documentation, and that the name of Secret Labs
AB or the author not be used in advertising or publicity pertaining to
distribution of the software without specific, written prior
permission.
SECRET LABS AB AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO
THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS. IN NO EVENT SHALL SECRET LABS AB OR THE AUTHOR BE LIABLE FOR
ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
JDH... do you have any idea where to put it?
Thanks for the feedback,
Todd Miller
-- 
Todd Miller <jm...@st...>

Hi matplotlib developers,
John has rightly directed me to the developers list with the following 
email. So now, after subscribing, I have a couple of suggestions for 
the developer of the TkAgg backend. (John Miller?)
Begin forwarded message:
> From: John Hunter <jdh...@ac...>
> Date: Tue Mar 9, 2004 2:52:33 AM Australia/Adelaide
> To: Andrew Straw <str...@as...>
> Subject: Re: TkAgg backend issues
>
>>>>>> "Andrew" == Andrew Straw <str...@as...> writes:
>
> Andrew> Hi John, A couple more quick notes:
>
> Andrew> 1) It might be very useful to put the following comment in
> Andrew> setupext.py in the add_tk_flags section so that idiots
> Andrew> like me don't build the TkAgg backend against tk8.4, even
> Andrew> though their Tkinter uses 8.3!
>
> Andrew> # Make sure you use the Tk version given by
> Andrew> Tkinter.TkVersion # or else you'll build for a wrong
> Andrew> version of the Tcl # interpreter (leading to nasty
> Andrew> segfaults).
>
> Andrew> 2) It's pretty clear that a lot of the TkAgg stuff was
> Andrew> taken directly out of PIL. Therefore, we need to live up
> Andrew> to their (not very challenging) license conditions: we
> Andrew> have to include their copyright notice and their
> Andrew> permissions as specified in Imaging-1.1.x/README.
>
> Looks right to me. Could you email this to the devel list. I don't
> maintain the Tk backend so I'd like Todd and the rest of the stsci
> crew to take the lead here.
>
> If it's alright with you, matplotlib-devel is the best place for
> patches, comments, etc..., since sometimes other people are working on
> similar problems and would like to avail themselves of your work and
> comments.
>
> Thanks!
> JDH
>

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