matplotlib-devel Mailing List for matplotlib

Paul Kienzle wrote:
> A further comment on the windows PDF problems. 
> 
> PDF output generated by matplotlib on Windows and on OS X is readable 
> in Preview.app on OS X but is not readable in Acrobat 8.1.0 or 7.0.5 
> on Windows.
> 
> Adobe 7.0.5 produces the message "There were too many arguments".
> 
> At this point I have no idea how to proceed, but I will at least post
> the correct to ttconv.
Can you set "pdf.compression : 0" and send me a copy of the troublesome 
PDF (probably best off list if it's a large file.)?
Do you know what set of fonts are getting embedded? If their not in the 
mpl set, it's possible they haven't been tested.
Cheers,
Mike
-- 
Michael Droettboom
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

A further comment on the windows PDF problems. 
PDF output generated by matplotlib on Windows and on OS X is readable 
in Preview.app on OS X but is not readable in Acrobat 8.1.0 or 7.0.5 
on Windows.
Adobe 7.0.5 produces the message "There were too many arguments".
At this point I have no idea how to proceed, but I will at least post
the correct to ttconv.
	- Paul

I've resolved part of the PDF font problem on windows --- ttconv was not
opening the font file with "rb". I'll send a patch later as soon as I
figure out why acrobat is saying "too many arguments" when opening the
resulting pdf file. Preview.app on OS X opens the files without difficulty.
	- Paul

Hi,
We are having trouble with PDF generation on Windows (see below).
Python 2.4.3 - Enthought Edition 1.1.0
freetype 2.5.3 (GnuWin32 package)
Anyone experienced similar problems?
Meanwhile I'm modifying ttconv to include the font name in the error message.
	- Paul
 
Traceback (most recent call last):
 File "_tmp_alignment_test.py", line 87, in ?
 savefig("alignment_test_pdf", dpi=150)
 File "c:\python24\Lib\site-packages\matplotlib\pyplot.py", line 274, in savefig
 return fig.savefig(*args, **kwargs)
 File "c:\python24\Lib\site-packages\matplotlib\figure.py", line 770, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File "c:\python24\Lib\site-packages\matplotlib\backend_bases.py", line 1195, in print_figure
 orientation=orientation,
 File "c:\python24\Lib\site-packages\matplotlib\backends\backend_pdf.py", line 1943, in print_pdf
 file.close()
 File "c:\python24\Lib\site-packages\matplotlib\backends\backend_pdf.py", line 406, in close
 self.writeFonts()
 File "c:\python24\Lib\site-packages\matplotlib\backends\backend_pdf.py", line 475, in writeFonts
 fontdictObject = self.embedTTF(realpath, chars[1])
 File "c:\python24\Lib\site-packages\matplotlib\backends\backend_pdf.py", line 918, in embedTTF
 return embedTTFType3(font, characters, descriptor)
 File "c:\python24\Lib\site-packages\matplotlib\backends\backend_pdf.py", line 732, in embedTTFType3
 rawcharprocs = ttconv.get_pdf_charprocs(filename, glyph_ids)
RuntimeError: TrueType font may be corrupt (reason 2)

Hi Eric, Mike,
On Monday 10 September 2007 08:08:42 am Michael Droettboom wrote:
> Eric Firing wrote:
> > There is an inconsistency between mpl-data/matplotlib.conf and
> > config/mplconfig.py. The former has [[math]] under [text], but the
> > latter is based on a separate [mathtext]. It would be trivial to
> > resolve the inconsistency, but I don't know which way it should be
> > resolved, so I will leave this to you or Mike.
> >
> Darren,
>
> I trust your judgement on which way to go, as you have a better sense of
> how other settings have been laid out. I'm happy to do the work -- I
> just don't know which is correct going forward (these are new settings,
> so backward compatibility isn't a concern.)
>
> The values in matplotlib.conf should also should be updated to match
> mplconfig.py.
Eventually, matplotlib.conf should be autogenerated when setup.py is run. I 
have not tried to do this yet, maybe I can spend some time on it next 
weekend.
The mathtext settings are more like font.* settings than text.*, so I think 
they should get their own section (like in matplotlib.conf) instead of a 
subsection of text (like in mplConfig).
As for the greater organization of mplConfig, I laid things out in a way that 
made sense to me, but this organization is completely hidden right now, and I 
think we should discuss it before it congeals. For example, some might feel 
strongly that we should stick to the rcParams organization, to make a 
possible future transition as easy as possible. Here is what I changed:
rcParams mplConfig
-----------------------------|-----------------------------------
backend backend.use
font.sans-serif font.sans_serif
text.dvipnghack text.latex.dvipnghack
polaraxes.grid axes.polargrid
cairo.* backend.cairo.*
tk.* backend.tk.*
ps.* backend.ps.*
ps.usedistiller backend.ps.distiller.use
ps.distiller.res backend.ps.distiller.resolution
pdf.* backend.pdf.*
svg.* backend.svg.*
Darren

Darren,
I trust your judgement on which way to go, as you have a better sense of 
how other settings have been laid out. I'm happy to do the work -- I 
just don't know which is correct going forward (these are new settings, 
so backward compatibility isn't a concern.)
The values in matplotlib.conf should also should be updated to match 
mplconfig.py.
Cheers,
Mike
Eric Firing wrote:
> Darren,
> 
> There is an inconsistency between mpl-data/matplotlib.conf and 
> config/mplconfig.py. The former has [[math]] under [text], but the 
> latter is based on a separate [mathtext]. It would be trivial to 
> resolve the inconsistency, but I don't know which way it should be 
> resolved, so I will leave this to you or Mike.
> 
> Eric
> 
> -------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> On 9/9/07, Eric Firing <ef...@ha...> wrote:
>> The Axes.panx() method and several others contain calls to
>> _send_xlim_event() and similar methods. These methods don't seem to be
>> defined anywhere.
> 
> These methods (panx, zoomx) are from the very old toolbar, which
> should be deprecated and removed in my option. It doesn't look like
> they work anyhow, because as you note they rely on the nonexistant
> _send_xlim_event. The xlim callbacks are handled by the
> 'xlim_changed' notification of the callbacks attribute. I think all
> the methods that contain this (panx, zoomx and PolarAxes.set_xlim can
> either be removed entirely or have the _send_xlim_event call removed.
These methods have been broken for a long time, which is a crude form of 
deprecation. I am simply removing them now. Same for the old toolbar. 
 Given that the pan and zoom functions have been broken for so long, I 
don't see how anyone could be using it, so I don't see any point in 
keeping it around with a deprecation warning.
Eric
> 
> JDH

The pylab namespace has gradually gotten messier and messier, with all 
sorts of things dumped into it. A number of people have asked for a 
smaller module that would contain only the state-machine plotting part 
of pylab--that is, the figure, show, plot, contour, etc. sorts of 
functions. The name "pyplot" was suggested. I have made a first cut at 
this in svn, and I hope interested people will take a look and try it 
out. Here are the changes:
1) pylab is still present as a namespace aggregator, importing things 
from numpy and pyplot. So as to avoid breaking existing code that uses 
it, I have kept the numpy.oldnumeric imports rather than importing from 
 numpy itself, but it is done explicitly rather than via numerix. We 
will want to make a transition away from oldnumeric, but I did not want 
to force that immediately. The present pylab should work like the old 
one, except that I removed a few redundant imports. It is possible that 
some user code was using them and will therefore fail, but I expect such 
cases, if any, to be rare and easy to fix.
2) matplotlib.pyplot has all the basic function-based plotting and 
global things like rc and rcParams. If you want a fully modern version 
of pylab in interactive mode, then instead of
from pylab import *
you would do
from numpy import *
from matplotlib.pyplot import *
The latter may be what pylab itself evolves into.
Note that although pylab.py gets installed as a top-level module, 
pyplot does not; you have to qualify it with "matplotlib".
pyplot imports a number of classes from matplotlib in addition to the 
basic functions. If there is a consensus that this should not be 
done--that pyplot should be a smaller and cleaner namespace--it would be 
easy to take out those imports.
I have not written a docstring for pyplot.py yet. I will do that once 
it has been checked out and the design has settled down.
Eric

John Hunter wrote:
> On 9/9/07, Eric Firing <ef...@ha...> wrote:
>> The Axes.panx() method and several others contain calls to
>> _send_xlim_event() and similar methods. These methods don't seem to be
>> defined anywhere.
> 
> These methods (panx, zoomx) are from the very old toolbar, which
> should be deprecated and removed in my option. It doesn't look like
> they work anyhow, because as you note they rely on the nonexistant
> _send_xlim_event. The xlim callbacks are handled by the
> 'xlim_changed' notification of the callbacks attribute. I think all
> the methods that contain this (panx, zoomx and PolarAxes.set_xlim can
> either be removed entirely or have the _send_xlim_event call removed.
> 
> JDH
John,
OK, thanks, I will try to clean this up soon. I stumbled over it 
because one of the wx examples has its own toolbar with buttons that 
call these methods.
Eric

On 9/9/07, Eric Firing <ef...@ha...> wrote:
> The Axes.panx() method and several others contain calls to
> _send_xlim_event() and similar methods. These methods don't seem to be
> defined anywhere.
These methods (panx, zoomx) are from the very old toolbar, which
should be deprecated and removed in my option. It doesn't look like
they work anyhow, because as you note they rely on the nonexistant
_send_xlim_event. The xlim callbacks are handled by the
'xlim_changed' notification of the callbacks attribute. I think all
the methods that contain this (panx, zoomx and PolarAxes.set_xlim can
either be removed entirely or have the _send_xlim_event call removed.
JDH