Re: [Matplotlib-users] Intersecting polygons

2013-08-23 Thread Chris Beaumont
Thanks for the tips -- I wish there was a way to do this within MPL, but it
sounds like I'll have to live with external hackery.

>
> > PS. Try to convince the Dark Powers of the journal you send your work,
> > that they modernize their processing and accept PDF.
> +1


I know, right?

chris
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] building matplotlib 1.3 on OS X 10.8.4

2013-08-23 Thread Russell E. Owen
In article ,
 James Boyle  
 wrote:

> I built MPL 1.3 from source, all seem to go OK but I ran into the problem of 
> not finding libfreetype.6.dylib when importing.

Hmmm, it works for me. (I tried it again, just now). Here is what I did:

* Make sure you have XQuartz installed. I have 2.7.4 which I got from 
Apple.

* Edit setupext.py. Change this line:
 'darwin': ['/usr/local/', '/usr', '/usr/X11', '/opt/local'],
to:
'darwin': ['/usr', '/usr/X11'],
to avoid any conflicts with any extra software you might have installed.

* Copy setup.cfg.template to setup.cfg to change:
#backend = TkAgg
to:
backend = TkAgg

* python setup.py build
* python setup.py install

I found this resulted in a matplotlib I could use just fine on 10.8. (It 
won't work on 10.6 because the X11 libraries are in the wrong place).

-- Russell


--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] Explicitly clearing Matplotlib/Pylab figure buffers

2013-08-23 Thread Benjamin Root
On Fri, Aug 23, 2013 at 4:08 PM, Kari Aliranta <
kari.p.alira...@student.jyu.fi> wrote:

> 23.08.2013 20:57, Eric Firing kirjoitti:
> > On 2013/08/23 3:55 AM, Kari Aliranta wrote:
> >> Hello, fellow Matplotlib users,
> >>
> >>
> >> I'm embedding some Matplotlib figures into GUI (PyQt4) windows or widget
> >> canvases using qt4agg as the backend. I'm having problems with these
> >> figures popping up any time when some other part of the program calls
> >> pyplot.show().
> >
> > Generally, when embedding, one simply does not use the pyplot interface
> > at all, so this sort of problem does not arise.  Is there any reason why
> > you can't use this approach?
>
> Thank you. I'd like to stick to pure OO, but I'm using some
> third party open source code that uses pylab extensively for
> rather large and interactive (as in "includes scrollbars,
> buttons and several types of events") figures. The code
> works nicely in itself, and has an option to return the
> figure object without actually showing the plot.
>
> I was hoping to take the returned figure as an object and
> reset the related state environment information, effectively
> "smuggling" the created figure out of the state environment.
> If there is a simple way to do this in Matplotlib, that
> would be quite useful.
>
>
There is one quick-n-dirty way of doing it. And it ain't pretty.

Using the third-party code in a subprocess that creates a pickle of the
figure. Then load up the pickle and extract the figure object in your
parent process. Your instance of matplotlib will never be touched.

Told you it wasn't pretty...

Ben Root
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] Intersecting polygons

2013-08-23 Thread Sterling Smith
> 
> 
> PS. Try to convince the Dark Powers of the journal you send your work, 
> that they modernize their processing and accept PDF.
+1

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] Explicitly clearing Matplotlib/Pylab figure buffers

2013-08-23 Thread Kari Aliranta
23.08.2013 20:57, Eric Firing kirjoitti:
> On 2013/08/23 3:55 AM, Kari Aliranta wrote:
>> Hello, fellow Matplotlib users,
>>
>>
>> I'm embedding some Matplotlib figures into GUI (PyQt4) windows or widget
>> canvases using qt4agg as the backend. I'm having problems with these
>> figures popping up any time when some other part of the program calls
>> pyplot.show().
>
> Generally, when embedding, one simply does not use the pyplot interface
> at all, so this sort of problem does not arise.  Is there any reason why
> you can't use this approach?

Thank you. I'd like to stick to pure OO, but I'm using some 
third party open source code that uses pylab extensively for 
rather large and interactive (as in "includes scrollbars, 
buttons and several types of events") figures. The code 
works nicely in itself, and has an option to return the 
figure object without actually showing the plot.

I was hoping to take the returned figure as an object and 
reset the related state environment information, effectively 
"smuggling" the created figure out of the state environment. 
If there is a simple way to do this in Matplotlib, that 
would be quite useful.

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] Intersecting polygons

2013-08-23 Thread Jerzy Karczmarczuk
Le 23/08/2013 03:32, Chris Beaumont a écrit :
> It looks like some programs (like illustrator, and pdf2ps) are 
> semi-smart about handling transparency when converting to ps. Both 
> have their quirks (illustrator seems to mess up the bounding box, 
> pdf2ps makes the text look worse/fuzzy).
>
> Is this the recommended/best strategy?

Who can really say what is a/the recommended strategy?...

I am almost certain that the process described by Jon Ramsey - passing 
through jpeg - is better to be avoided. It probably works decently, and 
the JPEG is quite economic, but the conversion of a raster into EPS 
produces large files, and - as you said - the rasterization makes it not 
so scalable. And in general, a lossy compression is methodologically 
wrong here...

I compared on a sample picture (similar to yours, but simpler, from the 
matplotlib documentation) these two methods:

1. Generate pdf, use pdf2ps (and convert to eps)
2. Generate svg, use inkscape to export eps.

The results are visually comparable. I don't notice much of fuzziness; 
perhaps this is the anti-aliasing on your display?
My version, the passage through svg produces a file which is more than 3 
times shorter.

Good luck.

Jerzy Karczmarczuk

PS. Try to convince the Dark Powers of the journal you send your work, 
that they modernize their processing and accept PDF.


--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] Explicitly clearing Matplotlib/Pylab figure buffers

2013-08-23 Thread Benjamin Root
On Fri, Aug 23, 2013 at 1:57 PM, Eric Firing  wrote:

> On 2013/08/23 3:55 AM, Kari Aliranta wrote:
> > Hello, fellow Matplotlib users,
> >
> >
> > I'm embedding some Matplotlib figures into GUI (PyQt4) windows or widget
> > canvases using qt4agg as the backend. I'm having problems with these
> > figures popping up any time when some other part of the program calls
> > pyplot.show().
>
> Generally, when embedding, one simply does not use the pyplot interface
> at all, so this sort of problem does not arise.  Is there any reason why
> you can't use this approach?
> >
> > How do you avoid this showing of previous figures? Is there some hidden
> > buffer where the figures go? If there is, what is the way to clear this
> > buffer, or preferably avoid putting figures in this buffer altogether?
> > I'd be happy to handle these figures as simple individual objects.
>
> To remove a figure created by pyplot, use pyplot.close(fig); but still,
> trying to use the pyplot interface for anything more complicated than
> direct interactive use and simple non-interactive scripts is likely to
> cause more problems than it solves. It's just not what pyplot is
> designed for.
>
> Eric
>

I am wondering if the problem being described here is one where someone
creates a module to do some particular thing using matplotlib, and someone
else has the script that is using pyplot and that module. I am fairly
certain that the pure OO approach should still work for the code in the
module without interference from the script's usage of pyplot, though, but
I am not 100% certain.

Cheers!
Ben Root
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] Explicitly clearing Matplotlib/Pylab figure buffers

2013-08-23 Thread Eric Firing
On 2013/08/23 3:55 AM, Kari Aliranta wrote:
> Hello, fellow Matplotlib users,
>
>
> I'm embedding some Matplotlib figures into GUI (PyQt4) windows or widget
> canvases using qt4agg as the backend. I'm having problems with these
> figures popping up any time when some other part of the program calls
> pyplot.show().

Generally, when embedding, one simply does not use the pyplot interface 
at all, so this sort of problem does not arise.  Is there any reason why 
you can't use this approach?
>
> How do you avoid this showing of previous figures? Is there some hidden
> buffer where the figures go? If there is, what is the way to clear this
> buffer, or preferably avoid putting figures in this buffer altogether?
> I'd be happy to handle these figures as simple individual objects.

To remove a figure created by pyplot, use pyplot.close(fig); but still, 
trying to use the pyplot interface for anything more complicated than 
direct interactive use and simple non-interactive scripts is likely to 
cause more problems than it solves. It's just not what pyplot is 
designed for.

Eric
>
> (I'm aware that this "hidden buffer" may be the pylab/pyplot buffer. I
> tried deepcopying the figure and then clearing the pylab buffer with
> pylab.clf() , but figures don't seem to be deepcopyable.)
>
>
> A  typical situation is the following:
>
> - There is a window with a widget. The widget (widgetMpl in the code
> below) has a slightly customized FigureCanvas in it. The drawing code is
> activated by clicking a button in the window. The code goes as follows.
>
>   # The plot method returns a complicated instance of Figure with
> several axes, constructed with Pylab.
>   previewFigure =
> self.parent.experiment.file_to_plot.plot(show=False, n_channels=10)
>
>   self.ui.widgetMpl.canvas.figure = previewFigure
>   self.ui.widgetMpl.canvas.draw()
>
>
> - I draw the figure in the window once, or several times with different
> file_to_plot, by pressing the button. I may or may not close the window
> with the aforementioned widget.
>
> - Elsewhere in the program there is another window with very simple
> drawing code using pyplot. When this code calls pyplot.show(), all the
> figures drawn in the first window will show up.
>
>
>
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> Matplotlib-users mailing list
> Matplotlib-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>


--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] Explicitly clearing Matplotlib/Pylab figure buffers

2013-08-23 Thread Benjamin Root
On Fri, Aug 23, 2013 at 9:55 AM, Kari Aliranta <
kari.p.alira...@student.jyu.fi> wrote:

> Hello, fellow Matplotlib users,
>
>
> I'm embedding some Matplotlib figures into GUI (PyQt4) windows or widget
> canvases using qt4agg as the backend. I'm having problems with these
> figures popping up any time when some other part of the program calls
> pyplot.show().
>
> How do you avoid this showing of previous figures? Is there some hidden
> buffer where the figures go? If there is, what is the way to clear this
> buffer, or preferably avoid putting figures in this buffer altogether?
> I'd be happy to handle these figures as simple individual objects.
>
> (I'm aware that this "hidden buffer" may be the pylab/pyplot buffer. I
> tried deepcopying the figure and then clearing the pylab buffer with
> pylab.clf() , but figures don't seem to be deepcopyable.)
>
>
> A  typical situation is the following:
>
> - There is a window with a widget. The widget (widgetMpl in the code
> below) has a slightly customized FigureCanvas in it. The drawing code is
> activated by clicking a button in the window. The code goes as follows.
>
>  # The plot method returns a complicated instance of Figure with
> several axes, constructed with Pylab.
>  previewFigure =
> self.parent.experiment.file_to_plot.plot(show=False, n_channels=10)
>
>  self.ui.widgetMpl.canvas.figure = previewFigure
>  self.ui.widgetMpl.canvas.draw()
>
>
> - I draw the figure in the window once, or several times with different
> file_to_plot, by pressing the button. I may or may not close the window
> with the aforementioned widget.
>
> - Elsewhere in the program there is another window with very simple
> drawing code using pyplot. When this code calls pyplot.show(), all the
> figures drawn in the first window will show up.
>
>
>
It is called the "pyplot state environment".  When code uses pylab or
pyplot, the pyplot state implicitly keeps track of all the axes and figures
that are generated. The way to avoid the pyplot state environment is to
completely avoid any and all usage of pyplot. Don't even import it. Work
strictly down in the OO layer. Of course, this is difficult to do for a
variety of reasons, but it should be achievable.  There are other people on
this mailing list that are much more experienced than I with the pure
OO-approach and embedding, and hopefully they can chime in with pointers
and tips.

Cheers!
Ben Root
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] [matplotlib-devel] I have a Mac!

