Fri 13 Jan 2012 04:20:59 PM UTC, comment #20:
No objection to including it in 3.6.0 (I had pushed to stable for that reason).
I don't expect this change will result in any regressions, so I don't see a need for an rc2.
|
Fri 13 Jan 2012 03:50:59 PM UTC, comment #19:
Ben, thanks for digging in to this problem.
I think the report can be closed now.
Unless there is some objection, I intend to include this change in the 3.6.0 release, but I don't plan to make another release candidate snapshot just for it. Is there any objection to that?
|
Fri 13 Jan 2012 04:09:43 AM UTC, comment #18:
Just to second Rik's comment: nice work!
Michael
|
Thu 12 Jan 2012 10:40:25 PM UTC, comment #17:
Thanks Rik!
If you look at the list of comments, I took a few wrong turns ;-)
I've pushed a changeset.
http://hg.savannah.gnu.org/hgweb/octave/rev/81ee6b12adbc
I'm not planning to replace epstool as using ghostscript or graphicsmagick to tighten the bbox modifies the eps-code and breaks compatibility with psfrag.
If there are no objections from those following along, this can be closed.
|
Thu 12 Jan 2012 09:29:25 PM UTC, comment #16:
Wow. That's some impressive root-cause analysis Ben.
|
Thu 12 Jan 2012 07:46:59 PM UTC, comment #15:
I've solved the problem. My notes are below.
I began by creating the simplest plot that demonstrated the problem.
I used ghostscript to determine the bbox size.
peaks2.eps is ok, but peaks3.eps is not (bbox is too large).
Next I experimented with the eps-files to see if I could isolate the problem. With the diff below applield to peaks3.eps, the bbox is determined correctly by ghostscript.
The ghostscript result, for foobar.eps, is below. It is approximately the same as for peaks2.eps.
|
Wed 11 Jan 2012 11:26:20 PM UTC, comment #14:
I have not yet determined why the gl2ps eps-files are violating the operand stack count. However, I did confirm that adding by saving the initial state and then restoring it after the eps-file code is run, the problem goes away.
At the top of the eps-file I placed,
And at the bottom.
Then I ran,
and obtained
This isn't a proper fix, but it does give an indication that the gl2ps eps-file is either leaving an operand on the stack or is eating one.
|
Wed 11 Jan 2012 02:36:59 AM UTC, comment #13:
I took a look at "gm convert". It did filter out the problem with the gl2ps eps-file.
Unfortunately it severely degrades the quality of the image.
Looks like we'll need to use ghostscript, or fix the bug in gl2ps.
When I have the time, I'll try to determine what it is about the gl2ps' eps-file that isn't compliant with the eps-standard.
|
Mon 09 Jan 2012 03:38:39 PM UTC, comment #12:
Ben,
Two points:
1. Have you looked at "convert" which is
part of ImageMagick? I am not sure it would
be useful, but it claims to do a lot of conversions,
and ImageMagick seems to be a widely available
package.
2. epstool is not mentioned anywhere in the current Manual,
specifically not in Appendix G where all the required
dependencies are listed.
|
Mon 09 Jan 2012 01:29:28 PM UTC, comment #11:
The epstool utility is also being used to add the tiff preview.
I'll leave the epstool as it is, but use gs to handle the -tight option.
|
Mon 09 Jan 2012 02:29:43 AM UTC, comment #10:
Michael,
I work on a changeset that replaces epstool with gs.
Currently Octave produces a tight bbox with
I'll replace this with something to the effect of
If I recall correctly epstool had some problem with pipes. If a tight bbox is the only reason we needed epstool, then I'm happy to avoid it.
|
Mon 09 Jan 2012 02:15:19 AM UTC, comment #9:
I forgot to mention the results of "epstool --test-eps foobar.eps"
By default ML produces the tight version. Maybe Mathworks decided it best to filter the generated eps code through gs to be sure result is compliant?
|
Mon 09 Jan 2012 02:13:16 AM UTC, comment #8:
Since this bug depends on epstool, can I ask: is
epstool appropriately necessary for Octave plotting?
It appears that it is not in standard distributions.
In fact, I think it is the only non-standrard package
used by Octave in Fedora systems. Could what it does be
done by ghostscript?
If this question has already been asked, just say what the
answer was.
Thanks,
Nichael
|
Mon 09 Jan 2012 01:54:50 AM UTC, comment #7:
I found a work around. First I produced a normal eps-file
Then I passed the result thru ghostscript.
The resulting foobar.eps has a tight bbox. I don't see where this is documented but did find it mentioned in the bug report below.
http://bugs.ghostscript.com/show_bug.cgi?id=689629
I'll put this on my list of to-do's.
|
Mon 09 Jan 2012 01:26:45 AM UTC, comment #6:
Doug,
I'm running gs 9.04 and epstool 3.08 on MacOS X.
My Ubuntu 10.04 has gs 8.71 and epstool 3.08. I see same result as you.
This seems to suggest the bug is with ghostscript 9.04.
I've been trying to figure out how to build and install an older version of ghostscript using macports, but haven't figured it out yet.
|
Mon 09 Jan 2012 12:59:43 AM UTC, comment #5:
My epstool version is
I tried the commands below.
They produced an eps-file with the header below.
Using gnuplot, I get the expected result.
Rik, the "print -tight" option isn't equivalent to "axis tight". It shouldn't change the axis ticks. Instead it tightens the bounding box around the figues children (which may include one or more axes). Even so, your suggestion that Octave handle the "-tight" can work for the opengl backends. We'd have to modify the position properties of each axis to for the looseinset on edges of the figure's axes to zero. Kostas was good at such things, but its a weakness of mine. I'll give this some more thought. Perhaps there's another way.
|
Mon 09 Jan 2012 12:27:50 AM UTC, comment #4:
Interestingly, running Kubuntu 10.04 with the same versions of Ghostscript and epstool I get a different result. I did a diff of Doug's test.eps and the one generated on my machine and they are different. In particular, the bounding box specification is different. Maybe there are differences due to installed fonts? gl2ps is the same version between both machines as well.
|
Sun 08 Jan 2012 11:54:48 PM UTC, comment #3:
On Ubuntu 10.04 I get:
doug@doug-desktop:~$ epstool --test-eps test.eps
"gs" -dNOEPS -dNOPAUSE -dBATCH -dNODISPLAY "/tmp/gsview9Yc9ME"
GPL Ghostscript 8.71 (2010-02-10)
Copyright (C) 2010 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Loading NimbusSanL-Regu font from /var/lib/defoma/gs.d/dirs/fonts/n019003l.pfb... 2325924 992949 2093988 789097 2 done.
EPSWARN FAIL: EPS file altered operand stack count
EPSWARN FAIL
"gs" -dNOPAUSE -dBATCH -sDEVICE=bbox -c "<</PageSize [9400 9400] /PageOffset [3000 3000]>> setpagedevice" -f "/tmp/gsviewYqGuGr"
GPL Ghostscript 8.71 (2010-02-10)
Copyright (C) 2010 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Loading NimbusSanL-Regu font from /var/lib/defoma/gs.d/dirs/fonts/n019003l.pfb... 2325996 992779 4027292 2727351 2 done.
%%BoundingBox: 3047 3062 3523 3421
%%HiResBoundingBox: 3047.831907 3062.951907 3522.779892 3420.727067
File has %%BoundingBox: 47 62 523 421
Correct is %%BoundingBox: 47 62 523 421
File used PostScript operators that are prohibited in an EPS file.
File claims to be EPS.
FAIL: File does not comply with EPS specification.
Failed
doug@doug-desktop:~$ epstool --help
epstool 3.08 2005-06-06
Copyright 1995-2005 Ghostgum Software Pty Ltd
Usage: epstool command [options] inputfile outputfile
You can see the file here:
http://ubuntuone.com/37jmrGkIYLnYbxYjyBvyYQ
As you can see I am using epstool 3.08
and the resulting picture look normal.
I hope this helps
Doug
|
Sun 08 Jan 2012 10:10:19 PM UTC, comment #2:
This problem exists for me on Kubuntu 10.04 so I don't think it is Mac specific. I don't have epstool installed and when I run the set of commands I get:
If I run without the '-tight' option the command works and generates a correctly sized eps image.
If I install epstool, an image is created but it is super small as in the original bug report. If I run a diff on the two different eps files I get
The problem does not seem to be Octave, but rather epstool which is updating the bounding box to some huge value. If I manually edit the eps file and restore the original bounding box then the figure is normal again.
It seems that either epstool is broken or we are not calling it correctly. As a work around, could we implement an unwind_protect block to have the 'tight' done by Octave rather than epstool? I'm thinking of something like this.
It also seems that the generated eps is not correct. If I run epstool with the --test-eps option I get the following.
|
Sat 07 Jan 2012 05:54:23 PM UTC, comment #1:
The problem does not exist on Ubuntu 10.04
http://octave.1599824.n4.nabble.com/Octave-3-5-92-snapshot-available-for-ftp-tt4270829.html#a4271872
|
Sat 07 Jan 2012 02:16:17 AM UTC, original submission:
The resulting eps is large, but but surf plot is tiny. I've attached the result.
|