matplotlib-devel Mailing List for matplotlib (Page 513)

Win32 Warning: This is the first release I've done since my windows
  build syste dies and I had to reinstall a bunch of tools and some
  version numbers in my GTK build environment changed (eg my GTK
  setup).  Let me know if you encounter any problems.  As always, try
  removing site-packages/matplotlib and reinstalling before reporting
  any problems

TeX support : Now you can (optionally) use TeX to handle *all* of the
  text elements in your figure with the rc param text.usetex (*Agg and
  PS only).  PS support requires tex, dvips and Ghostscript 8.51
  (older versions do not work properly -- test your version with
  'gs --version').  Agg support requires tex and dvipng.  A
  directory ~/.tex.cache is created where support files are cached for
  later reuse.  We opted to ues TeX rather than LaTeX because it is
  faster and can do all the things we thought useful for figure text
  snippets.  See http://matplotlib.sf.net/screenshots.html#tex_demo
  and http://matplotlib.sf.net/matplotlib.texmanager.html.  There are
  several new rc params for configuring tex/latex support

    # use tex/latex for all text handling
    text.usetex         : False  
    # tex is faster, but latex is required to use special font
    # packages.  See font.latex.package
    text.tex.engine     : latex  
    
    # This must be an available LaTeX font package, 
    # like 'times' or 'pslatex' ; only applies if text.usetex 
    # is true
    font.latex.package  : type1cm  

  Special thanks to Darren Dale for lots of hair-pulling work
  customizing, enhancing and debugging the ps backend for LaTeX
  support.

Masked arrays: Support for masked arrays in line plots, pcolor and
  contours.  There are some problems with filled contours and masked
  arrays.  Thanks Eric Firing and Jeffrey Whitaker.

Contour levels arg changes: see http://matplotlib.sf.net/API_CHANGES
  for details

Byte images: Much faster imaeg loading for MxNx4 or MxNx3 UInt8
  images, which bypasses the memory and CPU intensive integer/floating
  point conversions.  Nicolas Girard

New image resize options interpolation options.  New values for the
  interp kwarg are
        
    'nearest', 'bilinear', 'bicubic', 'spline16', 'spline36',
    'hanning', 'hamming', 'hermite', 'kaiser', 'quadric', 'catrom',
    'gaussian', 'bessel', 'mitchell', 'sinc', 'lanczos', 'blackman'

  See help(imshow) for details, particularly the interpolation,
  filternorm and filterrad kwargs.

Text and dashes - Daishi Harada contributed a patch for connecting
  text to points with lines.  See examples/dashpointlabel.py and
  examples/dashtick.py

Fast markers on win32: The marker cache optimization is finally
  available for win32, after an agg bug was found and fixed (thanks
  Maxim!).  Line marker plots should be considerably faster now on
  win32.

set deprecated: use setp instead; a simple, mostly braindead,
  conversion script is provided below

Qt in ipython/pylab: You can now use qt in ipython pylab mode.  Thanks
  Fernando Perez and the Orsay team!

Agg wrapper proper: Started work on a proper agg wrapper to expose
  more general agg functionality in mpl.  See examples/agg_test.py.
  Lots of wrapping remains to be done.

New scalar formatter: Darren Dale did a lot of work to make scalar
  formatting smarter in pathalogical cases.  See
  examples/newscalarformatter_demo.py

Small features: linewidth and faceted kwarg to scatter to control
  edgewidth and color, autolegending now inspects line segments in
  addition to vertices, upgraded to agg23, new example showing how to
  use line collections examples/line_collection.py, fixed antialiased
  property setting in agg, added a postscript papersize rc option,
  added an example showing how to embed mpl in a qt app
  examples/embedding_in_qt.py, arrow keys now exposed in mpl's GUI
  neutral event handling, added "among" kwarg to axes picker function
  to limit picks, added autoscale_on property to Axes to control
  whether or not autoscaling is done.

Bug fixes: fixed a contour masked array bug, contour memory leak




# Here is a script to recursively convert set and get to setp and
# getp. Please backup entire directory recursively before
# running this script

from matplotlib.cbook import listFiles

for fname in listFiles('.', '*.py'):

    lines = []
    cnt = 0
    for line in file(fname):
        if line.lstrip().startswith('set('):
            line = line.replace('set(', 'setp(')
            cnt +=1
        if line.lstrip().startswith('get('):
            line = line.replace('get(', 'getp(')
            cnt +=1
        lines.append(line)
        
    file(fname, 'w').writelines(lines)
    print '%s\t: %d replacements'%(fname,cnt)

>>>>> "Stefan" == Stefan Kuzminski <pon...@ya...> writes:

    Stefan> Is there an easy way to hide the axis lines? ( bounding
    Stefan> box of the figure ).  I set the xaxis._visible to false
    Stefan> and that hid the ticks, I also tried setting figure(
    Stefan> edgecolor='white' ).

This may be a confusion of terminology.

In matplotlib, the figure box is the entire canvas, and is
controlled by fig.figurePatch.  The Axes bounding box is the white box
inside the figure box, and is controlled by ax.axesPatch.  Both are
matplotlib.patches.Rectangle instances.  The Axis objects are the X
and Y Axis and control the ticks and tick labels.

To turn off the Axes box entirely, you can do

  ax.set_frame_on(False)

JDH

Is there an easy way to hide the axis lines? ( bounding box of the
figure ).  I set the xaxis._visible to false and that hid the ticks, I
also tried setting figure( edgecolor='white' ).

thanks,
S 

--- John Hunter <jdh...@ac...> wrote:

> >>>>> "Stefan" == Stefan Kuzminski <pon...@ya...> writes:
> 
>     Stefan> I'm wondering how difficult it would be to add a
>     Stefan> speedometer-like 'dial' plot type.  ( apparently this
>     Stefan> appeals to executive types ) I imagine it would take a
>     Stefan> range and a scalar value which would be the location of
>     Stefan> the 'needle'.  Any pointers to how to craft such a thing
>     Stefan> would be appreciated.
> 
> I think you could reuse most of the PolarAxes code for this, but
> instead of using a polar transform place a line or line/arrow in the
> center pointing to the "speed"
> 
> JDH
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Hi all,
	We have updated the OSX binaries which include all dependencies in a
single installer (i.e. libpng, freetype, numarray, Numeric, ...).  There
are 10.3/panther and 10.4/tiger binaries which include mpl-0.80 and
basemap-0.4.2.  The panther binary includes wxpython and the tiger
binary uses the system included wxpython.  Please feel free to contact
me if you experience any problems.

"Tools, Applications" Section:
http://sda.iu.edu/projects.html

- Charlie

On Mon, 2005-06-06 at 08:58 -0500, John Hunter wrote:
> >>>>> "Nicholas" == Nicholas Young <su...@su...> writes:
> 
>     Nicholas> Hi, There have been several times when I've come across
>     Nicholas> conditions where I want a user to be able to pick from
>     Nicholas> amongst a limited number of objects on plots containing
>     Nicholas> lots of other objects.  Previously I've written my own
>     Nicholas> functions to do this but it occurs to me that this is
>     Nicholas> likely to be something others will want to do.  To this
>     Nicholas> end I've made a very simple addition to the Axes.pick
>     Nicholas> method to take a keyword argument test which, if a
>     Nicholas> callable, is used to filter the objects from which to
>     Nicholas> pick.  A patch to CVS containing the alteration is
>     Nicholas> enclosed.
> 
> Hi Nick,
> 
> Although using a function may be the most general way of making
> picking selective, I wonder if it is the most intuitive.  I suspect
> that 9 time out of 10, a user will just want to pass a list of objects
> on which to pick.  Do you agree?

I do - but for flexibility how about this patch which allows both
options? The kind of list intersection I've used isn't the most
efficient but as mpl isn't at its most efficient with large numbers of
artists I didn't think that would be a problem.

Nick

>>>>> "Nicholas" == Nicholas Young <su...@su...> writes:

    Nicholas> Hi, There have been several times when I've come across
    Nicholas> conditions where I want a user to be able to pick from
    Nicholas> amongst a limited number of objects on plots containing
    Nicholas> lots of other objects.  Previously I've written my own
    Nicholas> functions to do this but it occurs to me that this is
    Nicholas> likely to be something others will want to do.  To this
    Nicholas> end I've made a very simple addition to the Axes.pick
    Nicholas> method to take a keyword argument test which, if a
    Nicholas> callable, is used to filter the objects from which to
    Nicholas> pick.  A patch to CVS containing the alteration is
    Nicholas> enclosed.

Hi Nick,

Although using a function may be the most general way of making
picking selective, I wonder if it is the most intuitive.  I suspect
that 9 time out of 10, a user will just want to pass a list of objects
on which to pick.  Do you agree?

JDH

Hi,

There have been several times when I've come across conditions where I
want a user to be able to pick from amongst a limited number of objects
on plots containing lots of other objects.  Previously I've written my
own functions to do this but it occurs to me that this is likely to be
something others will want to do.  To this end I've made a very simple
addition to the Axes.pick method to take a keyword argument test which,
if a callable, is used to filter the objects from which to pick.  A
patch to CVS containing the alteration is enclosed.

Nick

I worked quite a bit on the TeX support in MPL this weekend. I think the co=
de=20
is ready for wider testing, the changes are in CVS. Note there are a few ne=
w=20
options in .matplotlibrc:=20

1) font.latex.package allows you to select the latex fonts, but your select=
ion=20
has to be a valid latex package.

2) text.tex.engine allows you to select tex or latex to handle the text=20
layout.

3) ps.usedistiller allows users to pass any ps/eps output through=20
ghostscript's distiller (this is a necessary step for creating eps output i=
f=20
tex is handling the text). This will convert the fonts, shrink the file siz=
e,=20
and the resulting file should open more quickly. I have tested with=20
gnu-ghostscript-8.16. ghostscript-7.07 seems to have trouble getting the ep=
s=20
bounding box right.

4) ps.distiller.res allows the dpi to be set. It defaults to 600, but I=20
personally have it set to 6000 to get the best on-screen results for=20
files embedded in tex and converted to pdf. (JDH- note this option was=20
briefly called text.tex.epsres)

I also silenced the tex, dvips and gs stdout messages. If you want to see a=
ll=20
the reports that they print, you can set verbose.level =3D debug-annoying

Changes are in CVS.

Darren

>>>>> "Stefan" == Stefan Kuzminski <pon...@ya...> writes:

    Stefan> I'm wondering how difficult it would be to add a
    Stefan> speedometer-like 'dial' plot type.  ( apparently this
    Stefan> appeals to executive types ) I imagine it would take a
    Stefan> range and a scalar value which would be the location of
    Stefan> the 'needle'.  Any pointers to how to craft such a thing
    Stefan> would be appreciated.

I think you could reuse most of the PolarAxes code for this, but
instead of using a polar transform place a line or line/arrow in the
center pointing to the "speed"

JDH

I'm wondering how difficult it would be to add a speedometer-like
'dial' plot type.  ( apparently this appeals to executive types )  I
imagine it would take a range and a scalar value which would be the
location of the 'needle'.  Any pointers to how to craft such a thing
would be appreciated.

thanks,
Stefan

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

John Hunter wrote:

>>>>>>"Jeff" == Jeff Whitaker <js...@fa...> writes:
>>>>>>            
>>>>>>
>
>    Jeff> Eric: The combination of your two patches (cntr_bugfix.diff
>    Jeff> and cntr_bugfix2.diff) does indeed fix all of the problems
>    Jeff> with the basemap examples.  Many thanks!
>
>Are you testing from CVS ?  I committed them and want to make sure I
>have the right version in.
>
>Thanks to all...
>
>JDH
>  
>
John:  Following up on that 'ZeroDivisionError' - it goes away when I 
replace ticker.py with version 1.26 from CVS.  Must be due to Darren's 
changes yesterday.

To answer your original question - yes, it appeare you committed all the 
necessary fixes to cntr.c.

-Jeff

-- 
Jeffrey S. Whitaker         Phone : (303)497-6313
NOAA/OAR/CDC  R/CDC1        FAX   : (303)497-6449
325 Broadway                Web   : http://www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124

John Hunter wrote:

>>>>>>"Jeff" == Jeff Whitaker <js...@fa...> writes:
>>>>>>            
>>>>>>
>
>    Jeff> Eric: The combination of your two patches (cntr_bugfix.diff
>    Jeff> and cntr_bugfix2.diff) does indeed fix all of the problems
>    Jeff> with the basemap examples.  Many thanks!
>
>Are you testing from CVS ?  I committed them and want to make sure I
>have the right version in.
>
>Thanks to all...
>
>JDH
>  
>
John:  I was using a cvs version from the morning of 6/1, with Eric's 
two patches applied.  I just tried a new cvs checkout (from the evening 
of 6/2), but now whatever script I run I get the  'Divide by Zero' 
errors reported by Nicholas Girard yesterday.

-Jeff

-- 
Jeffrey S. Whitaker         Phone : (303)497-6313
NOAA/OAR/CDC  R/CDC1        FAX   : (303)497-6449
325 Broadway                Web   : http://www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124

>>>>> "Jeff" == Jeff Whitaker <js...@fa...> writes:

    Jeff> Eric: The combination of your two patches (cntr_bugfix.diff
    Jeff> and cntr_bugfix2.diff) does indeed fix all of the problems
    Jeff> with the basemap examples.  Many thanks!

Are you testing from CVS ?  I committed them and want to make sure I
have the right version in.

Thanks to all...

JDH

Eric Firing wrote:

> John, Jeff,
>
> The attached patch against the cntr.c in cvs does the following:
>
> 1) Fixes the bug you (Jeff) described above.
>
> 2) Adds a print function for debugging, but normally unused.
>
> 3) Fixes a minor bug in which space for an array of ints was allocated 
> where only an array of chars was used.
>
> The original masked array contourf bug is still there, but I suspect 
> (and hope!) it will not present a serious problem for basemap.  I 
> still want to find and fix it, but that may take a long time.
>
> I want to make some minor cleanups and one API change in contour.py, 
> but I will leave that for a separate message, probably within 24 hours.
>
> Eric

Eric: The combination of your two patches (cntr_bugfix.diff and cntr_bugfix2.diff) does indeed fix all of the problems with the basemap examples.  Many thanks!

-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/CDC  R/CDC1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

On Thursday 02 June 2005 1:55 pm, you wrote:
> Darren Dale <dd...@co...> writes:
> [snip]
>
> > the ps backend will produce a transitional eps file with a bunch of
> > psfrag markers, along with an associated tex file. backend_ps runs latex
> > on the tex file, which embeds the eps, and replaces the markers with the
> > actual text. Now we have a ps file, which can be converted into an eps =
if
> > desired with ps2epsi, or maybe this could be changed to a call to
> > ghostscript: gs -dNOPAUSE -sDEVICE=3Depswrite -sOutputFile=3Dtex_demo.e=
ps
> > tex_demo.ps. As far as the user is concerned, you type savefig('foo.eps=
')
> > and get foo.eps, blissfully unaware of all the intermediate steps.
>
> http://www.tex.ac.uk/cgi-bin/texfaq2html?label=3Dmpprologues
>
> describes a similar situation, but they use dvips -E to generate the
> eps file directly. Could you do that rather than using ghostscript?
> Apart from anything else, it should be quicker.

I had tried this. -E does not seem to be very robust, I cant view the=20
resulting eps files, they appear to be corrupted.

>
> > Here is my current problem. I embed an eps file generated with ps2epsi =
in
> > a new tex document. The dvi looks ok, but after dvips, the text in my
> > figure gets inverted and shifted. This seems to be a bigger problem when
> > using latex classes that do some font handling behind the scenes, for
> > example, article seems ok, but revtex4 and ha-prosper yield unacceptable
> > results.
>
> As an alternative, could you use the .tex/.eps pair directly. This
> would allow you to use the same font and text size in the figure
> caption as in the main document.

This is the way it was originally done. I think it is much better to have a=
=20
single nugget than to have a half complete figure. I think scientific=20
journals may have a problem with submitting these kinds of half complete=20
figures for publication.

>
> > On the other hand, if I use ghostscript to generate the eps, I can
> > embed the files and the printed page looks fine, but the fonts look
> > terrible on screen.
>
> If you are using xdvi, then I found that too. I blamed it on
> ghostscript being used to render the graphics with low resolution, or
> not antialiasing the text.
>
[...]
> >
> > How can MPL deal with these non-MPL issues? I know John doesn't like the
> > idea of handling text in eps as images, but if we did, could that be a
> > suitable workaround?
>
> I agree with John here.

So do I. But I have a thesis, two papers, and two talks to write. I was hop=
ing=20
practicality might temporarily win out, but I dont know for sure that such =
an=20
effort would even solve the problem.

>
> > Does anyone have another suggestion?
>
> Hope these suggestions might help.
>
> Chris
>
> PS One further thought I had is MetaPost.
> http://www.tex.ac.uk/cgi-bin/texfaq2html?label=3DMP Is it possible for
> matplotlib to embed the tex expressions in the same way that metapost
> does? This might not solve your problem however, as xdvi currently has
> a problem displaying them - see
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D295205 for details.
>
> PPS If you need something in a hurry (for your thesis?), can you
> create the whole thing as a bitmap? or use the latex "ite" package to
> position labels? If you do the latter, there is a patch I should send
> you - otherwise it clashes with various packages.

Thank you for the suggestions, but they are both significant deviations fro=
m=20
what I already have in place, and I have to prepare a talk for June 13. In=
=20
the worst case scenario, I will just set usetex to false, and make some=20
temporary changes in my local installation to work around some font layout=
=20
issues that usetex had addressed.

=46onts, fonts, fonts. My new f-word.

=2D-=20
Darren S. Dale

Bard Hall
Department of Materials Science and Engineering
Cornell University
Ithaca, NY. 14850

dd...@co...
http://people.ccmr.cornell.edu/~dd55/

Nicolas Girard wrote:

> That beeing said, I'm also in the need of a way of saving eps figures of gray 
> contours in negative, in order to save toner... with the standard gray 
> colormap, my contours are very dark, leading to a huge consumption of toner.
> 
> With a gray colormap "in negative", the result would be at least as readable 
> and consumes much less toner.
> 
> Two strategies are possible here:
> 
> - either display the gray colormap as usual on the screen, but save the figure 
> in negative with the "eps" or "png" backends (this is AFAIK the default 
> behaviour of IDL),

-1.  One of mpl's strengths is that it shows you on screen what you get 
on paper, I'd _hate_ to folow IDL here (or for that matter, on just 
about anything else).

> - or provide a "negative gray" colormap ; I've tried to hack the cm.py in that 
> way, and tried something like:
> 
> _ngray_data =  {'red':   ((0., 1, 1), (1., 0, 0)),
>                'green': ((0., 1, 1), (1., 0, 0)),
>                'blue':  ((0., 1, 1), (1., 0, 0))}

I've meen meaning to add a .reversed() method to the colormap instances, 
which will automatically return an instance of the given colormap with 
its lookup table reversed, and the name simply with a suffix appended 
(_r, _rev, r, ...).  I think this is the right solution, and I also 
think we should supply, by default, reversed versions of the standard 
colormaps.  At the very least, the gray_rev (or whatever it gets called) 
can be _extremely_ useful.

> but there seems to be a problem with the highest values, that keep beeing 
> displayed in white instead of black.

Mmh, I haven't seen this.  I have the same defined in my default 
run-time config loaded by ipython, and I haven't seen this kind of 
clipping, but maybe I just haven't noticed it.  I've been using 
matshow() and haven't seen this, I'll look again in more detail later.

Cheers,

f

Darren Dale <dd...@co...> writes:
[snip]
> the ps backend will produce a transitional eps file with a bunch of psfrag 
> markers, along with an associated tex file. backend_ps runs latex on the tex 
> file, which embeds the eps, and replaces the markers with the actual text. 
> Now we have a ps file, which can be converted into an eps if desired with 
> ps2epsi, or maybe this could be changed to a call to ghostscript: gs 
> -dNOPAUSE -sDEVICE=epswrite -sOutputFile=tex_demo.eps tex_demo.ps. As far as 
> the user is concerned, you type savefig('foo.eps') and get foo.eps, 
> blissfully unaware of all the intermediate steps.


http://www.tex.ac.uk/cgi-bin/texfaq2html?label=mpprologues

describes a similar situation, but they use dvips -E to generate the
eps file directly. Could you do that rather than using ghostscript?
Apart from anything else, it should be quicker.


> 
> Here is my current problem. I embed an eps file generated with ps2epsi in a 
> new tex document. The dvi looks ok, but after dvips, the text in my figure 
> gets inverted and shifted. This seems to be a bigger problem when using latex 
> classes that do some font handling behind the scenes, for example, article 
> seems ok, but revtex4 and ha-prosper yield unacceptable results.

As an alternative, could you use the .tex/.eps pair directly. This
would allow you to use the same font and text size in the figure
caption as in the main document. 

> 
> On the other hand, if I use ghostscript to generate the eps, I can
> embed the files and the printed page looks fine, but the fonts look
> terrible on screen. 

If you are using xdvi, then I found that too. I blamed it on
ghostscript being used to render the graphics with low resolution, or
not antialiasing the text.


> Here is a comment from the afpl website 
> http://www.cs.wisc.edu/~ghost/doc/AFPL/8.50/Issues.htm:
> 
> ---
> pswrite device generates low level PostScript.
> 
> pswrite and epswrite devices reduce everything to path, fill, stroke, clip 
> image, and imagemask operations. Although the resulting file prints OK it 
> produces unsatisfactory results when scaled, distilled or imported into 
> graphic editors. The file can easily exceed 4GB and hit file size limits in 
> some applications or operation systems. Handling of big files is slow. 
> ---
> The associated bug report (filed over 2 years ago) says this is a low priority 
> problem.
> 
> How can MPL deal with these non-MPL issues? I know John doesn't like the idea 
> of handling text in eps as images, but if we did, could that be a suitable 
> workaround? 

I agree with John here. 


> Does anyone have another suggestion?

Hope these suggestions might help. 

Chris

PS One further thought I had is MetaPost.
http://www.tex.ac.uk/cgi-bin/texfaq2html?label=MP Is it possible for
matplotlib to embed the tex expressions in the same way that metapost
does? This might not solve your problem however, as xdvi currently has
a problem displaying them - see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=295205 for details.

PPS If you need something in a hurry (for your thesis?), can you
create the whole thing as a bitmap? or use the latex "ite" package to
position labels? If you do the latter, there is a patch I should send
you - otherwise it clashes with various packages.
 

John, Jeff,

> Eric:  Thanks - contour indeed now seems to work perfectly with masked 
> arrays, but I still have problems with contourf (see attached 
> ortho_test.png).  Unfortunately, neither of your suggested workarounds 
> help, the first makes no difference and the second makes it much worse.
> -Jeff

The attached patch against the cntr.c in cvs does the following:

1) Fixes the bug you (Jeff) described above.

2) Adds a print function for debugging, but normally unused.

3) Fixes a minor bug in which space for an array of ints was allocated 
where only an array of chars was used.

The original masked array contourf bug is still there, but I suspect 
(and hope!) it will not present a serious problem for basemap.  I still 
want to find and fix it, but that may take a long time.

I want to make some minor cleanups and one API change in contour.py, but 
I will leave that for a separate message, probably within 24 hours.

Eric

I have been trying to deal with some font problems related to the new tex=20
capabilities in MPL. Let me summarize what MPL is doing, when text.usetex i=
s=20
true in rc:

texmanager runs TeX (or LaTeX) on a string, and John has somehow extracted =
an=20
image of that string and its bbox information to intelligently layout and=20
render the text.

