matplotlib-devel Mailing List for matplotlib

John Hunter wrote:
>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
> 
> 
> 
> Fernando> Well, I actually tried to see it but gv (Fedora Core 2)
> Fernando> chokes on the file: CPU utilization goes to 100% after
> Fernando> displaying the axes, labels, and a tiny bit of the
> Fernando> graph. I killed it after a while.
> 
> I had the same problem with ggv (but I converted it with ps2pdf and
> viewed it as pdf). What are you using as a PS viewer Paul?
GGV (i.e. Gnome ghostview)
> One thing that concerns about embedding truetype fonts in PS figures
> is that they don't look very good in standard viewers (xdvi, ggv)
> though they seem to print fine, at least on the printers I've tried.
> It may be that the viewers don't have very good truetype rendering
> algorithms.
It might also be the standard fonts that we use. In other words, there might be 
other truetype fonts that render better with freetype2.
> I'm on the fence about whether we should revert to the afm fonts for
> plain text in PS, and just use truetype for mathtext and if
> explicitly requested using a yet-to-be-determined mechanism. These
> certainly look better in the PS viewers I've tried. Of course the
> truetype fonts offer the same look and feel across backends, which is
> why I am on the fence. Any opinions here?
I don't see a gain here, since PS output is mainly for printing where the fonts 
look fine. Maybe we should invest more effort in a PDF backend, which displays 
better in a viewer and also does the conversion to PS. Or switch to TTF that 
render better in a viewer, such as the core MS TT fonts.
> Fernando> Are there known problems with the Postscript generated
> Fernando> by matplotlib? Can it produce EPS directly (better for
> Fernando> publication)?
> 
> EPS: yes - just save as *.eps from just about any backend.
> 
> The only reported problem I've heard was a post from Flavio Coelho
> 
> While on the same topic, I had some problems inserting matplotlib
> generated PS plots into TeXMacs, although they open normally in gv,
> for instance. have you have seen any compatibility issues for the PS
> files and other PS viewing programs? Running ps2ps on the
> matplotlib PS files resolved the problem. However I wanted to use
> TexMacs as a frontend to use matplotlib interactively...
> 
> Paul, so we could help narrow this problem with gv and your figure,
> could you try generating it with 0.60.2 (which uses AFM if I recall
> correctly) to see if it is related to the new font handling in PS?
I'll take a look at it. However, I suspect the fonts are not the problem, since 
each font only increases the size of the PS file by about 60 kBs. I suspect it 
is the size of the data and the rendering code that is causing the problem.
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

John Hunter wrote:
>>>>>>"Paul" == Paul Barrett <ba...@st...> writes:
> 
> 
> Paul> I found a bug in the Y-axis scaling. See the attached PS
> Paul> file. The Y-axis scale should go from 0. to 2.0e-11 (in
> Paul> ergs/cm**2/s/Angstrom). Instead it is zeros. Anyone having
> Paul> experience with the scaling code want to fix this?
> 
> Darren Dale posted a small fix related to ticking for exponentially
> formatted data to the users list today - you may want to see if that
> helps.
No, the latest CVS still shows the bug.
> Otherwise, if you can send me a tarball which has a script and some
> data so I can replicate the bug, I'll take a look. These bugs are
> easier to fix if you have something to test against.
Attached is the data (FITS) file and the following are the commands that I use 
to plot the data. You may need to download the pyfits module to access the file.
 >>> import pyfits
 >>> from matplotlib.matlab import *
 >>> fits = pyfits.open('C05302010011alif4ttagfcal.fit')
 >>> data = fits[1].data.field
 >>> plot(data('wave'), data('flux'))
[<matplotlib.lines.Line2D instance at 0x40da5c4c>]
 >>> show()
Thanks for taking a look at this.
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
 Fernando> Well, I actually tried to see it but gv (Fedora Core 2)
 Fernando> chokes on the file: CPU utilization goes to 100% after
 Fernando> displaying the axes, labels, and a tiny bit of the
 Fernando> graph. I killed it after a while.