2013-08-23 Thread Chris Barker - NOAA Federal
On Fri, Aug 23, 2013 at 8:14 AM, Matt Terry  wrote:
> I'm banging away at installing MPL on top of python.org's python.

This is why binary installers are good idea!

> the libfreetype/freetype issue.

yeah, that's kind of uglyand where is doesn't "just work" for me...

> 1) install libpng[1] and freetype[2] from source

libpng and freetype are different, though install from source may be
the way to go:

libpng is there, but is not properly installed, I'm not sure it's got
the header for the same version as the lib, and libpng-config is
either not there or not for the right version or somethign ugly. It
look, form messages at build time, that someone has hacked some code
into the MPL build that figures all that out, but for other stuff I'm
doing, I just punt and build libpng -- that's pretty straighforward,
at least. But teh solution in the MPL code now seems to work.

> 2) install XQuartz[3] and twiddle /opt/X11, /usr/X11 (per Russell's
> directions[4]) so MPL finds XQuartz's libpng/freetype

I _think_ that OS-X now ships with X11, which has freetype (though
installed weirdly once again...) we certainly should NOT expect people
to install anything big to build MPL, and binaries should not depend
on anything not shipped by Apple by default.

According to Russell, you do need to install something, so I think that's out.

> 4) create the MPL binary installer and use that

That's what most people should do -- but one of us needs to build it.

> Option 1 seems simple-est, but installing freetype requires more than
> ./configure && make && sudo make install.

darn. But hopefully we can figure it out.

> Option 4: This would require some input from whoever (Gohlke?, Owen?) makes
> the binary installers.

I think Russell has been doing it for MPL lately.

My thoughts:

We want to support two user-bases:

1) folks that don't mind a little command line work, and probably need
other scientific libs, etc anyway, an want an MPL that runs on their
machine:
   - these folks should use homebrew or macports to build the
dependencies (or even hand-compile them). Ideally we have setup.py
that will find those libs, and test to see that the builds work once
in a while.

2) folks that "just want to use it" and/or want a binary they can
re-distribute via py2app, etc.
  - for these folks, we need to provide binaries. These binaries should:
   1) Match the python.org python builds. (probably only the Intel ones now...)
   2) statically link the non-sytem libs

This has been done for a while, off and on, most recently by Russell, AFAIK.

But this is not a problem unique to MPL. All sorts of python packages
need this, and only some of the package maintainers do it (well).
Also, a bunch of packages require the same dependencies (i.e. PIL and
MPL both need png and freetype)

So, rather than re-inventing the wheel over and over again, It would
be great to have a central repository where we can develop build
scripts, etc that share an infrustructure for building these binaries.

I've started one:

https://github.com/MacPython/mac-builds

there is not much there, only a couple things I'm working on at the
moment (netCDF4, which is of interest to scipy folks, and py_gd, which
is my own simple drawing lib, that no one else uses (yet?)

If anyone wants to join the project let me know -- if I know you from
your work with this community, I'll gladly add you.

I'm using the gattai build system:
(https://sourceforge.net/projects/gattai/). I decided to do that, as I
was sick of re-writing essentially the same build scripts, and I kept
adding features to mine that would have resulted in re-implementing
gattai anyway. I've been hacking at gattai, and its author is quite
open to moving it forward.

That being said, there is no reason that we need to use the same build
system -- we could easily have custom build scripts for a project, and
still have it share the dependencies.

I was planning on getting it all further along before announcing the
project and looking for help, but since is came up...

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] [matplotlib-devel] I have a Mac!

2013-08-23 Thread Russell Owen

On Aug 22, 2013, at 8:24 PM, Matt Terry  wrote:

> > with/without third party X
> I'm not quite sure what you mean by with/without third party X. If you
> are referring to Tck/Tk:
> 
> I had an issue where MPL found the headers to freetype in /opt/local, but 
> library in /usr/X11.  Hilarity ensues.  I *think* /usr/X11 showed up when I 
> installed XQuartz, but I don't have a clean image to compare against.
> 
> The with-X / without-X builds would be there to check that the default search 
> paths are compatible with common environments.

Have you tried eliminating /opt from the search path in setupext.py? If that 
does the trick, I think we may be stuck. The default search paths are trying to 
work for default python, python.org python, macports and homebrew, plus 
user-built libraries in /usr/local. I'm not convinced one file can do it all. 
Apple moving X from /usr/X11 to /opt/X11 did not help.

Regards,

-- Russell--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] [matplotlib-devel] I have a Mac!

2013-08-23 Thread Russell Owen
On Aug 23, 2013, at 8:14 AM, Matt Terry  wrote:

