Bug #1181

Incompatible BoundingBox and PS_MEDIA causes crash

Added by Andreas 11 months ago. Updated 11 months ago.

Status:ClosedStart date:2018-01-11
Priority:NormalDue date:
Assignee:-% Done:


Target version:-
Affected version:6.x-svn Platform:


User error or bug - whatever you call it, GMT 6 crashes if the BoundingBox and PS_MEDIA are incompatible. During the PS → PDF,PNG[..] conversion. I think.

Using 6.0.0_r19587.

GMT 6 modern mode

andreas:~$ gmt begin && gmt pscoast -R6/8/61/63 -Js0/90/1:10000 -W -Dc -Bafg --PS_MEDIA=A4 && gmt end
psconvert [ERROR]: Unable to decode BoundingBox file ./psconvert_8548c.bb
psconvert [ERROR]: Failed to remove ./psconvert_8548c.bb! [remove error: No such file or directory]
ERROR: Caught signal number 11 (Segmentation fault) at
Stack backtrace:

~equivalent in GMT 5 (classic)

$ gmt pscoast -R6/8/61/63 -Js0/90/1:10000 -W -Dc -Bafg --PS_MEDIA=A4 > a.ps
$ psconvert -Tf -A -Z a.ps
gmt: Unable to create GMT User directory : \/.gmt
gmt: Auto-downloading of earth_relief_##m|s.grd files has been disabled.
psconvert: Unable to decode BoundingBox file ./psconvert_10144c.bb
psconvert: Failed to remove ./psconvert_10144c.bb! [remove error: No such file or directory]

Associated revisions

Revision 19588
Added by Joaquim 11 months ago

Don't try to remove the BB file twice. Fixes #1181


#1 Updated by Joaquim 11 months ago

  • Status changed from New to In Progress

Applied in changeset r19588.

#2 Updated by Joaquim 11 months ago

  • Status changed from In Progress to Resolved

Fixed in r19588, though we should capture this type of user errors. Specially now that we also compute an internal GMTBoundingBox.

#3 Updated by Andreas 11 months ago

This might not be the correct place to bring this up, but; will the PS_MEDIA parameter be obsolete and removed at some point? In this day and age, who cares about the "physical format of the current plot paper"? In the past I can understand why this was important, but now?

#4 Updated by Joaquim 11 months ago

We have discussed this but did not implemented anything. Agree that there is no need to clip a figure if its scale implies dimensions larger than paper size.

#5 Updated by Paul 11 months ago

Setting a paper size is mostly something required by ghostscript so that it will render the full plot. If you plot outside the PS_MEDIA dimensions then psconvert, calling gs, will truncate your plot to the paper size. There are some ways to deal with this:

  1. Set PS_MEDIA internally once the plot dimensions from -R -J is known, plus margins.
  2. Set PS_MEDIA to something very large, then crop at the end.

Option 1 seems good until you realize that later plotting may very well enlarge the area. So then it becomes much more complicated to keep track. We used to do this (badly) back in the GMT4 days but gave up since we cannot do it accurately without including font metrics. Option 2 means we may waste large amounts of memory to rasterize the PS onto an unnecessarily large matrix.

GMT originated in making plots destined for paper and of high quality, and setting dimensions is still relevant given -J -R. So being aware of a paper size does not seem that unreasonable to me, still.

#6 Updated by Paul 11 months ago

Meanwhile... we have looked into this further and can announce that GMT 6 will not require any PS_MEDIA setting unless you want to. The default will be "auto" and we crop to fit you plot, no matter how large. Thanks for starting the thought process. We will retain PS_MEDIA because it is required for some endeavors such as making frames for movies (they all need to be the same size).

#7 Updated by Joaquim 11 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF