matplotlib-devel Mailing List for matplotlib (Page 516)

On Fri, 2005-05-13 at 20:46 -0400, Paul Barrett wrote:
> I guess that I wasn't aware of it at the time.  I believe (John may want 
> to correct me if I'm wrong) that there was also a desire to have it 
> coded in Python for reasons of simplicity and portability, since in 
> early 2004 MPL was not as mature as it is now and did not contain as 
> much C/C++ code.  I see no reason not to use fontconfig if it provides 
> the same functionality as the current font_manager and the wrapper 
> software can be easily done.
> 
> What obvious benefits do you see to using fontconfig instead of 
> font_manager?  

- speed from being coded in C.
- speed from caching font info, and avoiding the need to traverse the
filesystem reading font filenames and directories.
- fontconfig is widely used, so its code has become well tested and
mature.

- integration with freetype
You could say that fontconfig is a utility designed to help you use
freetype, so if you require freetype (as mpl does) why not use
fontconfig too? Many systems that have freetype installed will already
have fontconfig installed as well. 

- consistency with other applications - if you are using gtk+/GNOME,
Qt/KDE, Mozilla or other applications that use fontconfig then using
fontconfig from matplotlib means you are using the same font-matching
library and have access to exactly the same font files as your other
applications.

> Does it provide access to individual font glyphs?  This 
> feature would allow embedded fonts and mathtext to be included in the 
> SVG backend.  I guessing that it almost certainly provides unicode 
> support.  Anything else?

Fontconfig does the font-matching and font configuration, to access to
individual font glyphs I think you use freetype directly (after
fontconfig has selected the desired font).

"Font Configuration and Customization for Open Source Systems" written
in 2002 describes the origial design of fontconfig -
http://keithp.com/~keithp/talks/guadec2002/

This is the main fontconfig site http://www.fontconfig.org/wiki/

Steve

Steve Chaplin wrote:

>I took a look at font_manager.py today and can see that John and Paul have 
>done a good job but I wonder - is it a case of reinventing the wheel, or 
>perhaps parallel development?
>
>There is the fontconfig library (written in C) which has very similar 
>functionality. It works with FreeType, supports W3C CSS2, is used by 
>Mozilla, pango/gtk+, Qt and is available for Windows, and provides
>caching of font information.
>
>Was fontconfig considered when font_manager was written and a decision 
>made not to use it?
>
>fontconfig seems to have become the standard font config and font matching 
>method for many systems and applications, should matplotlib consider
>using it?
>(It would involve creating a Python binding for it, but that should be
>possible)
>  
>
I guess that I wasn't aware of it at the time.  I believe (John may want 
to correct me if I'm wrong) that there was also a desire to have it 
coded in Python for reasons of simplicity and portability, since in 
early 2004 MPL was not as mature as it is now and did not contain as 
much C/C++ code.  I see no reason not to use fontconfig if it provides 
the same functionality as the current font_manager and the wrapper 
software can be easily done.

What obvious benefits do you see to using fontconfig instead of 
font_manager?  Does it provide access to individual font glyphs?  This 
feature would allow embedded fonts and mathtext to be included in the 
SVG backend.  I guessing that it almost certainly provides unicode 
support.  Anything else?

 -- Paul

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

Hi, Florent! ;-)

Florent Rougon <f.r...@fr...> wrote:

[...]

> This causes minor tick labels not to be drawn when using tick_top(), as
> shown in the attached example (+ two lines patch).

This part of my mail still applies, AFAICT.

> Note: I stumbled accross this because I draw a few vlines on a plot to
>       mark specific values and I wanted a label indicating what each
>       vline means. I managed to add these labels with minor ticks using
>       a FixedLocator and a FixedFormatter, but the minor tick labels
>       where colliding with the major ones. Therefore, I tried to move
>       them to the top.

For this one, however, I have found a better solution. FixedLocator and
FixedFormatter are easy to use, but:

   1. They replace one of your two major/minor ticks&ticklabels sets.
   2. They don't allow you (AFAIK) do draw the labels on the other side
      of the axis line (i.e., above the axis line when using
      tick_bottom(), below the axis line when using tick_top()), which
      caused ugly overlaps with major tick labels in my case.

The better solution simply consists in mimicking what is done in axis.py
to place tick labels. A small loop over the positions and label strings,
mixed with a transformation, and voilà! The labels are placed just as
they should, offset a bit to the left (to avoid clashing with the vline
they correspond to) and top from the position on the x axis, with the
offsets given in dpi, and therefore correct whatever resolution is
chosen to render the figure.

Special congrats for having included this dpi setting as lazy value in
the core design, despite the usual habit of working directly in pixels.