> I'm banging away at installing MPL on top of python.org's python.  I'm at the 
> libfreetype/freetype issue.  There seems to be three approaches to getting 
> MPL's dependencies.
> 
> 1) install libpng[1] and freetype[2] from source
> 2) install XQuartz[3] and twiddle /opt/X11, /usr/X11 (per Russell's 
> directions[4]) so MPL finds XQuartz's libpng/freetype
> 3) install XQuartz[3] and install pkg-config[5] so MPL can find the cleverly 
> installed libraries
> 4) create the MPL binary installer and use that
> 
> Option 1 seems simple-est, but installing freetype requires more than 
> ./configure && make && sudo make install.
> Option 2 worries me with the manual symlinking and such.  Who knows what 
> we'll clobber.
> Option 3: haven't fully explored.
> Option 4: This would require some input from whoever (Gohlke?, Owen?) makes 
> the binary installers.
> 
> [1] http://www.libpng.org/pub/png/libpng.html
> [2] http://www.freetype.org/index.html
> [3] http://xquartz.macosforge.org/landing/
> [4] http://www.astro.washington.edu/users/rowen/BuildingMatplotlibForMac.html
> [5] http://www.freedesktop.org/wiki/Software/pkg-config/

I'm a bit puzzled what you are trying to do. I've found that matplotlib "just 
builds" if I only want to use it on the Mac I'm building it on. Depending on 
what you've added to your Mac you may find you have to restrict the search dirs 
in setupext.py, but that's all I have ever had to do for years.

For me the problems arise when trying to build a binary installer that runs on 
multiple versions of MacOS.

The following comments all deal with that case (making a binary installer):

I would eliminate (2) as an option; I thought it would help but it doesn't 
(perhaps I need to update my matplotlib build instructions). The issue is that 
when I build a binary installer on 10.8, it cannot be used on 10.6 because it 
is looking for some libraries in /opt/X11 (which is where XQuartz is installed 
on 10.8) instead of /usr/X11 (which is where X11 is installed on 10.6). It's 
only an issue for binary installers; I haven't had any problem just building 
matplotlib for python.org python.

I have pretty much given up building binary installers on anything but the 
oldest version of MacOS X that they can be used on (or as close as I can get). 
I've just run into too many problems like this.

I like (1) for binary installers. It eliminates the need for a user to have 
installed X11 at all. The hassle is making sure matplotlib statically links 
these libraries. I've always done this by taking the crude approach of deleting 
the shared object libraries, leaving only the static libraries; it always 
worked in the past, but recently I ran into a problem where something I was 
building simply refused to use a static library (I don't remember the details).

Regarding option [4]. You can get a binary installer for matplotlib 1.3 from 
here:

but it may clobber your python-dateutil and pytz (especially likely if they 
were installed by the matplotlib 1.2.1 binary installer). That's the main 
reason it's not an official binary installer.

-- Russell

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] Matplotlib V1.3 suptitle

2013-08-23 Thread Peter Bloomfield


On 08/23/2013 11:31 AM, Benjamin Root wrote:


On Fri, Aug 23, 2013 at 11:21 AM, Peter Bloomfield 
mailto:peter.bloomfi...@camhpet.ca>> wrote:



On 08/23/2013 10:43 AM, Benjamin Root wrote:



On Fri, Aug 23, 2013 at 9:57 AM, Peter Bloomfield
mailto:peter.bloomfi...@camhpet.ca>> wrote:

Good morning,

I am running openSuSE 12.2, and this morning I upgraded
matplotlib to v1.3, and now I am having a problem with suptitle.
I use the following lines to put a title and legend onto a
plot figure

import matplotlib.pyplot as plt

plt.figure(1)

plt.suptitle( "Study# : " + os.path.basename(
inImage_IO.IO_FileName ) + \

"\n" + "{ Acquired : " + \

AcqDateTime.strftime( "%b %d, %Y - $T_o$ @ %H:%M:%S" ) + " }", \

y=0.98, weight="roman", size="large" )

plt.suptitle( "{Creation Date : " + AnalysisTOD + "}",

x=0.86, y=0.03, weight="roman", size="x-small" )


Under v1.3, I only get the 'Creation Date : ...' text at the
bottom of the figure the 'Study# ...' string is not present
at the top. If I change
it to

import matplotlib.pyplot as plt

plt.figure(1)

plt.suptitle( "Study# : ", y=0.98, weight="roman", size="large" )

plt.suptitle( "{Creation Date : " + AnalysisTOD + "}",

x=0.86, y=0.03, weight="roman", size="x-small" )

the 'Creation Date : ...' text at the bottom of the figure
the 'Study# : ' string is at the top.


So the problem is in the string construct in the first
example. Does anybody know of a way to get around this?


Thanks in advance


Peter


Oh, wow... we didn't think anybody was using that "misfeature". 
This was a bug we fixed for 1.3, in that users complained that

calling plt.title() would update an existing title, but
plt.suptitle() would not (multiple calls would just result in
text overlaid on top of each other).  We fixed this for 1.3 so
that there is a single text object that is kept and is revised in
subsequent calls to suptitle().  To get what you want, you will
have to consolidate those strings into one.

Cheers!
Ben


Thanks for getting back to me, but I have tried to do as you
suggest, but to no avail, and here I apologise for my lack of
knowledge of python/matplotlib.
I consolidated the strings into one, titleStr

titleStr = "Study# : " + os.path.basename(
inImage_IO.IO_FileName ) + \

   "\n" + "{ Acquired : " + \
AcqDateTime.strftime( "%b %d, %Y - $T_o$ @
%H:%M:%S" ) + " }"
plt.suptitle( titleStr, y=0.98, weight="roman", size="large" )

which should write the string
'Study# : Pos9.img\n{ Acquired : Feb 18, 2003 - $T_o$ @
14:55:02 }'
at the top of the figure,  but it did not, so I thought it is the
"\n", and tried