the ps backend will produce a transitional eps file with a bunch of psfrag=
=20
markers, along with an associated tex file. backend_ps runs latex on the te=
x=20
file, which embeds the eps, and replaces the markers with the actual text.=
=20
Now we have a ps file, which can be converted into an eps if desired with=20
ps2epsi, or maybe this could be changed to a call to ghostscript: gs=20
=2DdNOPAUSE -sDEVICE=3Depswrite -sOutputFile=3Dtex_demo.eps tex_demo.ps. As=
 far as=20
the user is concerned, you type savefig('foo.eps') and get foo.eps,=20
blissfully unaware of all the intermediate steps.

Here is my current problem. I embed an eps file generated with ps2epsi in a=
=20
new tex document. The dvi looks ok, but after dvips, the text in my figure=
=20
gets inverted and shifted. This seems to be a bigger problem when using lat=
ex=20
classes that do some font handling behind the scenes, for example, article=
=20
seems ok, but revtex4 and ha-prosper yield unacceptable results.

On the other hand, if I use ghostscript to generate the eps, I can embed th=
e=20
files and the printed page looks fine, but the fonts look terrible on scree=
n.=20
Here is a comment from the afpl website=20
http://www.cs.wisc.edu/~ghost/doc/AFPL/8.50/Issues.htm:

=2D--
pswrite device generates low level PostScript.

pswrite and epswrite devices reduce everything to path, fill, stroke, clip=
=20
image, and imagemask operations. Although the resulting file prints OK it=20
produces unsatisfactory results when scaled, distilled or imported into=20
graphic editors. The file can easily exceed 4GB and hit file size limits in=
=20
some applications or operation systems. Handling of big files is slow.=20
=2D--
The associated bug report (filed over 2 years ago) says this is a low prior=
ity=20
problem.

How can MPL deal with these non-MPL issues? I know John doesn't like the id=
ea=20
of handling text in eps as images, but if we did, could that be a suitable=
=20
workaround? Does anyone have another suggestion?

Darren