For the curious, here is the relevant part of code:

    pos    = [ self.mean, self.d1, self.q1, self.median, self.q3, self.d9 ]
    labels = [ u"mo", u"d1", u"q1", u"md", u"q3", u"d9" ]
    colors = [ 'r', '#6b8e23', '#cc5522', 'b', 'c', 'm']

    # We are going to draw a vertical line at each position with a label
    # nearby.
    #
    # Bad method for the label placement: using minor ticks. The biggest
    # problem is that it doesn't allow drawing the labels above the x axis
    # line; consequently, they often collide with the major tick labels,
    # which looks quite ugly:
    #
    #   self.axes.xaxis.set_minor_locator(FixedLocator(pos))
    #   self.axes.xaxis.set_minor_formatter(FixedFormatter(labels))
    #
    # Good method: place the labels by hand, just the way it is done in
    # matplotlib/axis.py for tick labels. For this, we use a transform
    # that will be passed to self.axes.text() and will translate each
    # label by the following offset, in PostScript points (1/72 inch):
    xoffset, yoffset = -3., 2.
    # The same offset in pixels, based on the figure's dpi value
    xo_pixels = Value(xoffset)*self.axes.figure.dpi*Value(1/72.)
    yo_pixels = Value(yoffset)*self.axes.figure.dpi*Value(1/72.)

    # We are going to transform x data coordinates and y Axes coordinates
    # into backend coordinates (pixels).
    trans = blend_xy_sep_transform(self.axes.transData,
                                   self.axes.transAxes)

    # The label text will be offset with a post-transformation
    transOffset = translation_transform(xo_pixels, yo_pixels)
    trans.set_offset((0,0), transOffset)

    for i in xrange(len(pos)):
        # Draw the line
        self.axes.axvline(x=pos[i], ymin=0., ymax=1., color=colors[i])
        # Place the corresponding label; x is in data coordinates and y in
        # Axes coordinates.
        self.axes.text(x=pos[i], y=0., s=labels[i],
                       fontsize=rcParams["tick.labelsize"],
                       verticalalignment='bottom',
                       horizontalalignment='right', transform=trans)

-- 
Florent

I took a look at font_manager.py today and can see that John and Paul have 
done a good job but I wonder - is it a case of reinventing the wheel, or 
perhaps parallel development?

There is the fontconfig library (written in C) which has very similar 
functionality. It works with FreeType, supports W3C CSS2, is used by 
Mozilla, pango/gtk+, Qt and is available for Windows, and provides
caching of font information.

Was fontconfig considered when font_manager was written and a decision 
made not to use it?

fontconfig seems to have become the standard font config and font matching 
method for many systems and applications, should matplotlib consider
using it?
(It would involve creating a Python binding for it, but that should be
possible)

Steve

>Thanks for the references. I decided to go for the second approach (it 
>seems maybe more sane, and it doesn't seem like their are any major 
>benefits to using the glyphs made..) The SVG code outputs a tuple of:
>basename, fontsize, unicode, ox, oy, metrics
>
>I go through the list, and output that. I'm not sure if I'm doing 
>everything correctly. For example, I have no clue what 'metrics' 
>contains (e.g. what advance, width, etc. will do, and if I need it or 
>not). I'm also not sure if things like hinting work using this method 
>either (esp. since I render each character seperately -- I'm not sure
I 
>see any other method of doing it, however).
>
>Any of this look sane?
>
>ctx = cairo.Context()
>file = open('test.ps', 'wb')
>ctx.set_target_ps(file, 4.3, 4.3, 300, 300)
>
>width, height, fonts = math_parse_s_ft2font_svg(r'$x^y * \pi$', 96, 50)
>
>for f in fonts:
>  basename, fontsize, num, ox, oy, metrics = f
>  ctx.select_font(basename)
>  ctx.scale_font(fontsize)
>  ctx.move_to(ox, 100 - oy)
>  ctx.show_text(unichr(num).encode('utf8'))
>
>ctx.stroke()
>
>ctx.show_page()

Looks OK as far as I can tell, did you run it and check the image?

The PS output produced by cairo is currently an image but eventually
the cairo PS backend will be updated to produce native PS.

Cairo itself has changed a lot since the last 0.4.0 snapshot, mostly
function name changes rather than new features. A new release should 
happen in a few weeks.

Steve

Hi all:

Here's a patch for axes.py that adds masked array support for pcolor.  
If either C[i,j], or any of the vertices surrounding it (X,Y at i,j 
i+1,j i+1,j+1 or i,j+1) are masked, the polygon is not filled. 

-Jeff

-- 
Jeffrey S. Whitaker         Phone : (303)497-6313
NOAA/OAR/CDC  R/CDC1        FAX   : (303)497-6449
325 Broadway                Web   : http://www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124

Here's an attempt at adding a method to allow controlling of the maximum 
radial value displayed in a polar plot.  In axes.py, I added the following 
method to the PolarAxes class.  I basically copied the code from 
autoscale_view() and made some minor changes.  If I can figure out what 
each step actually does I'll add some comments.

     def set_rmax( self, rmax ):
         rmin, oldrmax = self.rlocator.autoscale()
         self.rintv.set_bounds(rmin, rmax)

         self.axesPatch.xy = zip(self.thetas, rmax*ones(self.RESOLUTION))
         val = rmax*math.sqrt(2)
         self.viewLim.intervaly().set_bounds(val, val)

         # Re-create the radial ticks and labels.
         ticks = self.rlocator()
         self.set_rgrids(ticks)

         for t in self.thetagridlabels:
             t.set_y(1.05*rmax)

         r = linspace(0, rmax, self.RESOLUTION)
         for l in self.thetagridlines:
             l.set_ydata(r)

It sorta works but it definitely has a lot of problems.  Here's a sample 
script:

from pylab import *
figure( figsize=( 5, 5 ) )

theta = arange( 1, 6, .1 )
r = 10 * theta

polar( theta, r )
show()

Then try:
gca().set_rmax( 30 )
show()

1) I don't really want to call set_rgrids() because you lose any 
modifications the user has made to the radial grid.  If I don't call this, 
the radial grid doesn't update though so it looks crazy.  What would be 
nice is to duplicate the behavior of X/Y plots.   For example, if I set x 
ticks to be at 1,2,3 and then set the x limit to be 1->2, I don't see the 3 
tick somewhere off to the right of the plot.

2) There seems to be some kind of update problem w/ the theta labels.  Even 
though they're locations are being reset in the set_y() call, they don't 
appear.  However, if I use the pan button in the GUI and lightly tap the 
screen, they'll show up in the right locations (forget for a moment that 
panning is kind of a stupid thing to do in polar plots).

3) There is definitely some kind of data clipping problem.  The curve is 
not being properly clipped at the plot boundaries after calling set_rmax().

I'm sure all of these are problems w/ my set_rmax() routine but I'm not 
sure where to start with them.  Does anyone have any pointers for me to 
start with?

Thanks,
Ted

Hi,

It seems there is a little bug in axis.py, line 543 (in Axis.draw()).
The legacy Tick.set_label() is used instead of set_label1 and
set_label2 (a few lines above, the analogous code for major ticks uses
set_label1 and set_label2).

This causes minor tick labels not to be drawn when using tick_top(), as
shown in the attached example (+ two lines patch).

Thanks for the references. I decided to go for the second approach (it=20
seems maybe more sane, and it doesn't seem like their are any major=20
benefits to using the glyphs made..) The SVG code outputs a tuple of:
basename, fontsize, unicode, ox, oy, metrics

I go through the list, and output that. I'm not sure if I'm doing=20
everything correctly. For example, I have no clue what 'metrics'=20
contains (e.g. what advance, width, etc. will do, and if I need it or=20
not). I'm also not sure if things like hinting work using this method=20
either (esp. since I render each character seperately -- I'm not sure I=20
see any other method of doing it, however).

Any of this look sane?

ctx =3D cairo.Context()
file =3D open('test.ps', 'wb')
ctx.set_target_ps(file, 4.3, 4.3, 300, 300)

width, height, fonts =3D math_parse_s_ft2font_svg(r'$x^y * \pi$', 96, 50)

for f in fonts:
  basename, fontsize, num, ox, oy, metrics =3D f
  ctx.select_font(basename)
  ctx.scale_font(fontsize)
  ctx.move_to(ox, 100 - oy)
  ctx.show_text(unichr(num).encode('utf8'))

ctx.stroke()

ctx.show_page()





John Hunter wrote:

>>>>>>"Abraham" =3D=3D Abraham Schneider <ab...@cn...> writes:
>>>>>>           =20
>>>>>>
>
>    Abraham> When looking through the backend_cairo.py code, I
>    Abraham> realized that it currently renders the mathtext as
>    Abraham> images. While this is currently fine, as cairo's export
>    Abraham> of PS is really just an image, it would be better in the
>    Abraham> future to actually have it draw the fonts as paths.
>
>    Abraham> My first approach was to hack 'draw_mathtext.py', and to
>    Abraham> go and draw the strokes for the glyph's paths. The
>    Abraham> commands that the glyphs allow are (according to
>    Abraham> ft2font.cpp) are: MOVETO=3D0, LINETO=3D1, CURVE3=3D2, CURVE=
4=3D3,
>    Abraham> ENDPOLY=3D4. It seemed fairly simple, as cairo has the
>    Abraham> commands: 'move_to(x, y)', 'line_to(x, y)', and
>    Abraham> 'close_path()'. I wasn't sure if move_to and line_to were
>    Abraham> the equivalents of this, or actually 'rel_move_to' and
>    Abraham> 'rel_line_to'. Also, I wasn't sure how to map CURVE3 onto
>    Abraham> cairo's 'curve_to' (admittedly I know very little about
>    Abraham> these types of curves).
>
>    Abraham> If anyone has any suggestions on how to do this, it would
>    Abraham> be greatly appreciated. I also realized halfway through
>    Abraham> that perhaps it was a better idea to instead use cairo's
>    Abraham> truetype font ability, and if there weren't a simpler
>    Abraham> method to do this..
>
>I don't know much about cairo, but I can fill in a little detail about
>the font paths.  From
>http://freetype.sourceforge.net/freetype2/docs/glyphs/glyphs-6.html
>
>  An outline is described as a series of closed contours in the 2D
>  plane. Each contour is made of a series of line segments and B=E9zier
>  arcs. Depending on the file format, these can be second-order or
>  third-order polynomials. The former are also called quadratic or
>  conic arcs, and they are used in the TrueType format. The latter are
>  called cubic arcs and are mostly used in the Type 1 format.
>
>
>The CURVE3 code is a conic arc and the tuple that represents that
>curve in the glyph.path sequence is
>
>  CURVE3, xctl, yctl, xto, yto
>
>and for cubic arcs is=20
>
>  CURVE4, xctl1, yctl1, xctl2, yctl2, xto, yto
>
>
>The code to extra path from a glyph was lifted from agg, but I put the
>data structures in a list rather than an agg path to decouple agg form
>the freetype module.  I'm still deliberating about whether this is a
>good idea or not.
>
>Like you, I am not sure how to best handle conic arcs in cairo, but
>Steve may know.  Note that if you go the route you are considering,
>you will lose hinting information, so figuring out a way to use
>cairo's native truetype support may be preferable.
>
>So I can't really answer any of your questions .... but I'll post a
>conversion function from the ft2font path to an agg path in case it's
>of any use
>
>
>import os
>import matplotlib
>from matplotlib.ft2font import FT2Font
>import matplotlib.agg as agg
>
>MOVETO, LINETO, CURVE3, CURVE4, ENDPOLY =3D range(5)
>
>def glyph_to_agg_path(glyph):
>    path =3D agg.path_storage()
>    for tup in glyph.path:
>        print tup
>        code =3D tup[0]
>        if code =3D=3D MOVETO:
>            x,y =3D tup[1:]
>            path.move_to(x,y)
>        elif code =3D=3D LINETO:
>            x,y =3D tup[1:]
>            path.line_to(x,y)
>        elif code =3D=3D CURVE3:
>            xctl, yctl, xto, yto=3D tup[1:]
>            path.curve3(xctl, yctl, xto, yto)
>
>        elif code =3D=3D CURVE4:
>            xctl1, yctl1, xctl2, yctl2, xto, yto=3D tup[1:]
>            path.curve4(xctl1, yct1, xctl2, yctl2, xto, yto)
>        elif code =3D=3D ENDPOLY:
>            path.end_poly()
>
>    return path
>
>fname =3D os.path.join(matplotlib.get_data_path(), 'Vera.ttf')
>font =3D FT2Font(fname)
>glyph =3D font.load_char(ord('a'))
>path =3D glyph_to_agg_path(glyph)
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Oracle Space Sweepstakes
>Want to be the first software developer in space?
>Enter now for the Oracle Space Sweepstakes!
>http://ads.osdn.com/?ad_ids93&alloc_id=16281&op=3Dclick
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> =20
>