I had the same problem with ggv (but I converted it with ps2pdf and
viewed it as pdf). What are you using as a PS viewer Paul?
One thing that concerns about embedding truetype fonts in PS figures
is that they don't look very good in standard viewers (xdvi, ggv)
though they seem to print fine, at least on the printers I've tried.
It may be that the viewers don't have very good truetype rendering
algorithms.
I'm on the fence about whether we should revert to the afm fonts for
plain text in PS, and just use truetype for mathtext and if
explicitly requested using a yet-to-be-determined mechanism. These
certainly look better in the PS viewers I've tried. Of course the
truetype fonts offer the same look and feel across backends, which is
why I am on the fence. Any opinions here?
 Fernando> Are there known problems with the Postscript generated
 Fernando> by matplotlib? Can it produce EPS directly (better for
 Fernando> publication)?
EPS: yes - just save as *.eps from just about any backend.
The only reported problem I've heard was a post from Flavio Coelho
 While on the same topic, I had some problems inserting matplotlib
 generated PS plots into TeXMacs, although they open normally in gv,
 for instance. have you have seen any compatibility issues for the PS
 files and other PS viewing programs? Running ps2ps on the
 matplotlib PS files resolved the problem. However I wanted to use
 TexMacs as a frontend to use matplotlib interactively...
Paul, so we could help narrow this problem with gv and your figure,
could you try generating it with 0.60.2 (which uses AFM if I recall
correctly) to see if it is related to the new font handling in PS?
Thanks,
JDH

Paul Barrett wrote:
> Yes, I have the same problem with ggv. However, it prints fine on a PS printer, 
> so I think it's ghostview.
Mmh. It still might be worth looking into. Even if it's a ghostview problem, 
 it might be possible to generate 'friendlier' PS code that doesn't kill 
ghostview so badly. As people start using matplotlib for generating EPS plots 
which will go into papers, the "if you can't preview it just print it" answer 
is going to make quite a few unhappy campers, I suspect.
I know it sucks to code around the bugs of other code, but given that 
ghostview is the near-universally available tool (I checked the problem 
against RedHat 9, Fedora 1 and Fedora 2), matplotlib might want to bow a bit 
in this case :)
Just a suggestion.
Best,
f

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:
 Paul> I found a bug in the Y-axis scaling. See the attached PS
 Paul> file. The Y-axis scale should go from 0. to 2.0e-11 (in
 Paul> ergs/cm**2/s/Angstrom). Instead it is zeros. Anyone having
 Paul> experience with the scaling code want to fix this?
Darren Dale posted a small fix related to ticking for exponentially
formatted data to the users list today - you may want to see if that
helps.
Otherwise, if you can send me a tarball which has a script and some
data so I can replicate the bug, I'll take a look. These bugs are
easier to fix if you have something to test against.
JDH
 Paul> For those interested, this is a section of the far
 Paul> ultraviolet spectrum of the variable star SS Cygni (SS Cyg
 Paul> for short) taken by NASA's Far Ultraviolet Spectroscopic
 Paul> Explorer (FUSE for short).
 Paul> -- Paul
 Paul> -- Paul Barrett, PhD Space Telescope Science Institute
 Paul> Phone: 410-338-4475 ESS/Science Software Branch FAX:
 Paul> 410-338-4767 Baltimore, MD 21218

Paul Barrett wrote:
> I found a bug in the Y-axis scaling. See the attached PS file. The Y-axis 
> scale should go from 0. to 2.0e-11 (in ergs/cm**2/s/Angstrom). Instead it is 
> zeros. Anyone having experience with the scaling code want to fix this?
> 
> For those interested, this is a section of the far ultraviolet spectrum of the 
> variable star SS Cygni (SS Cyg for short) taken by NASA's Far Ultraviolet 
> Spectroscopic Explorer (FUSE for short).
Well, I actually tried to see it but gv (Fedora Core 2) chokes on the file: 
CPU utilization goes to 100% after displaying the axes, labels, and a tiny bit 
of the graph. I killed it after a while.
Are there known problems with the Postscript generated by matplotlib? Can it 
produce EPS directly (better for publication)?
Cheers,
f

I found a bug in the Y-axis scaling. See the attached PS file. The Y-axis 
scale should go from 0. to 2.0e-11 (in ergs/cm**2/s/Angstrom). Instead it is 
zeros. Anyone having experience with the scaling code want to fix this?
For those interested, this is a section of the far ultraviolet spectrum of the 
variable star SS Cygni (SS Cyg for short) taken by NASA's Far Ultraviolet 
Spectroscopic Explorer (FUSE for short).
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218