py2exe wisdom

As I was building a py2exe distribution of matplotlib, I noticed the
function get_py2exe_datafiles() in __init__.py that is not noted on
the FAQ.  Before I update the FAQ, can you all tell me your best
practices recommendations for wrapping matplotlib?

In particular, is there a way I can store the matplotlib data directly
in the exe so that install is simply a matter of copying an exe file
rather than a whole directory?

Technically this should be feasible --- freetype can load fonts
from memory or directly from the zip file given the proper driver,
and the various images should be similarly readable.

	- Paul

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: py2exe wisdom

Paul Kienzle wrote:
> Technically this should be feasible --- freetype can load fonts
> from memory or directly from the zip file given the proper driver,
> and the various images should be similarly readable.

ttconv will have to be likewise updated (probably to accept a Python 
file-like object).  It is currently hardcoded to only accept file paths 
and do its own reading using the C stdlib.

The Cairo backend will also be unable to use fonts this way (but that's 
only a minor change from how it is now -- Cairo can only read fonts from 
normal OS-specific font installation directories anyway.)

Personally, I'd prefer to see the fonts installed in a OS standard place 
-- then matplotlib could use fontconfig effectively on X11 systems and 
Cairo would function like all the other backends.  But that probably 
means having a proper installer on Windows/Mac and being a little more 
clever with packaging on Linux.

As for images, you could take the approach suggested by wxPython's img2py:

   http://www.wxpython.org/docs/api/wx.tools.img2py-module.html

There is nothing wx-specific about the concepts there...  But I'm not 
sure it's necessary if all of the backends can load images from strings 
anyway.

Cheers,
Mike

Re: dviread: usetex for the PDF backend

On Sunday 30 September 2007 04:16:08 pm Jouni K. Seppänen wrote:
> It turns out (thanks to Darren for the debug info) that AFM files do not
> exist for all fonts in all current TeX distributions, so I have modified
> the pdf backend to not use them. This loses some information that is
> required by the pdf spec (such as the x-height and stem widths of the
> embedded font) but at least in some tests Preview.app and Adobe Reader
> don't seem to mind.

Jouni, I just ran tex_demo.py, which I modified to  yield a pdf. The results 
are really impressive. In an earlier post you mentioned that transformations 
of Type-1 fonts probably requires a complete type-1 parser. Do you mean 
matplotlib's ft2font is missing some functionality?

Darren

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: dviread: usetex for the PDF backend

Darren Dale <dd55@...> writes:

> In an earlier post you mentioned that transformations of Type-1 fonts
> probably requires a complete type-1 parser. Do you mean matplotlib's
> ft2font is missing some functionality?

I don't think freetype has any support for modifying and outputting
fonts. Actually the transformations are probably just a matter of
locating and modifying the FontMatrix entry in the cleartext part of the
pfb file, but subsetting (to reduce file sizes) is more involved.

--

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

API additions

James,

I see that you have implemented a strategy change in axes.py for 
inverted axes, with corresponding additions to the API.  I don't have 
strong opinions about the strategy.  Keeping track of orientation via a 
flag is reasonable, although I'm not positive it is better, given that 
it complicates the API.  My first reaction to the new API is at best 
lukewarm, however, so perhaps it is worth a bit of thrashing out on the 
list.

What you have now (and similarly for yaxis):

+    def invert_xaxis(self, invert=True):
+        "Invert the x-axis if 'invert' is True."
+        self._invertedx = invert
+
+    def xaxis_inverted(self):
+        'Returns True if the x-axis is inverted.'
+        return self._invertedx

Some alternatives:

1) Attributes (could later be properties or those terrifying traits):
     x_right=True or False
     y_up

     xdir    'right' or 'normal' or True; vs 'left' or 'reversed' or False
and similarly for ydir

2) Getters and setters:

Re: API additions

James,

In principle, I'm not against adding a new API for this as long as the 
old one doesn't break.

I just have the usual concerns that callers of get_xlim/get_ylim don't 
break because of this.  The things I've tried so far seem to be working, 
but all calls to get_xlim/get_ylim should be tested exhaustively, to 
make sure that none of them depend on xmin > xmax when the axis is inverted.

 From the point of view of the transforms refactoring megabranch I'm 
working on, my only concern is that viewLim stays as-is -- that is, if 
the axis is inverted, then the values in viewLim are also inverted. 
That appears to be how you've kept things in your change -- I'd just 
like to put in my vote for that remaining the case regardless of where 
this discussion about API goes.

There does seem to be one small logic bug in the change.  If I invert 
the axis (in the old way), I can't then uninvert it in the old way:

axes().set_xlim(0.5, -0.5)
axes().set_xlim(-0.5, 0.5)
# The x-axis is still inverted