Hi,

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

> Yes, this is a historical artifact.  bar was implemented first (and

[...]

> This would all be fairly trivial except table is based on bar, and the
> table layout is pretty complex.  I "fixed" bar but broke table, and
> seeing no easy fix, unrolled the changes to bar. And that is where I
> left this problem last time I looked.

OK, I see.

> Would you mind filing a bug report on the sf site, with example code
> that shows the different behaviors of bar and barv, including a link
> to this discussion.

Done.

-- 
Florent

>>>>> "Abraham" =3D=3D Abraham Schneider <ab...@cn...> writes:

    Abraham> When looking through the backend_cairo.py code, I
    Abraham> realized that it currently renders the mathtext as
    Abraham> images. While this is currently fine, as cairo's export
    Abraham> of PS is really just an image, it would be better in the
    Abraham> future to actually have it draw the fonts as paths.

    Abraham> My first approach was to hack 'draw_mathtext.py', and to
    Abraham> go and draw the strokes for the glyph's paths. The
    Abraham> commands that the glyphs allow are (according to
    Abraham> ft2font.cpp) are: MOVETO=3D0, LINETO=3D1, CURVE3=3D2, CURVE4=
=3D3,
    Abraham> ENDPOLY=3D4. It seemed fairly simple, as cairo has the
    Abraham> commands: 'move_to(x, y)', 'line_to(x, y)', and
    Abraham> 'close_path()'. I wasn't sure if move_to and line_to were
    Abraham> the equivalents of this, or actually 'rel_move_to' and
    Abraham> 'rel_line_to'. Also, I wasn't sure how to map CURVE3 onto
    Abraham> cairo's 'curve_to' (admittedly I know very little about
    Abraham> these types of curves).

    Abraham> If anyone has any suggestions on how to do this, it would
    Abraham> be greatly appreciated. I also realized halfway through
    Abraham> that perhaps it was a better idea to instead use cairo's
    Abraham> truetype font ability, and if there weren't a simpler
    Abraham> method to do this..

I don't know much about cairo, but I can fill in a little detail about
the font paths.  From
http://freetype.sourceforge.net/freetype2/docs/glyphs/glyphs-6.html

  An outline is described as a series of closed contours in the 2D
  plane. Each contour is made of a series of line segments and B=E9zier
  arcs. Depending on the file format, these can be second-order or
  third-order polynomials. The former are also called quadratic or
  conic arcs, and they are used in the TrueType format. The latter are
  called cubic arcs and are mostly used in the Type 1 format.


The CURVE3 code is a conic arc and the tuple that represents that
curve in the glyph.path sequence is

  CURVE3, xctl, yctl, xto, yto

and for cubic arcs is=20

  CURVE4, xctl1, yctl1, xctl2, yctl2, xto, yto


The code to extra path from a glyph was lifted from agg, but I put the
data structures in a list rather than an agg path to decouple agg form
the freetype module.  I'm still deliberating about whether this is a
good idea or not.

Like you, I am not sure how to best handle conic arcs in cairo, but
Steve may know.  Note that if you go the route you are considering,
you will lose hinting information, so figuring out a way to use
cairo's native truetype support may be preferable.

So I can't really answer any of your questions .... but I'll post a
conversion function from the ft2font path to an agg path in case it's
of any use


import os
import matplotlib
from matplotlib.ft2font import FT2Font
import matplotlib.agg as agg

MOVETO, LINETO, CURVE3, CURVE4, ENDPOLY =3D range(5)

def glyph_to_agg_path(glyph):
    path =3D agg.path_storage()
    for tup in glyph.path:
        print tup
        code =3D tup[0]
        if code =3D=3D MOVETO:
            x,y =3D tup[1:]
            path.move_to(x,y)
        elif code =3D=3D LINETO:
            x,y =3D tup[1:]
            path.line_to(x,y)
        elif code =3D=3D CURVE3:
            xctl, yctl, xto, yto=3D tup[1:]
            path.curve3(xctl, yctl, xto, yto)

        elif code =3D=3D CURVE4:
            xctl1, yctl1, xctl2, yctl2, xto, yto=3D tup[1:]
            path.curve4(xctl1, yct1, xctl2, yctl2, xto, yto)
        elif code =3D=3D ENDPOLY:
            path.end_poly()

    return path