titleStr = "Study# : " + os.path.basename(
inImage_IO.IO_FileName )
plt.suptitle( titleStr, y=0.98, weight="roman", size="large" )

which should write the string
'Study# : Pos9.img'
and this again failed to write the suptitle in the figure.

Am I being dumb (rhetorical)? What is the best way to consolidate
the strings to work with suptitle, many thanks in advance.

Cheers

Peter


No issues here.  Let's try simplifying it further and further.  Try 
the following script.


import matplotlib.pyplot as plt
plt.suptitle("Study# : Pos9.img")
plt.show()

Does that work for you? If it does, iterate on that code example, 
adding pieces back into it and see when it breaks.


Ben Root

The example works, and changing it to

import matplotlib.pyplot as plt

plt.suptitle( "Study# : Pos9.img\n{ Acquired : Feb 18, 2003 - $T_o$ @ 
14:55:02 }")


plt.show()

also works.


Though now,  I need to apologise, in my original email I should have 
added that I am using

from matplotlib.backends.backend_pdf import PdfPages

to write a pdf file of the save the figure.


I extended the example to a small script

from matplotlib.backends.backend_pdf import PdfPages
import matplotlib.pyplot as plt
PDF_Filename = "Test.pdf"
OutPDF = PdfPages( PDF_Filename )
plt.suptitle("Study# : Pos9.img\n{ Acquired : Feb 18, 2003 - $T_o$ 
@ 14:55:02 }")

plt.savefig( OutPDF, dpi=600, format="pdf" )
OutPDF.close()

and this also works, the text is now written correctly in Test.pdf.

However, if I add a second call to plt.suptitle in the script the text 
added from the first call is removed, which is what was refered to in 
the first response.


Cheers

Peter





--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us

Re: [Matplotlib-users] Matplotlib V1.3 suptitle

2013-08-23 Thread Benjamin Root
On Fri, Aug 23, 2013 at 11:21 AM, Peter Bloomfield <
peter.bloomfi...@camhpet.ca> wrote:

>
> On 08/23/2013 10:43 AM, Benjamin Root wrote:
>
>
>
> On Fri, Aug 23, 2013 at 9:57 AM, Peter Bloomfield <
> peter.bloomfi...@camhpet.ca> wrote:
>
>>  Good morning,
>>
>> I am running openSuSE 12.2, and this morning I upgraded matplotlib to
>> v1.3, and now I am having a problem with suptitle.
>> I use the following lines to put a title and legend onto a plot figure
>>
>>  import matplotlib.pyplot as plt
>> plt.figure(1)
>>
>> plt.suptitle( "Study# : " + os.path.basename( inImage_IO.IO_FileName ) + \
>>
>> "\n" + "{ Acquired : " + \
>>
>> AcqDateTime.strftime( "%b %d, %Y - $T_o$ @ %H:%M:%S" ) + " }", \
>>
>> y=0.98, weight="roman", size="large" )
>>
>> plt.suptitle( "{Creation Date : " + AnalysisTOD + "}",
>>
>> x=0.86, y=0.03, weight="roman", size="x-small" )
>>
>>
>>  Under v1.3, I only get the 'Creation Date : ...' text at the bottom of
>> the figure the 'Study# ...' string is not present at the top. If I change
>> it to
>>
>>  import matplotlib.pyplot as plt
>> plt.figure(1)
>>
>> plt.suptitle( "Study# : ", y=0.98, weight="roman", size="large" )
>>
>> plt.suptitle( "{Creation Date : " + AnalysisTOD + "}",
>>
>> x=0.86, y=0.03, weight="roman", size="x-small" )
>>
>>  the 'Creation Date : ...' text at the bottom of the figure the 'Study#
>> : ' string is at the top.
>>
>>
>> So the problem is in the string construct in the first example. Does
>> anybody know of a way to get around this?
>>
>>
>> Thanks in advance
>>
>>
>> Peter
>>
>>
> Oh, wow... we didn't think anybody was using that "misfeature".  This was
> a bug we fixed for 1.3, in that users complained that calling plt.title()
> would update an existing title, but plt.suptitle() would not (multiple
> calls would just result in text overlaid on top of each other).  We fixed
> this for 1.3 so that there is a single text object that is kept and is
> revised in subsequent calls to suptitle().  To get what you want, you will
> have to consolidate those strings into one.
>
>  Cheers!
> Ben
>
>Thanks for getting back to me, but I have tried to do as you suggest,
> but to no avail, and here I apologise for my lack of knowledge of
> python/matplotlib.
> I consolidated the strings into one, titleStr
>
> titleStr = "Study# : " + os.path.basename( inImage_IO.IO_FileName ) + \
>
>"\n" + "{ Acquired : " + \
> AcqDateTime.strftime( "%b %d, %Y - $T_o$ @ %H:%M:%S" ) + "
> }"
> plt.suptitle( titleStr, y=0.98, weight="roman", size="large" )
>
> which should write the string
> 'Study# : Pos9.img\n{ Acquired : Feb 18, 2003 - $T_o$ @ 14:55:02 }'
> at the top of the figure,  but it did not, so I thought it is the "\n",
> and tried
>
> titleStr = "Study# : " + os.path.basename( inImage_IO.IO_FileName )
> plt.suptitle( titleStr, y=0.98, weight="roman", size="large" )
>
> which should write the string
> 'Study# : Pos9.img'
> and this again failed to write the suptitle in the figure.
>
> Am I being dumb (rhetorical)? What is the best way to consolidate the
> strings to work with suptitle, many thanks in advance.
>
> Cheers
>
> Peter
>
>
No issues here.  Let's try simplifying it further and further.  Try the
following script.

import matplotlib.pyplot as plt
plt.suptitle("Study# : Pos9.img")
plt.show()

Does that work for you? If it does, iterate on that code example, adding
pieces back into it and see when it breaks.

Ben Root
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] Matplotlib V1.3 suptitle

2013-08-23 Thread Peter Bloomfield


On 08/23/2013 10:43 AM, Benjamin Root wrote:



On Fri, Aug 23, 2013 at 9:57 AM, Peter Bloomfield 
mailto:peter.bloomfi...@camhpet.ca>> wrote:


Good morning,

I am running openSuSE 12.2, and this morning I upgraded matplotlib
to v1.3, and now I am having a problem with suptitle.
I use the following lines to put a title and legend onto a plot figure

import matplotlib.pyplot as plt

plt.figure(1)

plt.suptitle( "Study# : " + os.path.basename(
inImage_IO.IO_FileName ) + \

"\n" + "{ Acquired : " + \

AcqDateTime.strftime( "%b %d, %Y - $T_o$ @ %H:%M:%S" ) + " }", \

y=0.98, weight="roman", size="large" )

plt.suptitle( "{Creation Date : " + AnalysisTOD + "}",

x=0.86, y=0.03, weight="roman", size="x-small" )


Under v1.3, I only get the 'Creation Date : ...' text at the
bottom of the figure the 'Study# ...' string is not present at the
top. If I change
it to

import matplotlib.pyplot as plt

plt.figure(1)

plt.suptitle( "Study# : ", y=0.98, weight="roman", size="large" )

plt.suptitle( "{Creation Date : " + AnalysisTOD + "}",

x=0.86, y=0.03, weight="roman", size="x-small" )

the 'Creation Date : ...' text at the bottom of the figure the
'Study# : ' string is at the top.


So the problem is in the string construct in the first example.
Does anybody know of a way to get around this?


Thanks in advance


Peter


Oh, wow... we didn't think anybody was using that "misfeature".  This 
was a bug we fixed for 1.3, in that users complained that calling 
plt.title() would update an existing title, but plt.suptitle() would 
not (multiple calls would just result in text overlaid on top of each 
other).  We fixed this for 1.3 so that there is a single text object 
that is kept and is revised in subsequent calls to suptitle().  To get 
what you want, you will have to consolidate those strings into one.


Cheers!
Ben

Thanks for getting back to me, but I have tried to do as you suggest, 
but to no avail, and here I apologise for my lack of knowledge of 
python/matplotlib.

I consolidated the strings into one, titleStr

titleStr = "Study# : " + os.path.basename( inImage_IO.IO_FileName ) + \
   "\n" + "{ Acquired : " + \
AcqDateTime.strftime( "%b %d, %Y - $T_o$ @ %H:%M:%S" ) 
+ " }"

plt.suptitle( titleStr, y=0.98, weight="roman", size="large" )

which should write the string
'Study# : Pos9.img\n{ Acquired : Feb 18, 2003 - $T_o$ @ 14:55:02 }'
at the top of the figure,  but it did not, so I thought it is the "\n", 
and tried


titleStr = "Study# : " + os.path.basename( inImage_IO.IO_FileName )
plt.suptitle( titleStr, y=0.98, weight="roman", size="large" )

which should write the string
'Study# : Pos9.img'
and this again failed to write the suptitle in the figure.

Am I being dumb (rhetorical)? What is the best way to consolidate the 
strings to work with suptitle, many thanks in advance.


Cheers

Peter



--
Peter M. Bloomfield
Physicist,
PET Centre,
Centre for Addiction and Mental Health,
250 College St.,
Toronto, Ontario,
Canada M5T 1R8
Tel: 416 535 8501 Ext. 4243

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] [matplotlib-devel] I have a Mac!

2013-08-23 Thread Matt Terry
I'm banging away at installing MPL on top of python.org's python.  I'm at
the libfreetype/freetype issue.  There seems to be three approaches to
getting MPL's dependencies.

1) install libpng[1] and freetype[2] from source
2) install XQuartz[3] and twiddle /opt/X11, /usr/X11 (per Russell's
directions[4]) so MPL finds XQuartz's libpng/freetype
3) install XQuartz[3] and install pkg-config[5] so MPL can find the
cleverly installed libraries
4) create the MPL binary installer and use that

Option 1 seems simple-est, but installing freetype requires more than
./configure && make && sudo make install.
Option 2 worries me with the manual symlinking and such.  Who knows what
we'll clobber.
Option 3: haven't fully explored.
Option 4: This would require some input from whoever (Gohlke?, Owen?) makes
the binary installers.


[1] http://www.libpng.org/pub/png/libpng.html
[2] http://www.freetype.org/index.html
[3] http://xquartz.macosforge.org/landing/
[4]
http://www.astro.washington.edu/users/rowen/BuildingMatplotlibForMac.html
[5] http://www.freedesktop.org/wiki/Software/pkg-config/


On Thu, Aug 22, 2013 at 8:24 PM, Matt Terry  wrote:

>  > with/without third party X
>> I'm not quite sure what you mean by with/without third party X. If you
>> are referring to Tck/Tk:
>>
>
> I had an issue where MPL found the headers to freetype in /opt/local, but
> library in /usr/X11.  Hilarity ensues.  I *think* /usr/X11 showed up when I
> installed XQuartz, but I don't have a clean image to compare against.
>
> The with-X / without-X builds would be there to check that the default
> search paths are compatible with common environments.
>
> -matt
>
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] Matplotlib V1.3 suptitle

2013-08-23 Thread Sterling Smith

On Aug 23, 2013, at 7:43AM, Benjamin Root wrote:

