matplotlib-devel Mailing List for matplotlib

I've committed a new font manager to CVS.  It is based on the W3C Cascading 
Style Sheet, Level 1 (CSS1) design.  It is still rather basic, but does seem to 
work for most of the backends.  Therefore, FontTools, ttfquery, and 
ttf_font_manager are no longer needed by matplotlib.

The font manager currently handle only TrueType fonts, but should be 
generalizable to other font types.

The text object now has a fontproperties attribute which describes the basic 
aspects of the font, such as family, style, weight and size.  This attribute 
replaces the fontname, fontangle, fontweight, and fontsize attributes.

In future, I would suggest using font name sizes, such as small, medium, and 
large, to specify font sizes, instead of point sizes.  This should make it 
easier for font sizes to be consistent across backends.  It will also make it 
easier to change all the fonts just by changing the default font size that is 
associated with the medium font name.  The default value for this is 12.

The other interface issue to be aware of is the font family.  This is a list of 
font names in order of decreasing priority.  This should make it easier to match 
similar fonts across the various platforms.

  -- Paul

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

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

    Andrew> Now, my question is, can we set edgecolor=None on a patch
    Andrew> and have it not draw the edges of the patch?  Or whatever
    Andrew> is the most matlab-compatible way, assuming one can do
    Andrew> this in matlab.  Or, perhaps by analogy to fill=True we
    Andrew> could have stroke=True as well.  Perhaps this is already
    Andrew> "in there"--if so, what do I do?

Unfortunately, the backend design doesn't accomodate this so nicely.
The workaround is to set the edge and the face color to be the same.
You pay a performance hit but otherwise *it works*.

To do it right will require, but will require some extra work.  

A typical signature is:

    def draw_rectangle(self, gcEdge, rgbFace, x, y, width, height):

The gc contains extra information in addition to color that the
backend may optionally use in drawing the polygon: alpha, line
thickness, dash style.  This is why facecolor and edgecolor are set
differently in the current framework.   

I'm not sure what the cleanest design is to overcome this; it would
definitely require changing all the draw patch methods of all the
backends.  

Setting gcEdge to None is probably the easiest but you would lose
alpha information in doing so that we may want to use in drawing
filled polygons/rectangles.

An alternative is to simply remove the gc and explicitly pass the
required properties.

This brings up my next big matplotlib project - handling large
quantities of polygon data efficiently.  I would like to define all
the properties that are required for polygon drawing so that we can
provide optional backend methods like draw_rectangles and
draw_ellipses which could be implemented more efficiently than the
current methods.

I've always found the gcEdge and rgbFace a bit hackish for polygons
and wanted to clean this up at least for the polygon collection code.
So what is needed to fully specify a 2D polygon?

 * vertices 
 * edge thickness
 * edge dashes, eg a dashed rectangle surrounding a region
 * edge color: rgb or none for invisible
 * face color: rgb or none for invisible
 * alpha

Anything else?

I was thinking about a signature along the lines of 

  # good for drawing a polygon map of a country
  draw_polygons(N, verts, widths, dashes, edges, faces, alphas, trans):
    
Any of these args can be an N length sequence or a 1 length sequence.
If the sequence is length one, the backend just uses the 0th index for
all the polygons.

  verts: a list like [p1, p2, p3] where p1 = ( (x1,y1), (x2,y2), ...)
         and so on

  widths: the edge thickness

  dashes: a list like [d1,d2,d3] where d1 = ( inkon1, inkoff1,
          inkoff1, inkoff2).  This may be overkill; in 99.9999% of the
          cases as single dash style is all anyone will want.  Perhaps
          best to do away with dashes altogether for polygon
          collections.

  edges : a list of [rgb1, rgb2, ...]
  faces : a list of [rgb1, rgb2, ...]
  alphas: a list of [alpha1, alpha2, ...]
  trans:  a six-tuple, postscript/agg style transformation vector.

The last arg violates the current design in which backends don't have
to worry about transformations.  But doing the transformations of
verts in python incurs a performance penalty that obviates the purpose
of the function so it seems worth it.

draw_polygons really isn't ideally suited to a scatter or pcolor
though.  In those cases you would spend a lot of time in python
constructing your polygons vertices when you really only need one
shape placed at a many locations, possibly scaled.

  # good for drawing a polygon map of a country
  draw_identical(N, path, offsets, scales, widths, 
                 dashes, edges, faces, alphas, trans):


  path    : is a sequence of rlineto's defining the shape of the polygon
  offsets : a sequence of [(x1,y1), (x2,y2), ...] for the path
  scales  : a sequence of scales for each path; [scale1, scale2,
            scale3, ...] or [ (sx1, sy2), (sx2, sy2), ...] allowing
            the x and y directions to scale independently
  other args are the same

This seems a bit cumbersome.  I'm trying to think of the fewest
functions that will handle at least

  * pcolor with rectangles
  * scatters with markers of arbitrary shape and possibly varying
    sizes
  * maps, eg, map of voting by county in the US.

Thoughts?

JDH

On Tuesday, March 16, 2004, at 10:52 PM, John Hunter wrote:
>
> Changes are in CVS.

Great! (Too bad SF's CVS servers are way behind for anonymous 
checkouts--it's driving me nuts! I had to piece together a recent CVS 
checkout by downloading the CVSROOT tarball...)

Now, my question is, can we set edgecolor=None on a patch and have it 
not draw the edges of the patch?  Or whatever is the most 
matlab-compatible way, assuming one can do this in matlab.  Or, perhaps 
by analogy to fill=True we could have stroke=True as well.  Perhaps 
this is already "in there"--if so, what do I do?

Keep up the great work!
Andrew

On Tuesday, March 16, 2004, at 11:32 PM, John Hunter wrote:

>
> On OS X 10.3, I can run TkAgg fine, interactive works great from the
> prompt, etc.  However, when I on the figure window to move it or click
> on a navigation button etc, I get a "SetFrontProcess failed, -606"
> message and the desired action does not happen.  I am running under
> X11, launching python from an xterm.
>
> Do you get this Andrew?  Any ideas?

Yes.

Short answer: use "pythonw" not "python"

Long anser: The OS X Cocoa WindowServer (I'm paraphrasing the proper 
terms, which I'm sure are slightly different) requires something like 
any application that wants to open a GUI window must be clicked or 
equivalent.  Since that's not the way python generally works, pythonw 
for OS X was modified to do some black magic (LaunchServices??) to get 
around this requirement.  This stuff is not in the normal python 
executable. For this reason, I have my trusty ipython shell using 
pythonw on OS X.  There doesn't seem to be any problem running non-Tk 
apps with pythonw.

FYI, pygame has something that will print a complaint if it's not run 
with pythonw.  We could look under the hood and figure out how it's 
done there...