fname =3D os.path.join(matplotlib.get_data_path(), 'Vera.ttf')
font =3D FT2Font(fname)
glyph =3D font.load_char(ord('a'))
path =3D glyph_to_agg_path(glyph)

When looking through the backend_cairo.py code, I realized that it 
currently renders the mathtext as images. While this is currently fine, 
as cairo's export of PS is really just an image, it would be better in 
the future to actually have it draw the fonts as paths.

My first approach was to hack 'draw_mathtext.py', and to go and draw the 
strokes for the glyph's paths. The commands that the glyphs allow are 
(according to ft2font.cpp) are: MOVETO=0, LINETO=1, CURVE3=2, CURVE4=3, 
ENDPOLY=4. It seemed fairly simple, as cairo has the commands: 
'move_to(x, y)', 'line_to(x, y)', and 'close_path()'. I wasn't sure if 
move_to and line_to were the equivalents of this, or actually 
'rel_move_to' and 'rel_line_to'. Also, I wasn't sure how to map CURVE3 
onto cairo's 'curve_to' (admittedly I know very little about these types 
of curves).

If anyone has any suggestions on how to do this, it would be greatly 
appreciated. I also realized halfway through that perhaps it was a 
better idea to instead use cairo's truetype font ability, and if there 
weren't a simpler method to do this..

Thanks!

Abe

>>>>> "Marcin" == Marcin Wojdyr <wo...@un...> writes:


    Marcin> And the same about patches?  I like SF tracker.  It has
    Marcin> "Send email on new submission to" option.  Perhaps it
    Marcin> would be a good idea to send e-mail to devel list?

Yes, this is also a good idea.

JDH

>>>>> "Rolf" == Rolf Wester <rol...@il...> writes:

    Rolf> Hi, I have installed matplotlib-0.80 on WinXP and when I run
    Rolf> a Python script that calls pylab.plot several times after a
    Rolf> while the program ends with the error message listed
    Rolf> below. I inserted some print statements into backend_agg.py
    Rolf> and text.py (code snippets see below). As far as I can see
    Rolf> the problem is with the function xy_tup that returns
    Rolf> (70.0555555556, -3509680569.77) when given the input
    Rolf> (-0.030476944389471572, -0.012864052691159839).

It looks like your canvas width and height are really large if I am
reading your traceback properly -- are you sure your figure size and
dpi params are set right?  It would help immensely if you can come up
with a stand-alone script that exposes the bug.  If you can, report it
to the sourceforge bug tracker, along with the output of
--verbose-helpful and your rc file if it is customized and we can
probably track it down.

Absent a script which produces the bug, it is very hard to fix these
problems, even with the nice tracebacks you've provided.  Because many
people use mpl 0.80 on windows XP and haven't reported this problem, I
wonder if there is a bug in the script you are using or in your
configuration file.


Thanks,
JDH

>>>>> "Marcin" == Marcin Wojdyr <wo...@un...> writes:

    Marcin> It is attached. There are two comments-questions in the
    Marcin> patch, please delete them after reading.  And at the end
    Marcin> of this patched legend() method there is a line handles =
    Marcin> flatten(handles) If handles are not already flat, I think
    Marcin> something may go wrong earlier in this method (?).

As for the flatten stuff, all I can say is it involves how flatten
works in the presence of generators (the plot code ultimately uses a
generator when building a list of lines) and John Gill and I worked
pretty hard to make this robust and correct at the legend sprint at
pycon.  In the absence of a specific use case that breaks legend, I'm
assuming this code is correct.


    Marcin> Thanks for explaination. I guessed it works like this
    Marcin> after finding what 'hold' is in Matlab. I just meant to
    Marcin> say that such explaination could be helpful in mpl
    Marcin> documentation.

Done.

    Marcin> Yes, I've seen all the examples and they are very
    Marcin> useful. However wxPython demo is more useful than just a
    Marcin> set of examples: examples are grouped in categories, every
    Marcin> example has a detailed documentation about introduced
    Marcin> features. From wx demo overview:

Yes, this would be useful.  Any documentation you would like to add as
header strings to the examples will be most welcome!

JDH

>>>>> "Florent" == Florent Rougon <f.r...@fr...> writes:

    Florent> So, bar() does what I need. There is still one somewhat
    Florent> weird thing, however: barh() (as the barv() I wrote based
    Florent> on barh()) works with the *centers* of the bars
    Florent> (y-coordinates for barh(), x-coordinates for barv())
    Florent> whereas bar() expects the *left* x-coordinates of the
    Florent> bars in its first argument. This is not a drama, but a
    Florent> bit inconsistent.

Yes, this is a historical artifact.  bar was implemented first (and
wrong) and the coords represented left rather than center.  barh came
along later and decided rather than follow bar's mistake lead (a
foolish consistency and all that), it would do it right and bar could
be fixed later in a way that hopefully preserves backward
compatibility (eg an rc param and a warning) for a while.

This would all be fairly trivial except table is based on bar, and the
table layout is pretty complex.  I "fixed" bar but broke table, and
seeing no easy fix, unrolled the changes to bar. And that is where I
left this problem last time I looked.

Would you mind filing a bug report on the sf site, with example code
that shows the different behaviors of bar and barv, including a link
to this discussion.

Thanks,
JDH

On Thursday 05 May 2005 11:44 pm, John Hunter wrote:
[...]
>
> The next task is to take a set of fonts and build a mapping from
> unicode index to fontname, glyph index.  This will require some
> mastery of ft2font.  Last time I was working on this I wrote
> examples/font_indexing.py, mainly as a reminder to myself, on how to
> use the module to extract the relevant information from font files,
> character names, glyph indexes and character codes.  I now wish I had
> added more comments <wink>.  You may want to try this example, read
> over it, and make sure you understand what it is doing (add comments
> as you learn and commit the updates to CVS).