> 
> 
> On Fri, Aug 23, 2013 at 9:57 AM, Peter Bloomfield 
>  wrote:
> Good morning,
> 
> I am running openSuSE 12.2, and this morning I upgraded matplotlib to v1.3, 
> and now I am having a problem with suptitle.
> I use the following lines to put a title and legend onto a plot figure
> 
> import matplotlib.pyplot as plt
> plt.figure(1)
> plt.suptitle( "Study# : " + os.path.basename( inImage_IO.IO_FileName ) + \
> "\n" + "{ Acquired : " + \
> AcqDateTime.strftime( "%b %d, %Y - $T_o$ @ %H:%M:%S" ) + " }", \
> y=0.98, weight="roman", size="large" )
> plt.suptitle( "{Creation Date : " + AnalysisTOD + "}",
> x=0.86, y=0.03, weight="roman", size="x-small" )
> 
> Under v1.3, I only get the 'Creation Date : ...' text at the bottom of the 
> figure the 'Study# ...' string is not present at the top. If I change
> it to
> 
> import matplotlib.pyplot as plt
> plt.figure(1)
> plt.suptitle( "Study# : ", y=0.98, weight="roman", size="large" )
> plt.suptitle( "{Creation Date : " + AnalysisTOD + "}",
> x=0.86, y=0.03, weight="roman", size="x-small" )
> 
> the 'Creation Date : ...' text at the bottom of the figure the 'Study# : ' 
> string is at the top.
> 
> So the problem is in the string construct in the first example. Does anybody 
> know of a way to get around this?
> 
> Thanks in advance
> 
> Peter
> 
> 
> Oh, wow... we didn't think anybody was using that "misfeature".  This was a 
> bug we fixed for 1.3, in that users complained that calling plt.title() would 
> update an existing title, but plt.suptitle() would not (multiple calls would 
> just result in text overlaid on top of each other).  We fixed this for 1.3 so 
> that there is a single text object that is kept and is revised in subsequent 
> calls to suptitle().  To get what you want, you will have to consolidate 
> those strings into one.
> 
> Cheers!
> Ben
Ben,

I am glad for the fix.

Peter,

You could use 
gcf().text(x,y,'String 1',**keyw)
gcf().text(x2,y2,'String 2',**keyw)

-Sterling
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] Matplotlib V1.3 suptitle

2013-08-23 Thread Benjamin Root
On Fri, Aug 23, 2013 at 9:57 AM, Peter Bloomfield <
peter.bloomfi...@camhpet.ca> wrote:

>  Good morning,
>
> I am running openSuSE 12.2, and this morning I upgraded matplotlib to
> v1.3, and now I am having a problem with suptitle.
> I use the following lines to put a title and legend onto a plot figure
>
>  import matplotlib.pyplot as plt
> plt.figure(1)
>
> plt.suptitle( "Study# : " + os.path.basename( inImage_IO.IO_FileName ) + \
>
> "\n" + "{ Acquired : " + \
>
> AcqDateTime.strftime( "%b %d, %Y - $T_o$ @ %H:%M:%S" ) + " }", \
>
> y=0.98, weight="roman", size="large" )
>
> plt.suptitle( "{Creation Date : " + AnalysisTOD + "}",
>
> x=0.86, y=0.03, weight="roman", size="x-small" )
>
>
>  Under v1.3, I only get the 'Creation Date : ...' text at the bottom of
> the figure the 'Study# ...' string is not present at the top. If I change
> it to
>
>  import matplotlib.pyplot as plt
> plt.figure(1)
>
> plt.suptitle( "Study# : ", y=0.98, weight="roman", size="large" )
>
> plt.suptitle( "{Creation Date : " + AnalysisTOD + "}",
>
> x=0.86, y=0.03, weight="roman", size="x-small" )
>
>  the 'Creation Date : ...' text at the bottom of the figure the 'Study# :
> ' string is at the top.
>
>
> So the problem is in the string construct in the first example. Does
> anybody know of a way to get around this?
>
>
> Thanks in advance
>
>
> Peter
>
>
Oh, wow... we didn't think anybody was using that "misfeature".  This was a
bug we fixed for 1.3, in that users complained that calling plt.title()
would update an existing title, but plt.suptitle() would not (multiple
calls would just result in text overlaid on top of each other).  We fixed
this for 1.3 so that there is a single text object that is kept and is
revised in subsequent calls to suptitle().  To get what you want, you will
have to consolidate those strings into one.

Cheers!
Ben
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


[Matplotlib-users] Matplotlib V1.3 suptitle

2013-08-23 Thread Peter Bloomfield

Good morning,

I am running openSuSE 12.2, and this morning I upgraded matplotlib to 
v1.3, and now I am having a problem with suptitle.

I use the following lines to put a title and legend onto a plot figure

import matplotlib.pyplot as plt

plt.figure(1)

plt.suptitle( "Study# : " + os.path.basename( inImage_IO.IO_FileName ) + \

"\n" + "{ Acquired : " + \

AcqDateTime.strftime( "%b %d, %Y - $T_o$ @ %H:%M:%S" ) + " }", \

y=0.98, weight="roman", size="large" )

plt.suptitle( "{Creation Date : " + AnalysisTOD + "}",

x=0.86, y=0.03, weight="roman", size="x-small" )


Under v1.3, I only get the 'Creation Date : ...' text at the bottom of 
the figure the 'Study# ...' string is not present at the top. If I change

it to

import matplotlib.pyplot as plt

plt.figure(1)

plt.suptitle( "Study# : ", y=0.98, weight="roman", size="large" )

