matplotlib-devel Mailing List for matplotlib

>>>>> "Jochen" == Jochen Voss <vo...@se...> writes:

    Jochen> Hello, I found what I believe is bug in matplotlib.  The
    Jochen> program
    Jochen> displays a graph, where the xlabel is shifted to much
    Jochen> down.  Only the upper half of the xlabel is still visible,
    Jochen> the lower half is outside the visible area.

    Jochen> Is this a bug?  Or do I need to somehow manually reserve
    Jochen> space for the display of the xlabel?

See http://matplotlib.sf.net/faq.html#TEXTOVERLAP

Basically the subplots are fixed sizes - they don't automatically
adjust in response to the items placed on or around them.  One could
write a layout engine to do this, but there isn't one current.  You
have to adjust parameters as described in the link above.

JDH

>>>>> "Jochen" == Jochen Voss <vo...@se...> writes:

    Jochen> Hello, I did some clean-up of the matplotlib PostScript
    Jochen> backend.  Main changes:

    Jochen>   - The generated Postscript output is now completely DSC
    Jochen> conformant (I hope).

Great - everyone should take this for a test drive with their favorite
PS viewers before the next release.

    Jochen>   - All PostScript definitions go into a a PostScript
    Jochen> dictionary mpldict instead of the global one.  This will
    Jochen> hopefully prevent problems (name clashes) when including
    Jochen> matplotlib generated eps files into other PostScript files

    Jochen>   - I moved 1.5kb of comments about drawing ellipses from
    Jochen> the generated PostScript into a Python source code
    Jochen> comment.  I think it does not make sense to ship the
    Jochen> comment in each and every genereated picture.

Makes sense to me...

    Jochen> Hopefully I did not cause any new problems.  Comments
    Jochen> about the changes are most welcome.

One other PS quasi-bug you may want to be aware of is the way truetype
fonts are embedded.  The basic problem is that Paul couldn't find a
way to access the individual glyph information so ended up having to
embed the entire font.  For mathtext, with multiple fonts (which is
typical) this makes for large ps files.  It would be nice to just
embed only the required glyphs.  I believe this information is may be
available in face->glyph->outline - see also FT_Outline in the
freetype API abd agg22/font_freetype/agg_font_freetype.cpp which makes
use of this glyph info in decompose_ft_outline.

I haven't looked into this extensively, but I think it should be
possible.  This would help on mathtext for SVG, for which I believe we
require the individual glyph information.

JDH

>>>>> "Jochen" == Jochen Voss <vo...@se...> writes:

    Jochen> Hello, currently I am having a closer look at the
    Jochen> PostScript backend.  Some questions occurred to me:

    Jochen> 1) What is the meaning of 'backend_version'?  When should
    Jochen> it be increased/changed?

Eg, for gtk this would be the version of pygtk, for wx the version of
wxpython.  It is mainly used to provide us diagnositic information to
help when users post problems on the mailing list.  If they run with
--debug-helpful, we get the version info.  It is not the same as the
matplotlib version, which is reported separately.  For PS, it seems
that it should be the PS level that is required (PS level I, level
II).  But it could also be 'not applicable'.  If you can think of
something that makes sense, use it.

    Jochen> 2) Is the following code the correct way to get the
    Jochen> matplotlib version for use in a backend file:

    Jochen>     from matplotlib import __version__ version=__version__

Looks right to me; you could also do

from matplotlib import __version__ as version

    Jochen> 3) The draw_lines method checks whether the argument
    Jochen> arrays are of the same size as required.  The other
    Jochen> functions do not do any sanity checks on the arguments.
    Jochen> Can the renderer methods assume that they are called with
    Jochen> semantically correct arguments?  Is it ok to fail with an
    Jochen> Python exception otherwise?

Yes on both cases, me thinks.

    Jochen> 4) Can the PostScript code assume that each file contains
    Jochen> only one picture/page?  Might this change in the future?

I say yes.  I can't imagine changing this, but perhaps someelse who is
more imaginative than I could.

    Jochen> 5) Does matplotlib have the concept of a picture title
    Jochen> which could be written into the DSC "%%Title" comment?  If
    Jochen> the answer is yes: how do I get this title?