Traceback (most recent call last):
  File "font_indexing.py", line 36, in ?
    print 'AV', font.get_kerning(glyphd['A'], glyphd['V'])/64.0
IndexError: Unexpected SeqBase<T> length.

I had to make a change to font_indexing.py, the call to get_kerning() needed a 
kerning mode parameter. This will output information that can be compared 
with values reported by fontforge:

print 'AV', font.get_kerning(glyphd['A'], glyphd['V'], KERNING_UNSCALED)
print 'AA', font.get_kerning(glyphd['A'], glyphd['A'], KERNING_UNSCALED)

The results are:
Vera: (same in fontforge)
AV -131
AA 57
VeraSe: (same in fontforge)
AV -102
AA 0
FreeSerif:
AV 0.0  (-131 according to fontforge)
AA 0.0
FreeSans:
AV 0.0  (-75 according to fontforge)
AA 0.0

PostScript output using the freefont afm's also appears to not be kerned, 
which I dont understand. 

Darren

I am continuing to make progress reproducing Baptiste's results. I am now at 
the final step of his tutorial, I have been able to generate a postscript 
file using afm fonts, by editing the strings as he suggested. On my system, 
~/.fonts is on the gs path, so I stuck the Free*.ps files there and renamed 
them.

One note. The postscript file renders well, but I had trouble converting it to 
a pdf with ghostscript-7.07. Some of the glyphs would render right on top of 
each other, here is an example where I tried to render 
\hbar\hbar\hbar\hbar\omega\omega\omega\omega\hbar\omega\hbar\omega:
http://people.ccmr.cornell.edu/~dd55/matplotlib/unicode/useafm.ps
http://people.ccmr.cornell.edu/~dd55/matplotlib/unicode/useafm.pdf

I ended up uninstalling the GPL'd ghostscript and installed the AFPL verion 
8.51. After that, ps2pdf worked as expected.

Darren

On Saturday 07 May 2005 10:46 pm, Darren Dale wrote:
>
> At this point, I was not able to save a ps figure with ps.useafm=True. I
> get the following error
[...]
> KeyError: 295

I was able to work through this problem this morning, it was an issue with 
fontforge: inexperienced operator.

> If we try to look at our figure now, ghostscript will complain about
> '/rangecheck yada yada' and fail to display the figure. This is because
> postscript doesn't understand utf-8 encoding.
> Postscript does however understand unicode hexa codes. So we have to replace
> (R(\316\251))    [ octal representation of utf-8 characters ]
> with
> <0052002803a90029>    [ each 4 hexa figures are one character ]
> For now, we have to do that manually in our favorite text editor. To compute
> the hexa code in python, we do:
>  >>> unistr=u'R(\u03a9)'
>  >>> print ('<'+'%04x'*len(unistr)+'>') % tuple([ord(c) for c in unistr])

I tried replacing the characters in my ps file, but was not able to render the 
characters. Would you mind sending me your file, so I can see what you did?

