Bug #521

ps2raster fails when psimage places an EPS image

Added by Paul over 7 years ago. Updated over 7 years ago.

Status:ClosedStart date:2014-02-22
Priority:NormalDue date:
Assignee:Remko% Done:


Target version:Candidate for next bugfix release
Affected version:5.x-svn Platform:


This is a simple example of placing an EPS file inside a psbasemap box. When psimage places this EPS it seems to wipe everything with white and nothing shows. Converting the EPS image to PNG and placing it with psimage works fine. I note Adobe Distiller works fine , so perhaps this is a ghostscript bug out of our control?

bug.sh Magnifier - Script that reproduces the bug (356 Bytes) Paul, 2014-02-22 09:07

logo.eps - The offending logo (463 KB) Paul, 2014-02-22 09:07


#1 Updated by Paul over 7 years ago

Just noted that gs bug.ps works fine so GMT creates a valid PS with the included EPS and the problem must be how ps2raster handles it.

#2 Updated by Joaquim over 7 years ago

Even more. If we do it in 3 steps, than it works

1. Run with -Te only to create the bug.eps file
2. Run with -S the print out the ghost command
3. Run the ghostscript command directly on command line with a only edit which is to replace the eps file name to bug.eps

#3 Updated by Remko over 7 years ago

Joaquim's solution suggests that we may have an error with "encapsulating" the logo.eps into the larger PS file.
Have you looked at the difference between bug.eps and bug.ps?

#4 Updated by Joaquim over 7 years ago

The difference is that the bug.ps has these 3 extra lines (which makes it having two sets BoundingBox declarations)

PSLevel 1 gt { << /PageSize [595 842] /ImagingBBox null >> setpagedevice } if

%%BoundingBox: 0 0 194 66
%%HiResBoundingBox: 0 0 193.0937 65.2778

Note: this is a Train Bug Spoting exercise via iPohone hotspot. (not very practical)

#5 Updated by Remko over 7 years ago

Ah. I remember that one.
In the past I already wanted to kick that line out for similar reasons. Also having to do with issues with ghostscript.
Then it couldn't be removed because it was the preferred way to let ghostscript know the page size (instead of using options in the call to ghostscript.
Maybe we should reconsider abolishing that line, or to remove it before creating PDF or PNG.
It probably means that the test will work when using pscoast -A, because that will create EPS as intermediate step first (I believe).

#6 Updated by Joaquim over 7 years ago

I think I remember that as well but from my recall we had to recover that line to fix another bug.

#7 Updated by Remko over 7 years ago

I think it is in this set of lines:

                if (Ctrl->T.eps != 1)    /* Write out /PageSize command */
                    fprintf (fpo, "<< /PageSize [%g %g] >> setpagedevice\n", w, h);

The /PageSize is written in this case always to the intermediate file, except when using -Te
This switch was meant to put the /PageSize in the output file when using -TE
I think the check should say == -1 instead. The BoundingBox is already given to ghostscript using its -g and -r options.

Or was there another reason for introducing /PageSize in the intermediate files?

#8 Updated by Joaquim over 7 years ago

I knew had been here before but don't remember the circumstances anymore. I dug into the SVN history and found that we are turning round on this issue. On r9027 you did what you are proposing now (check == -1), but latter revert it on r9029 to it's current form.
Now, why are we cyclic coming back to this?

#9 Updated by Remko over 7 years ago

Aarrgghh. While it is so nice that one can unearth all those code changes, it is depressing to see we were here once before
Now I wish I had said a bit more in the comment, specifying why I reverted it.

#10 Updated by Joaquim over 7 years ago

It must have been triggered by some user report on a problem around that date (8 September 2011)
(nothing obvious pops up in a quick Goog search)

#11 Updated by Remko over 7 years ago

I made those changes in quick succession: http://gmt.soest.hawaii.edu/projects/gmt/activity?from=2011-09-09
r9027: Added -TE to put /PageSize setpagedevice in (we did not have it there at all)
r9028: Put /PageSize in the right place within %%Setup %%EndSetup
r9029: Write /PageSize always, except in case of -Te

So I wonder why:
  • I introduced -TE in the first place
  • I decided that it should always be written to the intermediate files

The first question is probably answered by: http://comments.gmane.org/gmane.comp.gis.gmt.user/16281
The answer to the second one was probably just on a whim, thinking that really only -Te required that the setpagedevice not be there.

Hence I suggest to remove setpagedevice once again, except when using -TE. I'll make sure the patch will point here for the discussion.

#12 Updated by Remko over 7 years ago

  • Status changed from New to Resolved

Fixed in r12956 (GMT5.1.x and GMT 5.2.x)
Does not affect GMT4.

#13 Updated by Joaquim over 7 years ago

Yes, now that I read that's what was the issue that I was trying to remember. Good digging. Noe I'll remember better if this resurfaces in the next couple of years.

#14 Updated by Paul over 7 years ago

  • Status changed from Resolved to Closed

Closing this one.

Also available in: Atom PDF