plt.suptitle( "{Creation Date : " + AnalysisTOD + "}",

x=0.86, y=0.03, weight="roman", size="x-small" )

the 'Creation Date : ...' text at the bottom of the figure the 'Study# : 
' string is at the top.



So the problem is in the string construct in the first example. Does 
anybody know of a way to get around this?



Thanks in advance


Peter


--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


[Matplotlib-users] Explicitly clearing Matplotlib/Pylab figure buffers

2013-08-23 Thread Kari Aliranta
Hello, fellow Matplotlib users,


I'm embedding some Matplotlib figures into GUI (PyQt4) windows or widget 
canvases using qt4agg as the backend. I'm having problems with these 
figures popping up any time when some other part of the program calls 
pyplot.show().

How do you avoid this showing of previous figures? Is there some hidden 
buffer where the figures go? If there is, what is the way to clear this 
buffer, or preferably avoid putting figures in this buffer altogether? 
I'd be happy to handle these figures as simple individual objects.

(I'm aware that this "hidden buffer" may be the pylab/pyplot buffer. I 
tried deepcopying the figure and then clearing the pylab buffer with 
pylab.clf() , but figures don't seem to be deepcopyable.)


A  typical situation is the following:

- There is a window with a widget. The widget (widgetMpl in the code 
below) has a slightly customized FigureCanvas in it. The drawing code is 
activated by clicking a button in the window. The code goes as follows.

 # The plot method returns a complicated instance of Figure with 
several axes, constructed with Pylab.
 previewFigure = 
self.parent.experiment.file_to_plot.plot(show=False, n_channels=10)

 self.ui.widgetMpl.canvas.figure = previewFigure
 self.ui.widgetMpl.canvas.draw()


- I draw the figure in the window once, or several times with different 
file_to_plot, by pressing the button. I may or may not close the window 
with the aforementioned widget.

- Elsewhere in the program there is another window with very simple 
drawing code using pyplot. When this code calls pyplot.show(), all the 
figures drawn in the first window will show up.




--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] Intersecting polygons

2013-08-23 Thread Jon Ramsey
Dear Chris and List,

pdf2ps is usually just a front end to a long-winded ghostscript ("gs")
command.  On my system this comes out as:

gs -q -dNOPAUSE -dBATCH -P- -dSAFER -sDEVICE=ps2write
"-sOutputFile=$outfile" -c save pop -f "$1"

If you're feeling brave, you can look at the ghostscript manual for ways to
improve upon the results (http://www.ghostscript.com/doc/9.07/Use.htm).

I've had to play this "game" with Astronomy journals in the past, and what
I actually did was save the output as a JPEG of ridiculously high
resolution and then put a postscript wrapper around it using jpeg2ps (
http://www.pdflib.com/download/free-software/jpeg2ps/).
Not pretty, but it works.

Good luck,
Jon



Jon Ramsey
===
jon.p.ram...@gmail.com


On 23 August 2013 03:32, Chris Beaumont  wrote:

> Thanks for these tips. It looks like some programs (like illustrator, and
> pdf2ps) are semi-smart about handling transparency when converting to ps.
> Both have their quirks (illustrator seems to mess up the bounding box,
> pdf2ps makes the text look worse/fuzzy).
>
> Is this the recommended/best strategy?
>
> Thanks,
> chris
>
>
> On Thu, Aug 22, 2013 at 8:04 PM, Jerzy Karczmarczuk <
> jerzy.karczmarc...@unicaen.fr> wrote:
>
>> Chris Beaumont :
>> >
>> > I have a semitransparent plot that I rather like:
>> ...
>> > I'd like to publish something like this in a journal which requires
>> > EPS figures. Unfortunately, EPS doesn't support transparency.
>> >
>> > How hard would it be to coax matplotlib (or another tool) to convert
>> > this semi-transparent figure into a non-semitransparent figure that
>> > looks the same?
>>
>> I won't claim that this is an ultimate solution, but what I did a few
>> times was to
>> 1. Choose the svg backend, savefig the picture as svg.
>> 2. Open in Inkscape and export as .eps.
>>
>> The result was satisfactory.
>>
>> Jerzy Karczmarczuk
>>
>>
>>
>> --
>> Introducing Performance Central, a new site from SourceForge and
>> AppDynamics. Performance Central is your source for news, insights,
>> analysis and resources for efficient Application Performance Management.
>> Visit us today!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
>> ___
>> Matplotlib-users mailing list
>> Matplotlib-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>
>
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> Matplotlib-users mailing list
> Matplotlib-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] Intersecting polygons

2013-08-23 Thread Florian M. Wagner

  
  
Hey Chris,
  
  I had a similar problem. I saved the transparent objects, so the
  polygons in your case, as a high-resolution png and the axes,
  dots, lines, text objects and everything else to an eps. Finally,
  I just layed them on top of each other in Illustrator and saved as
  eps, which produced a decent result. But this was only a
  work-around as well. They might be better options...
  
  Cheers
  Florian
  
  Am 23.08.2013 00:55, schrieb Chris Beaumont:


  
  Hi,


I have a semitransparent plot that I rather like:




I'd like to publish something like this in a journal which
  requires EPS figures. Unfortunately, EPS doesn't support
  transparency. 


How hard would it be to coax matplotlib (or another tool)
  to convert this semi-transparent figure into a
  non-semitransparent figure that looks the same? It would
  consist of more polygons, each of which has a constant RGB
  value in the transparent figure.


I don't want to rasterize the lines, because I like zooming
  absurdly far into plots, and having them stay crisp.


Cheers,
Chris
  
  
  
  
  --
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
  
  
  
  ___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users



  

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users