> Producing pretty PDFs is well and nice, but most publishers will ask for
> .eps with all fonts embedded. So we have to embed the fonts into the .eps
> file. I could find no program to do this. DO NOT use gs -sDEVICE=pswrite
> for that. Not only will ghostscript mangle the fonts, but also the plots 
(!).
> 
> Luckily, the FreeSans.ps from above is already a postscript with embedded
> fonts, so we are golden. Just cat the font files together with the .eps
> and merge the headers and footers by hand.
> 
> [ It would be nice to have a ps.embedfonts preference. For Type 0, this is
> easy, as above; I don't know for Type 1. Also, it would be good to embed
> only the needed glyphs, but I haven't looked at how to do it ]

I slept on exactly these considerations last night. I was thinking that we 
should embed only the needed glyphs, and it should not be optional. The 
output has to be portable. Embedding AFM fonts should also take care of the 
PostScript kerning issues we have been talking about.

-- 
Darren S. Dale

Bard Hall
Department of Materials Science and Engineering
Cornell University
Ithaca, NY. 14850

dd...@co...

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

> I think what you are looking for is the "bar" function --
> http://matplotlib.sf.net/matplotlib.pylab.html#-bar.  See
> examples/barchart_demo.py.
>
> Or do I misundertand what you are after..

You understood well, thank you. I was confused because at first, when I
looked at hist(), I saw that its argument 'bins' can be a sequence. From
that, I inferred that non-uniform widths were allowed for the bins.
After testing and reading the code, I understood this was wrong. Then, I
quickly looked at Axes.bar's docstring, since it was used in hist(), and
its beginning:

        BAR(left, height, width=0.8, bottom=0,
            color='b', yerr=None, xerr=None, ecolor='k', capsize=3)

        Make a bar plot with rectangles at

          left, left+width, 0, height

        left and height are Numeric arrays.

made me think that 'width' could only be a float, not an array.

So, bar() does what I need. There is still one somewhat weird thing,
however: barh() (as the barv() I wrote based on barh()) works with the
*centers* of the bars (y-coordinates for barh(), x-coordinates for
barv()) whereas bar() expects the *left* x-coordinates of the bars in
its first argument. This is not a drama, but a bit inconsistent.

Thanks.

-- 
Florent

>>>>> "Florent" == Florent Rougon <f.r...@fr...> writes:
    Florent> direction. Therefore, I wrote its twin sister,
    Florent> Axes.barv(), based on Axes.barh(). The patch included in

I think what you are looking for is the "bar" function --
http://matplotlib.sf.net/matplotlib.pylab.html#-bar.  See
examples/barchart_demo.py.

Or do I misundertand what you are after..

JDH

On Saturday 07 May 2005 10:46 pm, Darren Dale wrote:
> >
> > Now it's time to produce a PDF. Run ps2pdf on one of the plots above,
> > at look at the ugly Type 3 fonts in your prefered PDF viewer.
> > The only way to get decent PDF is to set ps.useafm to True again.
>
> I copied my ttf fonts to matplotlib/fonts/ttf/, and reinstalled MPL from
> CVS. At this point, with ps.useafm=False, I was able to generate a pdf with
> really nice looking fonts. How were your fonts ugly?

I take that back, the fonts look nice in Adobe Reader 7, but not so good in 
kpdf.

Baptiste,

Thank you so much for this tutorial. It was very easy to follow. I have a 
couple of comments sprinkled through the instructions

On Wednesday 20 April 2005 7:13 pm, Baptiste Carvello wrote:
> Hello,
>
> I've been playing with the unicode rendering code that got added in
> matplotlib 0.74. All tests have been done on Linux with the 0.74-1
> debian package, lazy me... They should work on any platform, but you
> will have to find out the gory details (!).
>
> [ Most of these are examples, but there are a few remarks for the ps
> backend maintainers mostly, enclosed in square brackets in the text. No
> patches yet, but if you find the ideas useful, I can give it a try later. ]
>
> To try this out, you may also need the rather complete FreeFont unicode
> font: 1) download the ttf from
>     http://savannah.nongnu.org/download/freefont/freefont-ttf.tar.gz
> 2) put the .ttf files in your prefered Truetype fonts directory
> 3) remove ~/.ttffont.cache
> 4) restart matplotlib
>
> Part I: Guess what I do for a living
>
> Get your favorite interactive backend and display pretty plots
>
>  >>> plot([0.3,0.01,-0.01,-0.01,-0.1,-0.1,-0.3,-0.01,0.01,0.01,0.1,0.1,0.3]
>  >>>,\
>
> ... [105,100,98,90,92,101,105,100,98,90,92,101,105],'kD-')
>
>  >>> ylim(85,110)
>  >>> xlabel(u'\u03bc\u2080H(T)', name='FreeSans')
>  >>> ylabel(u'R(\u03a9)', name='FreeSans')
>  >>> ^D
>
> or weird formulas
>
>  >>> figtext(0.5,0.5,u'\u0127\u03c9 \u226a k\u0432T',name='FreeSerif',\
>
> ... size=30, ha='center', va='center', color='r')
>
>  >>> ^D
>
> You can also save to svg, and even to postscript (or eps) provided you set
> the ps.useafm preference to False for now.
>
> Part II: All work and no play...
>
>  >>> plot([0.3,0.01,-0.01,-0.01,-0.1,-0.1,-0.3,-0.01,0.01,0.01,0.1,0.1,0.3]
>  >>>,\
>
> ... [105,100,107,90,92,101,105,100,98,90,92,101,105],'kD-')
>
>  >>> ylim(85,110)
>  >>> text(-0.01,107,u'   \u261c booh! the ugly
>  >>> artifact!',name='FreeSerif',\
>
> ... size=20, va='top', ha='left')
>
>  >>> ^D
>
> ;-)
>
> Part III: Ugly, dirty and mean
>
> Now it's time to produce a PDF. Run ps2pdf on one of the plots above,
> at look at the ugly Type 3 fonts in your prefered PDF viewer.
> The only way to get decent PDF is to set ps.useafm to True again.

I copied my ttf fonts to matplotlib/fonts/ttf/, and reinstalled MPL from CVS. 
At this point, with ps.useafm=False, I was able to generate a pdf with really 
nice looking fonts. How were your fonts ugly?

>
> For this to work, we have to provide the AFM files for FreeFont:
> 1) download the source of the font from:
>     http://savannah.nongnu.org/download/freefont/freefont-sfd.tar.gz
> 2) download fontforge from fontforge.sourceforge.net
> 3) open each .sfd file in freefont, and run File\Generate Fonts;
>     choose type 'PS Type 0'; this should produce a corresponding
>     .afm and .ps file; save the .ps file for later.


This was a little confusing, I think it should read 'open each .sfd file in 
fontforge, and run ...' I was able to generate afm and ps files, but I think 
something went wrong (see below). Did you have any trouble with this step? 


> 4) move the afm file to a directory which is searched by matplotlib.
>     Any subdirectory of /usr/share/fonts/ will do, provided said
>     subdirectory is not a symlink
>     [ is this a bug ? the implementation is in lib/font_manager.py,
>       function x11FontDirectory(); os.path.walk() ignores symlinks ]
> 5) remove ~/.afmfont.cache
> 6) restart matplotlib
> 7) when you save the first .ps figure, the cache is rebuilt

At this point, I was not able to save a ps figure with ps.useafm=True. I get 
the following error, maybe fontforge had trouble generating the afm files? 

At any rate, these fonts look really great. I'm going to start working on the 
unicode mappings so you can do '$\hbar$' instead of u'\u0127'. Again, thanks 
for the tutorial! Can we commit the freefont ttf's to CVS?

Darren


/usr/lib/python2.4/site-packages/matplotlib/pylab.py in savefig(*args, 
**kwargs)
    738 def savefig(*args, **kwargs):
    739     fig = gcf()
