ghostscript and usetex, need opinions

Hi Everyone,

I recently added some code to mpl such that, if you wanted to use the usetex
option, or the psdistiller option, it would check the version of any external
dependencies and raise an error if something was missing.

The ghostscript requirement is something of a headache. The conservative
distributions, such as RHEL, continue to provide ghostscript version 7.07,
but we have had problems with the postscript output being clipped with this
version. I ended up requiring version 8.16 or later, but a number of users
have had problems meeting these requirements.

If you were using the usetex option with an older version of ghostscript (8.01
for example) without any problems, please speak up so I can set the
requirements accordingly. Additionally, I will probably issue a warning
instead of raising an error in the event that ghostscript is available but
the version is old.

Darren

Darren Dale wrote:

The ghostscript requirement is something of a headache. The conservative distributions, such as RHEL, continue to provide ghostscript version 7.07, but we have had problems with the postscript output being clipped with this version.

Has anyone figured out what the problem is with older gs versions? gs has been around along time, there has got to be a way to generate EPS that would work with older versions.

Fedora Core4 is not generally a "conservative" distribution, and OS-X (10.3 anyway) doesn't provide 8.16 either. It would be great to not have this requirement.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...259...

Hey Darren,

Maybe this will help, maybe it won't.
Ubuntu provides 3 gs options in its package manager:
gs-afpl v. 8.14
gs-gpl v. 8.01
gs-esp v. 7.07

I have also installed gpl 8.50 from source.

My problems only occur when including the eps files in a latex file.
With gs-gpl 8.01 or gs-esp 7.07, the output looks like the bad_bbox
picture (it only shows the top of the figure where the plot is
covering up the text). With gs-afpl 8.14 or gpl 8.50 (from source), I
get the output in better_bbox.jpg, but there is still a thin white
line from the figure that goes through the text. So maybe the white
frame or a white background is messing things up.

But I don't think the problem really is the bounding box, I think it
is this white frame or background being drawn bigger than the bounding
box, because if I use the LaTeX command \includegraphics* (which as I
understand it clips the figure to the bounding box - as opposed to
\includegraphics without the * which does not), the output from all 4
gs versions is fine. epstopdf makes nice pdfs with a good bounding
box/paper size regardless of which version generates the eps files
(but I have to use the gatech-theis class for my thesis which does not
work with pdflatex, so I need nice eps files).

The only problem I had meeting the v >8.16 problem was getting gs to
find my system fonts. This was solved by setting GS_LIB and exporting
it in my .bashrc file. I found the font paths by running gs -h on one
of the ubuntu provided versions (i.e /usr/bin/gs-gpl -h).

Hope this helps.

Let me know if you want me to test anything else. I really value this
option and am glad to help with its development/testing/debugging.

Ryan

bad_bbox.jpg

better_bbox.jpg

···

On 1/23/06, Christopher Barker <Chris.Barker@...259...> wrote:

Darren Dale wrote:
> The ghostscript requirement is something of a headache. The conservative
> distributions, such as RHEL, continue to provide ghostscript version 7.07,
> but we have had problems with the postscript output being clipped with this
> version.

Has anyone figured out what the problem is with older gs versions? gs
has been around along time, there has got to be a way to generate EPS
that would work with older versions.

Fedora Core4 is not generally a "conservative" distribution, and OS-X
(10.3 anyway) doesn't provide 8.16 either. It would be great to not have
this requirement.

-Chris

--
Christopher Barker, Ph.D.
Oceanographer

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

Chris.Barker@...259...

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hey Darren,

Maybe this will help, maybe it won't.
Ubuntu provides 3 gs options in its package manager:
gs-afpl v. 8.14
gs-gpl v. 8.01
gs-esp v. 7.07

I have also installed gpl 8.50 from source.

My problems only occur when including the eps files in a latex file.
With gs-gpl 8.01 or gs-esp 7.07, the output looks like the bad_bbox
picture (it only shows the top of the figure where the plot is
covering up the text).

You can force extra space around the figure to prevent this overlap by doing
something like this, I just dont remember which of the 4 values is relavant
for this problem:
\includegraphics[trim=-10 -10 -10 -10]{rk-fig.eps}

With gs-afpl 8.14 or gpl 8.50 (from source), I
get the output in better_bbox.jpg, but there is still a thin white
line from the figure that goes through the text.

This line can be removed by doing something like:
\includegraphics[clip=true]{rk-fig.eps}

So maybe the white
frame or a white background is messing things up.

But I don't think the problem really is the bounding box, I think it
is this white frame or background being drawn bigger than the bounding
box, because if I use the LaTeX command \includegraphics* (which as I
understand it clips the figure to the bounding box - as opposed to
\includegraphics without the * which does not), the output from all 4
gs versions is fine.

I wasn't aware of \includegraphics*...

epstopdf makes nice pdfs with a good bounding
box/paper size regardless of which version generates the eps files
(but I have to use the gatech-theis class for my thesis which does not
work with pdflatex, so I need nice eps files).

The only problem I had meeting the v >8.16 problem was getting gs to
find my system fonts. This was solved by setting GS_LIB and exporting
it in my .bashrc file. I found the font paths by running gs -h on one
of the ubuntu provided versions (i.e /usr/bin/gs-gpl -h).

Hope this helps.

Let me know if you want me to test anything else. I really value this
option and am glad to help with its development/testing/debugging.

Thank you Ryan, this is a valuable post.

···

On Monday 23 January 2006 15:05, Ryan Krauss wrote:

Darren Dale wrote:
> The ghostscript requirement is something of a headache. The conservative
> distributions, such as RHEL, continue to provide ghostscript version
> 7.07

[...]

Fedora Core4 is not generally a "conservative" distribution, and OS-X
(10.3 anyway) doesn't provide 8.16 either. It would be great to not have
this requirement.

I just spent some time improving the dependency checks, the changes are in
cvs. I relaxed the ghostscript requirement to gs-7.07, but issue a warning if
a version earlier than 8.16 is found. Based on Ryans post, and the recent
changes to the mpl code, I will update the usetex wiki page sometime within
the next couple days.

I have one question. If, for example, a user sets usetex =True in
matplotlibrc, but TeX is not installed, is it better to issue a warning and
force usetex=False, or is it better to raise an error? Right now I do the
former.

Darren

···

On Monday 23 January 2006 12:34, you wrote:

Issue a warning. At least the user gets a plot, even if it is not a good one.

– Paul

···

On 1/23/06, Darren Dale <dd55@…958…> wrote:

I have one question. If, for example, a user sets usetex =True in
matplotlibrc, but TeX is not installed, is it better to issue a warning and
force usetex=False, or is it better to raise an error? Right now I do the

former.


Paul Barrett,
PhD
Johns Hopkins University
Assoc. Research Scientist Dept of Physics and Astronomy
Phone: 410-516-5190 Baltimore, MD 21218