I think we have to keep this API working as-is (as it's a pretty common 
one), even if we extend it with invert_xaxis.  One possible solution may 
be to not change set_xlim at all, and make get_xlim, invert_xaxis, and 
xaxis_inverted more dynamic, i.e. don't use a _invertedx flag [untested 
code warning]:

Re: py2exe wisdom

On Tue, Oct 02, 2007 at 10:42:13AM -0400, Paul Kienzle wrote:
> As I was building a py2exe distribution of matplotlib, I noticed the
> function get_py2exe_datafiles() in __init__.py that is not noted on
> the FAQ.  Before I update the FAQ, can you all tell me your best
> practices recommendations for wrapping matplotlib?
> 
> In particular, is there a way I can store the matplotlib data directly
> in the exe so that install is simply a matter of copying an exe file
> rather than a whole directory?
> 
> Technically this should be feasible --- freetype can load fonts
> from memory or directly from the zip file given the proper driver,
> and the various images should be similarly readable.

For the record, here is what I'm using to wrap matplotlib in py2exe.

Since I'm using the wx backend I've excluded Tkinter.  

Since numerix uses __import__, py2exe wasn't clever enough to find the 
numerix extensions, and had to be listed explicitly.  Similarly 
for backends.

I'm not picking up the 14Mb of timezone info that I don't need.  Maybe
want packages = ['pytz'] if your applications need it.

I haven't addressed mpl-data yet.

	- Paul

myapp.py

Re: API additions

On 10/4/07, Michael Droettboom <mdroe@...> wrote:

>      def invert_xaxis(self, invert=True):
>
>          "Invert the x-axis if 'invert' is True."
>

I like this approach over a state flag (I agree with Eric that it
would be nice to avoid if we can since it complicates communication
between different parts of the Axes and Axis code).  But why do we
need an invert kwarg.  I would imagine that invert_xaxis might work
like

def invert_xaxis(self):
    left, right = self.get_xlim()
    self.set_xlim(right, left)

then you could toggle back and forth

and xaxis_inverted would work as you propose.

JDH

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: API additions

On 10/4/07, Ted Drain <ted.drain@...> wrote:
> John,
> I think that the problem isn't doing the inversion - it's keeping
> it.  Calling set_xlim() to invert is fine - but it never seems to
> stay that way.  There is a lot of code (resizing, autoscaling,
> labelling, etc) that has a tendency to flip the axis back to it's
> 'un-inverted' state.  The idea behind having a flag on the axis
> itself is so that other code can check that easily to see what the
> state of the axis is.
>

> We do a lot of plots that require an inverted axis and we've had tons
> of problems keeping the axis inverted (which is where the idea for
> the flag came from).  It seems like people forget that this is
> possible and add code that assumes that xmin < xmax which then ends
> up flipping the axis back to it's "normal" state (this happens in the
> aspect ratio code for example).

I see -- I missed James' original email describing the motivation for
this flag because it was in spam quarantine (I think he posted from a
non-subscribed address).  As I was just  clearing out the spam, I
noticed it, and now better understand what you are trying to do.  It
seems like a reasonable use case.

If I am reading this right, there is no way to support this kind of
behavior *and* not break existing code.  If we want to go this route,
I don't mind breaking existing code as long as we do it cleanly.  Eg,
I think xmin and xmax should always be in order (calls to
set_xlim(xmax, xmin) would raise a helpful exception like "call
ax.invert_xaxis instead") and we would need to make sure that the

Re: API additions

John,
I think keeping the existing API is probably a good idea.  What about 
something like this:

- Keep xlim and viewlim as they are.

- Add xbound() (or maybe a better name) that returns (x1,x2) where x1 < x2.

- Add set_xbound(x1,x2) that takes x1<x2, checks the inversion flag, 
and then calls set_xlim() w/ the args in the proper order.

- Change the existing axis code that messes w/ bounds (autoscale, 
aspect ratio, etc) to use xbound.  These algorithm can then be 
written so they're independent of the order of x1 and x2 and they 
won't flip the bounds back if the inversion flag is set.

Ted

At 08:05 AM 10/4/2007, John Hunter wrote:
>On 10/4/07, Ted Drain <ted.drain@...> wrote:
> > John,
> > I think that the problem isn't doing the inversion - it's keeping
> > it.  Calling set_xlim() to invert is fine - but it never seems to
> > stay that way.  There is a lot of code (resizing, autoscaling,
> > labelling, etc) that has a tendency to flip the axis back to it's
> > 'un-inverted' state.  The idea behind having a flag on the axis
> > itself is so that other code can check that easily to see what the
> > state of the axis is.
> >
>