--> 740     return fig.savefig(*args, **kwargs)
    741 if Figure.savefig.__doc__ is not None:
    742     savefig.__doc__ = Figure.savefig.__doc__

/usr/lib/python2.4/site-packages/matplotlib/figure.py in savefig(self, *args, 
**kwargs)
    515                 kwargs[key] = rcParams['savefig.%s'%key]
    516
--> 517         self.canvas.print_figure(*args, **kwargs)
    518
    519

/usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtkagg.py in 
print_figure(self, filename, dpi, facecolor, edgecolor, orientation)
     89         else:
     90             agg = self.switch_backends(FigureCanvasAgg)
---> 91             try: agg.print_figure(filename, dpi, facecolor, edgecolor, 
orientation)
     92             except IOError, msg:
     93                 error_msg_gtk('Failed to save\nError message: 
%s'%(msg,), self)

/usr/lib/python2.4/site-packages/matplotlib/backends/backend_agg.py in 
print_figure(self, filename, dpi, facecolor, edgecolor, orientation)
    403                 from backend_ps import FigureCanvasPS # lazy import
    404                 ps = self.switch_backends(FigureCanvasPS)
--> 405                 ps.print_figure(filename, dpi, facecolor, edgecolor, 
orientation)
    406             else:
    407                 raise IOError('Do not know know to handle extension 
*%s' % ext)

/usr/lib/python2.4/site-packages/matplotlib/backends/backend_ps.py in 
print_figure(self, outfile, dpi, facecolor, edgecolor, orientation)
    909         self._pswriter = StringIO()
    910         renderer = RendererPS(width, height, self._pswriter)
--> 911         self.figure.draw(renderer)
    912
    913         self.figure.set_facecolor(origfacecolor)

/usr/lib/python2.4/site-packages/matplotlib/figure.py in draw(self, renderer)
    393
    394         # render the axes
--> 395         for a in self.axes: a.draw(renderer)
    396
    397         # render the figure text

/usr/lib/python2.4/site-packages/matplotlib/axes.py in draw(self, renderer)
   1358
   1359         for zorder, i, a in dsu:
-> 1360             a.draw(renderer)
   1361
   1362         self.title.draw(renderer)

/usr/lib/python2.4/site-packages/matplotlib/text.py in draw(self, renderer)
    315
    316             return
--> 317         bbox, info = self._get_layout(renderer)
    318
    319         for line, wh, x, y in info:

/usr/lib/python2.4/site-packages/matplotlib/text.py in _get_layout(self, 
renderer)
    162         whs = []
    163         for line in lines:
--> 164             w,h = renderer.get_text_width_height(
    165                 line, self._fontproperties, 
ismath=self.is_math_text())
    166             if not len(line) and not self.is_math_text():

/usr/lib/python2.4/site-packages/matplotlib/backends/backend_ps.py in 
get_text_width_height(self, s, prop, ismath)
    191             if ismath: s = s[1:-1]
    192             font = self._get_font_afm(prop)
--> 193             l,b,w,h = font.get_str_bbox(s)
    194
    195             fontsize = prop.get_size_in_points()

/usr/lib/python2.4/site-packages/matplotlib/afm.py in get_str_bbox(self, s)
    315         for c in s:
    316             if c == '\n': continue
--> 317             wx, name, bbox = self._metrics[ord(c)]
    318             l,b,w,h = bbox
    319             if l<left: left = l

KeyError: 295

PS: it seems you cannot specify the color as an RGB tuple, contrary to
    what the comments suggest. At least, I didn't manage to do it, and
    the bug is most probably also in Axes.barh() since the code for this
    part should be unchanged. No time to investigate, sorry.

-- 
Florent

On Thu, 5 May 2005, John Hunter wrote:

> OK, could you resend a patch against CVS?
> 

It is attached. There are two comments-questions in the patch,
please delete them after reading.
And at the end of this patched legend() method there is a line
handles = flatten(handles)
If handles are not already flat, I think something may go wrong
earlier in this method (?).


>     Marcin> BTW when I was reading mpl docs I stopped for a while on
>     Marcin> description of 'hold'. I'm not used to Matlab and didn't
>     Marcin> understand what is "hold state".  (I found it out in
>     Marcin> Matlab docs).
> 
> When hold is True, subsequent plot commands will be added to the
> current axes.  When hold is False, the current axes and figure
> will be cleared on the next plot command

Thanks for explaination. I guessed it works like this after finding
what 'hold' is in Matlab. I just meant to say that such explaination
could be helpful in mpl documentation.

>     Marcin> 2. something like wxPython demo,
>     Marcin> that contains all the examples
> 
>  2) Have you seen the examples directory in the matplotlib src
>     distribution, and is also available here
>     http://matplotlib.sourceforge.net/matplotlib_examples_0.80.zip ?
>     Or do you mean something else?

Yes, I've seen all the examples and they are very useful. However wxPython
demo is more useful than just a set of examples: examples are grouped
in categories, every example has a detailed documentation about 
introduced features. From wx demo overview:

"""
This demo is not only a collection of test cases for wxPython, but is also 
designed to help you learn about and how to use wxPython. Each sample is 
listed in the tree control on the left. When a sample is selected in the 
tree then a module is loaded and run (usually in a tab of this notebook,) 
and the source code of the module is loaded in another tab for you to 
browse and learn from. 
"""

Marcin

-- 
Marcin Wojdyr  |  http://www.unipress.waw.pl/~wojdyr/