matplotlib-devel Mailing List for matplotlib (Page 535)

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

    Jochen> Hello, why is figure derived from the Artist class?  This
    Jochen> causes some special casing (figure is the only artist
    Jochen> where artist.figure does not point to the figure).

    Jochen> The the figure actually used as an Artist somewhere?  What
    Jochen> would break if it would not be derived from Artist?

In a couple of places - in the call to set_transform in
Figure._set_artist_props and when FigureCanvas calls
figure.draw(renderer).  One could write a figure class that was not
derived form Artist, but I don't really see the benefit of changing
it.  The Artist hierarchy are basically all the things that implement
draw(renderer).  Of course in a dynamically typed language one doesn't
need to derive from Artist to implement draw(renderer), but it seems
conceptually cleaner to do so in this case -- plus I have already done
the Artist hierarchy in graphviz and included it in the users guide
:-)

It might also break some code which is relying on the Artist methods,
eg fig.get_transform (for people who want to add lines, text, etc in
fig coords).  I doubt there are many such people, but it is a
possibility.

    Jochen> I tried the patch

I didn't test this - did it pass backend_driver?

JDH

On Wed, 2004-11-03 at 12:48,
mat...@li... wrote:
> Message: 1
> Date: Tue, 2 Nov 2004 17:34:00 +0000
> From: Jochen Voss <vo...@se...>
> To: mat...@li...
> Subject: Re: [matplotlib-devel] questions about the PS backend
> 
> 
> --ZPt4rx8FFjLCG7dd
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> Hello,
> 
> On Sun, Oct 31, 2004 at 10:33:27AM -0600, John Hunter wrote:
> >     >> 7) The template backend uses=3D20
> >     >>=20
> >     >> verbose.report('Error: %s'%msg)
> >     >>=20
> >     >> Should this be 'verbose.report_error' instead?
> >=20
> > Yes.
> >=20
> >     Steve> No verbose() at all! But I agree I think it should be
> >     Steve> 'verbose.report_error'
> >=20
> > 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.
> Then the recent change to error_msg_template should be reverted,
> shouldn't it?
> 
> All the best,
> Jochen
I had the problem of error_msg() being called, executing
verbose.report('Error: %s'%msg) and no message being reported. I checked
how backend_agg handles errors and deleted verbose.report() and updated
the doc string to be consistent with the way agg uses error_msg().

We now have 'verbose' and error_msg() which both report errors. The
difference is that error_msg() has the side-effect of terminating your
program, which is not necessarily what you expect from its name.
I'd prefer to delete error_msg() completely, use 'verbose' for all
errors and add a 'raise SystemExit()' after it if you need to terminate
the program. I think it would make the code easier to understand.

Steve

Hello,

why is figure derived from the Artist class?
This causes some special casing (figure is the
only artist where artist.figure does not point to
the figure).

The the figure actually used as an Artist somewhere?
What would break if it would not be derived from
Artist?

