Bug #85

ps2raster -Au bounding box not tight for -Te

Added by Ken over 9 years ago. Updated almost 6 years ago.

Status:ClosedStart date:2012-05-23
Priority:NormalDue date:
Assignee:Remko% Done:


Target version:Candidate for next bugfix release
Affected version:all Platform:


GMT 5.0.1b_r10147 Linux (Ubuntu 12.04) 32 bit.
GMT 4.5.9_r9845 Linux (Ubuntu 12.04) 32 bit.

I believe there's a bug in ps2raster for both GMT4 and GMT5 (although it is more pronounced in GMT5) when trying to tighten the bounding box on an output EPS file with the -Te option.

The bug causes a slight whitespace margin to be left in EPS files, but not in other file formats such as PDF. It appears to occur on only two edges (upper and right for -P, lower and right for landscape) regardless of the projection used. While the whitespace margin occurs in both GMT 4 and 5, it's normally not very noticeable. However when the map in the source PostScript file is particularly small (a few centimetres), the margin becomes more pronounced, especially in GMT5. This becomes a problem if you're using psimage to accurately place the EPS files into a new map (as I am trying to do).

Attached is an example script and the resultant output of an EPS file with the bug, and a comparative PDF without the bug. You may need to zoom in/fullscreen to appreciate the whitespace margin.

PS: This bug was previously submitted to the GMT-Help list but has been updated for entry into Trac

boundingbox.sh Magnifier (401 Bytes) Ken, 2012-05-23 19:02

tight.eps (33.5 KB) Ken, 2012-05-23 19:02

tight.pdf (11.5 KB) Ken, 2012-05-23 19:02

hexahedron.sh Magnifier (8.13 KB) Ken, 2012-06-18 05:32


#1 Updated by Joaquim over 9 years ago