Well, there is a figure title and an axes title.  It would be easy to
add a renderer method called set_title which is called by figure.draw
and axes.draw.  The problem here is that although there *is* a figure
title (see matplotlib.matlab.figtitle) the most common way to set
titles is via matplotlib.matlab.title which sets the title of the
current axes.  Hence you could have multiple titles.  One solution,
that will work in 95% of the cases, is just to use the first call to
set_title in the renderer and ignore subsequent calls.  This will get
the figure title if there is one, and the first axes title if there
isn't.

    Jochen> Also I have some questions about the template backend in
    Jochen> backend_template.py:

    Jochen> 6) The template backend contains the line

    Jochen>     from matplotlib.transforms import Bbox

    Jochen>    Does this have any function or should it be removed?

It can be removed.

    Jochen> 7) The template backend uses

    Jochen>     verbose.report('Error: %s'%msg)

    Jochen>    Should this be 'verbose.report_error' instead?

Yes.

    Jochen> Sorry about having so many questions, Jochen --

Thanks!

JDH

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> John, I think the doc string for points_to_pixels() in
    Steve> backend_bases.py and backend_template.py should be updated
    Steve> define its return type.  Does points_to_pixels() return
    Steve> int, float, or float if the backend supports it (agg) else
    Steve> int (gtk)?

I think this should be a float return type, to leave issues of
rounding to the last minute when the backend renderer gets the coords
for drawing.  Eg, lines.py uses this information to draw line with
lengths in points - you might imagine a situation where the backend
round one way or the other depending on the two end points of the
line.  If the points were rounded first, this would not be possible.
If you agree with this, go ahead and update the doc string.

As I mentioned earlier, I'm looking into refactoring the backend
drawing model so that the transformations happen in the backend, which
would obviate some of these problems.

JDH

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

Hi Steve, 

    >> 7) The template backend uses=20
    >> 
    >> verbose.report('Error: %s'%msg)
    >> 
    >> Should this be 'verbose.report_error' instead?

Yes.

    Steve> No verbose() at all! But I agree I think it should be
    Steve> 'verbose.report_error'

Yes, it should.  All printing should either go to verbose.report or
verbose.report_error, so that the user specified output handles are
used.  This was just an oversight in backend_bases.error_msg.
Everyone should feel free to fix these as they find them.

Of course, GUI backends are an exception, where the error messages go
to the dialog box, as you noted.

    >> Also, there is a new PS backend now. I've been working on
    >> backend_cairo.py and today got it producing its own png and PS
    >> files.

Great - there have been a number of people who've been interested in a
cairo backend since the earliest days.  When you get the thing so that
you're happy with it, you might want to search for cairo on the
mailing list and let these people know there is one.

Thanks!
JDH

Hello,

On Sun, Oct 31, 2004 at 10:09:55PM +0800, Steve Chaplin wrote:
> backend_bases has:
> def error_msg(msg, *args, **kwargs):
>     """
>     Alert an error condition with message
>     """
>     print >>sys.stderr, msg
>     sys.exit()
>=20
> No verbose() at all! But I agree I think it should be
> 'verbose.report_error'=20
Yes, it seems that this makes sense in the non-interactive case.
We are aborting the program, so the message should be visible
in any case.

> Also, there is a new PS backend now. I've been working on
> backend_cairo.py and today got it producing its own png and PS files.
Cool!

All the best,
Jochen
--=20
http://seehuhn.de/

> 7) The template backend uses=20
> 
>     verbose.report('Error: %s'%msg)
> 
>    Should this be 'verbose.report_error' instead?

I was looking at this too, earlier today, because it was giving me a
problem - it was exiting without the error message being printed.

I looked to see how backend_agg handles errors and deleted it because I
don't think its even needed.
With a GUI backend you can popup an error message window.
With a non-GUI backend you can simply use
"from matplotlib.backend_bases import error_msg" as backend_agg does.

backend_bases has:
def error_msg(msg, *args, **kwargs):
    """
    Alert an error condition with message
    """
    print >>sys.stderr, msg
    sys.exit()

No verbose() at all! But I agree I think it should be
'verbose.report_error' 

Also, there is a new PS backend now. I've been working on
backend_cairo.py and today got it producing its own png and PS files.

Regards,
Steve