I tried the patch
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
diff -u -r1.5 figure.py
--- figure.py   21 Oct 2004 19:57:50 -0000      1.5
+++ figure.py   2 Nov 2004 19:35:03 -0000
@@ -13,7 +13,7 @@
=20
=20
=20
-class Figure(Artist):
+class Figure:
    =20
     def __init__(self,
                  figsize   =3D None,  # defaults to rc figure.figsize
@@ -27,7 +27,7 @@
         paper size is a w,h tuple in inches
         DPI is dots per inch=20
         """
-        Artist.__init__(self)
+        #Artist.__init__(self)
         #self.set_figure(self)
=20
         if figsize is None  : figsize   =3D rcParams['figure.figsize']
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
and everything still seems to work.  Maybe a figure
should be just something which uses artists to do its
work instead of being one itself.

What do you think?
Jochen
--=20
http://seehuhn.de/

Hello John,

On Tue, Nov 02, 2004 at 12:41:03PM -0600, John Hunter wrote:
> I think its fine to make the change you suggested -
> while you're in there, I suggest supporting writing to a file object
> as well as a filename, as agg does now.  All backends should support
> this.
Done!

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

Hello John,

On Tue, Nov 02, 2004 at 12:49:28PM -0600, John Hunter wrote:
> I don't know why is was changed (or what it was before).
I think it was just a misunderstanding about how error reporting
is supposed to work.

> def error_msg_template(msg, *args):
>     """
>     Signal an error condition.
>     - in a GUI backend, popup a error dialog.
>     - in a non-GUI backend delete this function and use
>     'from matplotlib.backend_bases import error_msg'
>     """
>     verbose.report_error(msg)
>     raise SystemExist
>=20
> All opposed, say Nay!
I agree with the code, but I am not the sure about the comment.

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

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

    Jochen> Then the recent change to error_msg_template should be
    Jochen> reverted, shouldn't it?

I don't know why is was changed (or what it was before).  I just
checked in 

def error_msg_template(msg, *args):
    """
    Signal an error condition.
    - in a GUI backend, popup a error dialog.
    - in a non-GUI backend delete this function and use
    'from matplotlib.backend_bases import error_msg'
    """
    verbose.report_error(msg)
    raise SystemExist

All opposed, say Nay!

JDH

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


    Jochen> Is there a reason for storing the PostScript data in a
    Jochen> string first?  Otherwise I could just pass the real file
    Jochen> handle to RendererPS and it would write all the stuff
    Jochen> directly into the output file.

The reason I did it (I think) was for efficiency, (wrongly) thinking
it would be faster to write to StringIO than to a file object.  Of
course, file objects buffer their output, so this is not a real
consideration.  I think its fine to make the change you suggested -
while you're in there, I suggest supporting writing to a file object
as well as a filename, as agg does now.  All backends should support
this.

JDH

Hello,

the current way the PostScript backend works is as follows:

  1) FigureCanvasPS.print_figure() uses StringIO to make a string look like
     a file.

  2) The RendererPS class writes the PostScript file (except for the header=
s)
     into this string, using file operations.  This is done via call to
     Figure.draw()

  3) FigureCanvasPS.print_figure() writes the resulting string into the
     output file.

Is there a reason for storing the PostScript data in a string first?
Otherwise I could just pass the real file handle to RendererPS and it
would write all the stuff directly into the output file.

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

Hello,

On Sun, Oct 31, 2004 at 10:33:27AM -0600, John Hunter wrote:
>     >> 7) The template backend uses=3D20
>     >>=20
>     >> verbose.report('Error: %s'%msg)
>     >>=20
>     >> Should this be 'verbose.report_error' instead?
>=20
> Yes.
>=20
>     Steve> No verbose() at all! But I agree I think it should be
>     Steve> 'verbose.report_error'
>=20
> 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.
Then the recent change to error_msg_template should be reverted,
shouldn't it?

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

in backend_agg lines 194 and 211, my application was passing unicodes
which were generating a CXX type error ( expecting a string ).  I put
in a str( .. ) around the 's' arg in these 2 lines and everything
worked. 

i.e.

font.set_text( s, 0.0)  

changed to..

font.set_text( str( s ), 0.0)  

Just a note that unicodes cause a problem going through CXX when a
string is expected.

S




		
__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 
 

On Oct 28, 2004, at 4:58 PM, Robert Kern wrote:

> gary ruben wrote:
>> True, I didn't pay much attention to licencing. In light of it 
>> though, here
>> are a couple more links to a couple of gentlemen who may be worth
>> grovelling to should the need arise. No specific licencing is 
>> mentioned.
>> <http://mahi.ucsd.edu/parker/Software/>
>
> Actually, having seen this code and the gist code, I'd recommend 
> waiting  for the gist-derived prototype.
>
> To muddy the waters a bit, the gist contouring algorithm looks to my 
> eye like Paul Bourke's CONREC algorithm, which may or may not be 
> patented.
>
Which gist contouring routine are you referring to? It appears to use 
two separate
implementations for different contour functions. We are using the code 
in gcntr.c.
If that is based on Bourke's routine, there shouldn't be a problem. 
None of the code
that uses it makes any reference to a patent; there appear to be a 
number of other
implementations, none of which appear to have been challenged. As far 
as patent
rights go, aren't they only good for 17 years? It was published in July 
1987
(though I suppose it may derive from when it was granted, not 
published).
Then there is copyright, but that doesn't guard against 
reimplementation so
long as code isn't copied (But I am not a lawy...).

Perry

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

    Jochen> Hello John,
    Jochen> On Sun, Oct 31, 2004 at 10:54:04AM -0600, John Hunter wrote:
    >> 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. ...
    Jochen> Yes, I know about this.  Let's see whether I can do
    Jochen> anything ...

    Jochen> It would also be nice if I could find a way to use the
    Jochen> printer's built-in fonts if the user wants to.  This
    Jochen> should lead to really small PostScript files and really
    Jochen> high quality printed glyphs.

This is effectively what we were doing before we started embedding PS
fonts in matplotlib (0.61 I believe).  So you can check out a CVS
version prior to that and take a look.  It might be nice to support
this as an rc option, to use afm fonts.  matplotlib has an afm parser
and ships with the standard afm files.

JDH

Hello John,

On Sun, Oct 31, 2004 at 10:54:04AM -0600, John Hunter wrote:
> 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. ...
Yes, I know about this.  Let's see whether I can do anything ...

It would also be nice if I could find a way to use the printer's built-in
fonts if the user wants to.  This should lead to really small PostScript
files and really high quality printed glyphs.

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

>>>>> "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

Hello,

I found what I believe is bug in matplotlib.
The program

    from matplotlib.matlab import *
    from math import sin

    t=3Darange(0,10,0.1)
    x=3Dmap(lambda tt:sin(tt), t)

    figure(figsize=3D(5,3))
    plot(t,x,"k-")
    xlabel("total time")
    ylabel("tatil tome")
    title("titol tame")

    show ()

displays a graph, where the xlabel is shifted to much down.  Only the
upper half of the xlabel is still visible, the lower half is outside
the visible area.

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

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

Hello,

I fixed the problem with the not-quite-correctly text in the PS
backend.  The solution was to shift all the text up by the distance
between the lower edge of the bounding box and the text base line.  I
added a new method to FT2Font, which calculates this distance.
Comments about this are most welcome.

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

Hello,

I did some clean-up of the matplotlib PostScript backend.
Main changes:

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

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

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

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

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

Hello,

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

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

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

    from matplotlib import __version__
    version=3D__version__

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

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

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

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

6) The template backend contains the line

    from matplotlib.transforms import Bbox

   Does this have any function or should it be removed?

7) The template backend uses=20

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

   Should this be 'verbose.report_error' instead?

Sorry about having so many questions,
Jochen
--=20
http://seehuhn.de/

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

Regards
Steve