We will try to look at this at a later time (we lot's of other things to work on) but even without looking into the code again, I'm afraid that there is nothing that we can do. The tight BB is computed by ghostscript itself and ps2raster only applies the answer it gets. So, I would be tempted to say that this is a ghostscript issue/bug.

#2 Updated by Florian over 9 years ago

  • Status changed from New to Feedback

What about integrating the BB calculation as a function into PSL?

#3 Updated by Ken over 9 years ago

I've looked into this a bit more. In ghostscript, it appears that the BoundingBox value rounds up to integers compared to the HiResBoundingBox value. My understanding is that this is to use 1/72 inch big points. If I run the following command on the EPS I attached earlier

gs -dNOPAUSE -dBATCH -q -sDEVICE=bbox boundingbox.eps

it returns

%BoundingBox: 0 0 58 58
%HiResBoundingBox: 0.000070 0.000070 57.419928 57.419928

This explains why it isn't a problem when creating PNG images, as detailed in the original post.

So, here are two possible features to fix this problem. They are probably not mutually exclusive.

1. When creating EPS files in ps2raster, an option that scales up the entire export to the nearest bp integer (rounding up) prior to sending it to ghostscript. This changes the size of the original image.

2. When using an EPS with psimage – there may be other tools I am unfamiliar with that also place EPS files – read the HiResBoundingBox value and use that for all placement calculations.

I feel the second option is the most crucial, because at the moment I can't use psimage to correctly position my maps. Precision is crucial when trying to do more complicated processes such as polyhedral maps.


#4 Updated by Paul over 9 years ago

Ken, I am not so sure. I note that if I use -X0 -Y0 then half the thickness of the basemap frame is clipped since it is outside the page. Without -X0 -Y0 as you have, then because of the default 1inch offset I see the entire frame. Now, running ps2raster on the -X0 -Y0 results in a clipped frame - what is outside the paper is not recovered. However, with yours the bounding box is adjusted to take into account the thickness of the basemap and the map is now wider than what was indicated with the -J option. Are you really placing these maps such that you want the 1/2 pen width to be included? I.e., if your placement of many maps is based on width of maps as given by projections then the width of the image you are placing will be wider due to the width of the basemap lines.

#5 Updated by Ken over 9 years ago

No, I am not necessarily wanting the 1/2 pen width to be included, but that's not the root cause of the bug I detailed in No.3 above.

Evidently it is hard to convey my meaning without a proper example. Attached is a script written specifically to demonstrate the problem. If you run the script, you will get an output that shows the problem of the extra whitespace introduced when psimage uses the BoundingBox variable instead of the HiResBoundingBox variable of the EPS header.

As a comparison, uncomment line 196. This clips out the whitespace in the EPS, and produces a closer approximation to what psimage should be producing.

Once this bug is fixed, I'll clean up the script for inclusion in the test suite for psimage. I think it's a nice example of its function.


#6 Updated by Joaquim about 9 years ago

Ken, this issue is not an ps2raster bug. According to Paul's Red book

"the BB (integers) encloses all marks painted on all pages. That is, it must be a "high water mark" in all directions for marks made on any page."

so we are doing it right when computing BB with ceil. However, I added the optional 'r' modifier to -A (that is, -Ar[...]) that will do rounding instead of ceil. For the time being this is an undocumented change, see if it helps you.

#7 Updated by Florian about 9 years ago

I don't understand why rounding could be a solution. The additional canvas space you get with ceil will be cropped by floor. So this cannot be exact either because you loose information, or? The only resolution I see is to scale the image so that the HiResBB values are no fractions anymore, i.e., HiResBB = BB.

#8 Updated by Joaquim about 9 years ago

No rounding is not the solution. It's just a dirty patch that will work a bit better by reducing the problem to an half-pixel mismatch. If you look at line 196 of the hexahedron script the <offset> arguments to -A do seam to work because they actually crop a bit of the image (like the rounding in some situations). It may prove that it's not worthy after all and that's why I didn't document it.

#9 Updated by Ken about 9 years ago

I think the bug title is being misleading as I have mentioned in my two follow-ups. The real solution to my problem would be for psimage to have an option to perform all
placement calculations using the HiResBB.

Joaquim, I couldn't get ps2raster -Aru to work for me.

#10 Updated by Joaquim about 9 years ago

Ken McLean wrote:

I think the bug title is being misleading as I have mentioned in my two follow-ups. The real solution to my problem would be for psimage to have an option to perform all
placement calculations using the HiResBB.

I have not dug into psimage but I would bet that is not possible. psimage loads the a ps file whose size, BY POSTCRIPT RULES, is determined by the BB, not the HiResBB so GMT has no interference here.

Joaquim, I couldn't get ps2raster -Aru to work for me.

What you mean 'not work'?
This is what I get for your hexahedron.ps file with -Aur (and note that the 'u' is useless here as it is meant to remove the GMT time stamp).

%%BoundingBox: 0 0 423 181
%%HiResBoundingBox: 0 0 422.514 181.098

#11 Updated by Ken about 9 years ago

Well, I don't know what to add to this as far as feedback goes. Without using the HiResBB for ps placement psimage can't really be relied on for fine-grained placement, as seen in my test script above. In my opinion that's a major limitation that warrants a workaround. I'm happy to help test, but I feel I've said all I can.

#12 Updated by Paul almost 6 years ago

Well, it is 3 years later and I want a resolution here. Sorry Ken, you may possibly no longer be listening, but anyway. Looking at this again and having forgotten most of this, I see psimage loads in the EPS file and scans it to find the BoundingBox record and extracts those integer dimensions and uses them for placement. Why cant we override that info if we also find the HiResBB? As Ken asked for? I don't see any issues here with such an implementation but we were pretty adamant above it could not be done. What am I missing? OK to implement this idea?

#13 Updated by Remko almost 6 years ago

  • Status changed from Feedback to Resolved
In fact, the story is a bit different than suggested above ... but things may have changed over the years.
  1. ps2raster (GMT4 and GMT5.1) and psconvert (GMT5.2) are both using the information in HiResBoundingBox to determine the size to the PDF output.
  2. They all take the HiResBounding box that is either already in the file (but defaults to using BoundingBox if it is not there), or is created by the first cropping step done by ghostscript, it cropping is desired.
  3. However, in the ghostscript command used to generate the PDF it uses the current resolution set by -E (default is 720).

The latter means that the rounding is done to the resolution level set by -E, irrespective of the HiResBoundingBox.

Let us assume we use "ps2raster -Tef -S tight.eps" then the ghostscript command varies depending on how we use -E.
  • without -E or -E720: -g582x582 -r720
  • with -E72: -g59x59 -r72
  • with -E3000: -g2423x2423 -r3000

So the user has some flexibility. However, my experience is that it is best to add -A1p to avoid still some scraping off of fonts or curves on the edges.

I have modified the manuals to make this clear.

#14 Updated by Paul almost 6 years ago

Great, but I think(?) the key issue with psimage remains: psimage will position a EPS usine regular BoundingBox instead of HiResBoundingBox. This has nothing to do with psconvert which only enters later. If psconvert is used to make an EPS then there is no rounding or resolutions but psimage has imposed the integer point positioning. That is what I want to change.

#15 Updated by Remko almost 6 years ago

  • Status changed from Resolved to In Progress
  • Assignee set to Remko

OK, I'll put this "in progress" then, on me to check out psimage's usage of BoundingBox.

#16 Updated by Paul almost 6 years ago

OK, I did not want to start messing with it in case you started. However, I think this is a good solution: We define struct imageinfo in postscriptlight.h, basically the old Sun ras header. However, simply add 4 more double variables to it and use those to store the highres bb stuff and use the integers as is for the regular BB. Then no change is needed to the PSL functions and it is just in psimage where you would pass the double arguments to the ploteps function - it may need to accept doubles but everything else stays the same (apart from fishing for the highres BB as well).

#17 Updated by Remko almost 6 years ago

I see. Yes, that was part of the issue as well, that psimage needs to be adjusted.
I'll follow your suggested approach. But if I do so, then it will mean changing PSL_plotepsimage.
As that means changing pslib, I'll only do this in 5.2 even if this can be considered a "bug".
It is so minor, that it doesn't warrant breaking things for those using pslib from 5.1 directly.

#18 Updated by Remko almost 6 years ago

  • Status changed from In Progress to Resolved

r14998 should have fixed this now also for psimage, in GMT 5.2.
This will not be patched in GMT5.1 or GMT4 because it requires changes in the pslib function PSL_plotepsimage.
This new code has not been tested yet

#19 Updated by Paul almost 6 years ago

  • Target version set to Candidate for next bugfix release
  • % Done changed from 0 to 100

Works fine with GMT's test suite. I had to update the PS for one script (doc/script/GMT_images.sh) since positioning changed due to highres. All else worked. I ran Ken's hexagone.sh script and it now no longer has the gaps Ken complained about. So I would say this problem has been resolved.

#20 Updated by Remko almost 6 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF