Menu
▾
▴
matplotlib-devel
|
From: Nicolas G. <nic...@ga...> - 2006-11-05 17:07:54
|
Hello everybody, I'm in the process of replacing R by matplotlib to plot all of our charts. I'm hacking the PDF backend because I need this format to import charts in ConTeXt (this is TeX macro package, similar to LaTeX, we use to produce PDF reports). My first question, very basic, is why function is_string_like, in module cbook, doesn't simply return isinstance(s, types.StringTypes) instead of try: obj + '' except (TypeError, ValueError): return 0 return 1 Thanks for your work, Nicolas -- Garden - Marketing & Datamining Consultancy Nicolas Grilly Tel +33 1 45 72 48 78 Mob +33 6 03 00 25 34 www.garden-paris.com |
|
From: Gael V. <gae...@no...> - 2006-11-05 17:12:07
|
On Sun, Nov 05, 2006 at 06:07:50PM +0100, Nicolas Grilly wrote: > I'm hacking the PDF backend because I need this format to import > charts in ConTeXt (this is TeX macro package, similar to LaTeX, we use > to produce PDF reports). I am all for a good PDF backend, but you should be aware that under unices you can tell matplotlib to use a distiller, as illustrated in: http://www.mail-archive.com/mat...@li.../msg001= 60.html Ga=EBl |
|
From: Nicolas G. <nic...@ga...> - 2006-11-05 17:48:08
|
SGkgR2HDq2wsCgpHYWVsIFZhcm9xdWF1eCA8Z2FlbC52YXJvcXVhdXhAbm9ybWFsZXN1cC5vcmc+ IHdyb3RlOgo+IEkgYW0gYWxsIGZvciBhIGdvb2QgUERGIGJhY2tlbmQsIGJ1dCB5b3Ugc2hvdWxk IGJlIGF3YXJlIHRoYXQgdW5kZXIKPiB1bmljZXMgeW91IGNhbiB0ZWxsIG1hdHBsb3RsaWIgdG8g dXNlIGEgZGlzdGlsbGVyLCBhcyBpbGx1c3RyYXRlZCBpbjoKPiBodHRwOi8vd3d3Lm1haWwtYXJj aGl2ZS5jb20vbWF0cGxvdGxpYi1kZXZlbEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQvbXNnMDAxNjAu aHRtbAoKWWVzLCBJIGtub3cgaXQncyBwb3NzaWJsZSB0byB1c2UgYSBkaXN0aWxsZXIgdW5kZXIg VW5pY2VzIHRvIGNvbnZlcnQKbXkgUERGIGludG8gYW4gRVBTLCBidXQgSSdtIHVuZGVyIFdpbmRv d3MuLi4gTW9yZW92ZXIsIEkgdGhpbmsgaXQncwpnb29kIHRvIGhhdmUgYSBtb3JlIHN0cmFpZ2h0 Zm9yd2FyZCB3YXkgdG8gcHJvZHVjZSBQREYgY2hhcnRzLCB3aXRob3V0CnJlcXVpcmluZyBhIGRp c3RpbGxlci4K |
|
From: Andrew S. <str...@as...> - 2006-11-05 17:21:44
|
Gael Varoquaux wrote: > On Sun, Nov 05, 2006 at 06:07:50PM +0100, Nicolas Grilly wrote: > >> I'm hacking the PDF backend because I need this format to import >> charts in ConTeXt (this is TeX macro package, similar to LaTeX, we use >> to produce PDF reports). >> > > I am all for a good PDF backend, but you should be aware that under > unices you can tell matplotlib to use a distiller, as illustrated in: > http://www.mail-archive.com/mat...@li.../msg00160.html > BTW, what's the "official" status of the PDF backend? Last I checked (a month or so ago), it seemed to work fine, has a couple of Python 2.4-isms, but was generally great. I was surprised that it didn't appear to make it onto the list of officially-sanctioned backends (e.g. in the "save" button on the toolbar, IIRC). I found it really useful for making vectorized figures with alpha for inclusion in a pdflatex document. (Is that possible going via an (e)ps route?) When I get back to that manuscript (ahem), I'll probably try to bang the PDF backend further into shape. What bits need to be added/fixed? Is the PDF backend TODO list documented anywhere? where? -Andrew |
|
From: Gael V. <gae...@no...> - 2006-11-05 17:27:19
|
On Sun, Nov 05, 2006 at 09:27:54AM -0800, Andrew Straw wrote: > When I get back to that manuscript (ahem), I'll probably try to bang > the PDF backend further into shape. That would be great for pdf generation under windows, where you can hardly assume the user has xpdf or epstopdf installed. It has been holding back the portability of pyreport (which is by default non portable as I don't have windows). Ga=EBl |
|
From: Nicolas G. <nic...@ga...> - 2006-11-05 17:51:02
|
On 11/5/06, Andrew Straw <str...@as...> wrote: > BTW, what's the "official" status of the PDF backend? Last I checked (a > month or so ago), it seemed to work fine, has a couple of Python > 2.4-isms, but was generally great. I was surprised that it didn't appear > to make it onto the list of officially-sanctioned backends (e.g. in the > "save" button on the toolbar, IIRC). I found it really useful for making > vectorized figures with alpha for inclusion in a pdflatex document. (Is > that possible going via an (e)ps route?) When I get back to that > manuscript (ahem), I'll probably try to bang the PDF backend further > into shape. What bits need to be added/fixed? Is the PDF backend TODO > list documented anywhere? where? I agree: the PDF backend is almost usable! I've just some issues with: - text alignment (I fixed it on my working copy of matplotlib); - accentuated characters (nearly fixed); - embedding of TTF fonts in the PDF (in progress - we need to limit the /Widths array to the 256 characters used in WinAnsiEncoding). |
|
From: John H. <jdh...@ac...> - 2006-11-05 18:46:12
|
>>>>> "Andrew" == Andrew Straw <str...@as...> writes:
Andrew> BTW, what's the "official" status of the PDF backend? Last
Andrew> I checked (a month or so ago), it seemed to work fine, has
Andrew> a couple of Python 2.4-isms, but was generally great. I
Andrew> was surprised that it didn't appear to make it onto the
Andrew> list of officially-sanctioned backends (e.g. in the "save"
Andrew> button on the toolbar, IIRC). I found it really useful for
Hmm, in backend_agg.py
FigureCanvasAgg.print_figure there is an entry for pdf in the print
switch routine. Which backend are you having trouble on? All the
*Agg backends should just pass the print request right through to agg,
which should handle PDF (and PS, EPS, SVG, etc...)
JDH
|
|
From: Nicolas G. <nic...@ga...> - 2006-11-05 17:49:58
|
Hi Andrew, Andrew Straw <str...@as...> wrote: > I'm not speaking with the authority of one who actually wrote the > function or uses it, so I don't know the specific reasons, if there are > any. However, this kind of thing is common (and encouraged) practice in > Python. It's a use of "duck typing". For more info see > http://en.wikipedia.org/wiki/Duck_typing Thank you for your answer. I use Python for two years now and know "duck typing" very well. It's one of the most powerful features of this language. But in this function, I don't like the idea to try an operation on a string, and wait for an exception in order to know if we really have a string or not. It's not very efficient, nor very beautiful. I guess initial developer did that to keep compatibility with old Python versions. |
|
From: John H. <jdh...@ac...> - 2006-11-05 18:51:35
|
>>>>> "Nicolas" == Nicolas Grilly <nic...@ga...> writes:
Nicolas> But in this function, I don't like the idea to try an
Nicolas> operation on a string, and wait for an exception in order
Nicolas> to know if we really have a string or not. It's not very
Nicolas> efficient, nor very beautiful.
Nicolas> I guess initial developer did that to keep compatibility
Nicolas> with old Python versions.
I did it because it is general, elegant, and efficiency doesn't matter
here (any string operation is insignificant to the work we do making a
figure). What if a user writes their own string class, eg someone
wants a mutable string, or a lower case string, or any number of
custom string objects, and these aren't covered by the types module?
We make heavy use of duck typing in matplotlib, and it hasn't caused
us any problems I know of.
JDH
|
|
From: Jouni K S. <jk...@ik...> - 2006-11-05 19:14:20
|
Andrew Straw <str...@as...> writes: > When I get back to that manuscript (ahem), I'll probably try to bang > the PDF backend further into shape. What bits need to be > added/fixed? Is the PDF backend TODO list documented anywhere? > where? The TODO list is in the comments of backend_pdf.py: # * the alpha channel of images # * image compression could be improved (PDF supports png-like compression) # * encoding of fonts, including mathtext fonts and unicode support # * Type 1 and Base-14 font support (i.e., "pdf.use_afm") # * TTF support has lots of small TODOs, e.g. how do you know if a font # is serif/sans-serif, or symbolic/non-symbolic? # * draw_markers, draw_line_collection, etc. # * use_tex I think the most important thing to fix is the font support. TTF embedding mostly works but I haven't figured out the encoding issues, and it would be really nice to be able to do font subsetting. I was going to look into the Fonttools library by Just van Rossum, but lately I've been too busy with other things to. "Nicolas Grilly" <nic...@ga...> writes: > I've just some issues with: > - text alignment (I fixed it on my working copy of matplotlib); Great! Is there a patch somewhere? -- Jouni |
|
From: John H. <jdh...@ac...> - 2006-11-05 19:16:41
|
>>>>> "Jouni" == Jouni K Seppanen <jk...@ik...> writes:
Jouni> able to do font subsetting. I was going to look into the
Jouni> Fonttools library by Just van Rossum, but lately I've been
Jouni> too busy with other things to.
FYI, matplotlib used to depend on fonttools, but we found the
dependency too onerous and booted it and wrote our own, lighter
freetype support. So I would be reluctant to reintroduce this
dependency.
JDH
|
|
From: Nicolas G. <nic...@ga...> - 2006-11-06 16:47:44
|
> "Nicolas Grilly" <nic...@ga...> writes: > > I've just some issues with: > > - text alignment (I fixed it on my working copy of matplotlib); > > Great! Is there a patch somewhere? Yes, I'm preparing one and I'll submit it in the next few days. |
|
From: Jouni K S. <jk...@ik...> - 2006-11-05 19:24:18
|
"Nicolas Grilly" <nic...@ga...> writes: [about is_string_like] > But in this function, I don't like the idea to try an operation on a > string, and wait for an exception in order to know if we really have a > string or not. It's not very efficient, nor very beautiful. I wouldn't worry about efficiency until there is a demonstrable need to speed something up. > I guess initial developer did that to keep compatibility with old > Python versions. I've always thought that is_string_like is there to allow compatibility with _future_ code where someone is using a new kind of string-like object that works just like a string but for which isinstance(x, (str, unicode)) is false. -- Jouni |
|
From: Jouni K S. <jk...@ik...> - 2006-11-05 19:46:36
|
John Hunter <jdh...@ac...> writes: > FYI, matplotlib used to depend on fonttools, but we found the > dependency too onerous and booted it and wrote our own, lighter > freetype support. So I would be reluctant to reintroduce this > dependency. OK. Was it just that you don't want to require mpl users to install fonttools, or were there other problems with it? Does anyone here have experience with subsetting TrueType fonts (or Type 1 or OpenType, for that matter)? One pretty frequent complaint is that the eps files produced by matplotlib can be huge because they include the full font. Nowadays some popular fonts include characters for Greek, Cyrillic, Hebrew, Arabic, and possibly even Chinese, Japanese, and Korean, so a font can be several megabytes large. -- Jouni |
|
From: John H. <jdh...@ac...> - 2006-11-05 20:21:37
|
>>>>> "Jouni" == Jouni K Seppanen <jk...@ik...> writes:
Jouni> OK. Was it just that you don't want to require mpl users to
Jouni> install fonttools, or were there other problems with it?
One problem was that it was large compared to mpl at the time, and mpl
was pure python. So it complicated the distribution to have a large
piece of extension code that wasn't quite as ubiquitous as numpy. Of
course now mpl is much larger and has it's own extension code headaches.
Jouni> Does anyone here have experience with subsetting TrueType
Jouni> fonts (or Type 1 or OpenType, for that matter)? One pretty
Jouni> frequent complaint is that the eps files produced by
Jouni> matplotlib can be huge because they include the full
Jouni> font. Nowadays some popular fonts include characters for
Jouni> Greek, Cyrillic, Hebrew, Arabic, and possibly even Chinese,
Jouni> Japanese, and Korean, so a font can be several megabytes
Jouni> large.
I would love for someone how to figure out how to extract and embed
just the needed glyphs rather than dump the whole file in. I'm 99%
sure this is possible, it just takes some dedication.
JDH
|
|
From: Nicolas G. <nic...@ga...> - 2006-11-06 17:07:43
|
On 11/5/06, Jouni K Seppanen <jk...@ik...> wrote:
> Does anyone here have experience with subsetting TrueType fonts (or
> Type 1 or OpenType, for that matter)? One pretty frequent complaint is
> that the eps files produced by matplotlib can be huge because they
> include the full font. Nowadays some popular fonts include characters
> for Greek, Cyrillic, Hebrew, Arabic, and possibly even Chinese,
> Japanese, and Korean, so a font can be several megabytes large.
I do not have experience in subsetting TrueType fonts, but I read the
pure Python code dedicated to this task in ReportLab:
http://www.reportlab.co.uk/svn/public/reportlab/trunk/reportlab/pdfbase/ttfonts.py
It proves it's possible to achieve it in pure Python, without
requiring fonttools. And it can be a good source of inspiration.
Perhaps the licence is compatible with matplotlib's one?
|
|
From: John H. <jdh...@ac...> - 2006-11-06 17:15:07
|
>>>>> "Nicolas" == Nicolas Grilly <nic...@ga...> writes:
Nicolas> It proves it's possible to achieve it in pure Python,
Nicolas> without requiring fonttools. And it can be a good source
Nicolas> of inspiration. Perhaps the licence is compatible with
Nicolas> matplotlib's one?
it is BSD which is compatible-- it appears that ttfonts pull in a bit
more or report lab, but this might be worth looking into. I don't
know if and how the techniques cold be generalized to PS embedding. I
think the problem Paul ran into (who did the PS embedding work) was
not getting the relevant info for specific glyphs, but how to write
the postscript to encode the subset.
JDH
|
|
From: Nicolas G. <nic...@ga...> - 2006-11-09 01:30:46
|
Thank you John for your answer. You're right: efficiency is a non-issue. I shouldn't have mentioned it. On 11/5/06, John Hunter <jdh...@ac...> wrote: > Nicolas> But in this function, I don't like the idea to try an > Nicolas> operation on a string, and wait for an exception in order > Nicolas> to know if we really have a string or not. It's not very > Nicolas> efficient, nor very beautiful. > > Nicolas> I guess initial developer did that to keep compatibility > Nicolas> with old Python versions. > > I did it because it is general, elegant, and efficiency doesn't matter > here (any string operation is insignificant to the work we do making a > figure). What if a user writes their own string class, eg someone > wants a mutable string, or a lower case string, or any number of > custom string objects, and these aren't covered by the types module? > > We make heavy use of duck typing in matplotlib, and it hasn't caused > us any problems I know of. > > JDH |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X