matplotlib-devel Mailing List for matplotlib

Hello,
I'd like your confirmation on what I see from
http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194&release_id=646644
(the download page ofr 0.98.5 release). on that page I see
1. win binary install
2. .egg file
3. source code
4. mpkg file
Now, correlating with operating systems, we got:
1. windows
2. windows only? <-- that's the doubt I have
3. OS indipendent
4. Mac OS X?
In particular I'm interested in egg files: is "easy_install" only
supported for windows? is there any plan/will to extend it to
linux/other OSes?
I'm just asking because I'd like to give right advices in the book :)
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Jouni K. Seppänen <jk...@ik...> wrote:
> You're right. I committed your patch, but there is another bug that
> makes this a little difficult to test: the font cache doesn't record
> whether it was build with pdf.use14corefonts enabled or not, and the
> font name "Helvetica" happens to match "Helvetica Narrow", whose metrics
> are included with matplotlib, and using that afm file without including
> the font itself breaks the output. I'm too busy with other things to fix
> this now, but patches are welcome. As a workaround, deleting
> ~/.matplotlib/fontList.cache helps if anyone wants to alternate between
> enabling and disabling use14corefonts.
Thanks for committing my patch! I've reproduced the font cache bug on
my machine too. Thanks for your detailed explanation. I've updated the
test case to acknowledge this issue and to set use14corefonts to True
*before* importing pylab (because importimg pylab seems to refresh the
font cache).
Those changes are in the attached patch. It's certainly not a
definitive workaround, but it's better than nothing ;-)
> Unfortunately, this functionality is deprecated in the PDF standard as
> of PDF 1.5, and many publishers require embedding all fonts in PDF
> files. Apparently not all substitutes for the standard fonts are similar
> enough. (The real fonts need to be licensed, so many Linux distributions
> ship with free look-alike substitutes, and who knows what fonts are
> installed on some publisher's systems.)
I'm aware of that deprecation. I agree we'll need to drop that feature
in a not so distant future...
--
Nicolas Grilly

> I will have a look at the code for both PyGTK and OS X. 
> Hopefully that will show me more of the best way of
> handling this.
The code in PyGTK is a bit easier to understand than the code for OS X. The OS X code also includes stuff to handle SIGINTs (keyboard interrupts by ctrl-c), which is nice but not really essential.
> But, what happens if PyOS_InputHook is called
> repeatedly. Are you not then starting the event loop
> multiple times. Can you say more about what happens in
> this case?
On the first call to PyOS_InputHook, you start the event loop, and you stay in the event loop until some input is available on stdin. So Python never gets the chance to call PyOS_InputHook repeatedly. 
Depending on if and how readline is installed, it is possible that once input is available on stdin and PyOS_InputHook exits, PyOS_InputHook is called a second time. But that doesn't do any real damage: the event loop is restarted, but it exits immediately because input is available on stdin. It's good to double-check that that works on wx though. Another option is to write your hook function as follows:
check if any input is available on stdin; if so, return
add fileno(stdin) to the set of file descriptors to be watched by the event loop
start the event loop; if input is available on stdin, exit the event loop and return
--Michiel.