On Wed, 2005-06-01 at 15:49 -0700, Andrew Straw wrote:
> John Hunter wrote:
> >>>>>>"Nicholas" == Nicholas Young <su...@su...> writes:
> > 
> > 
> >     Nicholas> Now done in the attached patch, I also added support for
> >     Nicholas> MxNx3 images; as I suspected these are noticeably slower
> >     Nicholas> than MxNx4 images but I changed my mind and decided it
> >     Nicholas> was worth supporting them.
> > 
> > Great, I just committed this to CVS.
> > 
> > Andrew, if you get a minute to update from CVS, can you make sure that
> > the PIL changes don't cause a problem for your PIL using mpl scripts?
> 
> I didn't have much of a check, but image_demo3.py still works.
> 
> This may be the apparently-longstanding imshow resizing bug (that I 
> haven't followed), but this demo shows some storage behavior when 
> resizing -- horizontal stretching of the window allows the aspect ratio 
> of the image to change to horizontally stretched, but vertical 
> stretching of the window appears to scale the image to maintain its 
> original aspect ratio.

I don't think this is connected to the changes I've made; as I've
changed none of the resizing/streaching/fixed aspect code.  I've not
followed any prior discussion (and so don't know why the problem hasn't
been fixed) but if I'm reading it correctly it's fairly clear from the
general imshow code that problem is going to manifest itself.

Nick

On Wednesday 01 June 2005 18:38, John Hunter wrote:

> Nicolas wants a standard
> colormap but with the colorbar display inverted (red would still map
> to large numbers but for vertical colorbars would be on the bottom and
> for horizontal colorbars would be on the left -- the colorbar tick
> labels would change too).
>
That beeing said, I'm also in the need of a way of saving eps figures of gray 
contours in negative, in order to save toner... with the standard gray 
colormap, my contours are very dark, leading to a huge consumption of toner.

With a gray colormap "in negative", the result would be at least as readable 
and consumes much less toner.

Two strategies are possible here:

- either display the gray colormap as usual on the screen, but save the figure 
in negative with the "eps" or "png" backends (this is AFAIK the default 
behaviour of IDL),

- or provide a "negative gray" colormap ; I've tried to hack the cm.py in that 
way, and tried something like:

_ngray_data =  {'red':   ((0., 1, 1), (1., 0, 0)),
               'green': ((0., 1, 1), (1., 0, 0)),
               'blue':  ((0., 1, 1), (1., 0, 0))}

but there seems to be a problem with the highest values, that keep beeing 
displayed in white instead of black.

What do you think ?

PS: which place would be the more appropriate for this discussion, the -user 
or -devel mailing list ?

Cheers,
Nicolas

John Hunter wrote:
>>>>>>"Nicholas" == Nicholas Young <su...@su...> writes:
> 
> 
>     Nicholas> Now done in the attached patch, I also added support for
>     Nicholas> MxNx3 images; as I suspected these are noticeably slower
>     Nicholas> than MxNx4 images but I changed my mind and decided it
>     Nicholas> was worth supporting them.
> 
> Great, I just committed this to CVS.
> 
> Andrew, if you get a minute to update from CVS, can you make sure that
> the PIL changes don't cause a problem for your PIL using mpl scripts?

I didn't have much of a check, but image_demo3.py still works.

This may be the apparently-longstanding imshow resizing bug (that I 
haven't followed), but this demo shows some storage behavior when 
resizing -- horizontal stretching of the window allows the aspect ratio 
of the image to change to horizontally stretched, but vertical 
stretching of the window appears to scale the image to maintain its 
original aspect ratio.

Cheers!
Andrew

>>>>> "Keith" == Keith Goodman <kwg...@gm...> writes:

    Keith> Thought you might be interested in knowing that the Octave
    Keith> maintainers are looking into using matplotlib in Octave.

Hi Keith, 

I very recently exchanged emails with Tom Holroyd (CCd on this mail),
who was also interested in adding mpl plotting to octave.  We thought
that embedding the python interpreter might be the path of least
resistance.  It might be good for Tom to be in touch with the octave
people to avoid duplication of effort.

There are also some inconsistencies in the plotting functions between
mpl and matlab, in addition to the lack of 3D.  For example, our plot
command does not currently support plot(x, Y) or plot(X,Y) where X and
Y are matrices, though it would be easy to add such functionality.
Also, the default behavior of imshow is pretty different (in
matplotlib imshow scales the image to fit the current axes box).
These differences will surely cause some minor headaches, but for the
most part the interfaces are compatible.  A combination of
extending/patching matplotlib and doing some translation on the octave
side would probably work for most (2D) cases.

Thanks for the heads up,
JDH

Thought you might be interested in knowing that the Octave maintainers
are looking into using matplotlib in Octave.

(Octave, by the way, is a free language for numerical computation that
is mostly compatible with Matlab.)

---------- Forwarded message ----------
From: John W. Eaton <jwe at bevo dot che dot wisc dot edu>
Date: Jun 1, 2005 9:54 AM
Subject: Re: Line thickness
To: Keith Goodman <kwgoodman at gmail dot com>
Cc: octave maintainers mailing list <maintainers at octave dot org>


[I'm moving this discussion to the maintainers list.]

On  1-Jun-2005, Keith Goodman wrote:

| Take a look at the beautiful screenshots (and the code used to
| generate the plots) at
| http://matplotlib.sourceforge.net/screenshots.html

OK, it seems like it would be useful to be able to use this directly
from Octave.  What would be the best way to make that happen?  Do we
need a general Octave <-> Python interface, or can we just build
bindings for matplotlib?  How about a handle graphics compatible
interface for Octave that uses matplotlib?  The one major difficulty
that I see is that matplotlib seems to only handle 2-d plotting.

jwe

On Wednesday 01 June 2005 18:50, Fernando Perez wrote:
>
> I wonder though: if we also get 'reversed' colormaps, is this going to
> be a cause for confusion with the 'reversed' colorbar keyword?  It may
> not be a problem in the end, as long as the two different ideas are
> clearly explained, to prevent others falling into the same trap I did.
>
Please feel free to use any keyword you want, provided the feature is 
implemented ! English is not my native language, so I just came to "reverse" 
as the closest word to what I had in mind, but for sure there must be better 
alternatives (invert, mirror, whatever)

Nicolas