# Source for inaccuracies in plot dimensions?

My task is to plot maps with given outside dimensions and a given scale. I have trouble nailing the dimensions.

Target size is the DIN A1 paper format which is 841mm x 594mm in landscape orientation.
Required map scale is 1:500,000.

I’m using `-Rxmin/xmax/ymin/ymax+uk -Jl/1:500000` to force my plot dimensions. Calculating `xmin/xmax/ymin/ymax` is done via

``````width/2:  0.841m * 500,000 = 420500m / 2,000 = 210.25km
height/2: 0.594m * 500,000 = 297000m / 2,000 = 148.5km
``````

Using those numbers gives me a plot that is 1.3mm too wide and 1.4mm too tall. I suspect that this is due to the map border pen width. The map border is drawn centered on the plot border so the plot gets one pen width wider and taller.

Next step was trying `MAP_FRAME_PEN=0` and `MAP_FRAME_TYPE=inside` which resulted in the following plot dimensions:

width (mm) ∆ width (mm) height (mm) ∆ height (mm)
841.0 594.0 DIN A1 format (target size)
842.3 +1.3 595.4 +1.4 GMT default settings
841.4 +0.4 594.1 +0.1 `MAP_FRAME_PEN=0`
841.1 +0.1 594.1 +0.1 `MAP_FRAME_TYPE=inside`

This experimentation has led to believe me that these inaccuracies are indeed due to map border pen width. I also assume that the +0.1 mm increase in dimensions is due to rounding errors. The thing I don’t really understand is the +0.4 mm in width with `MAP_FRAME_PEN=0`.

While 0.1 mm plot size deviation is well within my dimensional requirements I wonder if there is an easier way to achieve a dimensionally fixed plot with a given scale and a border? The border not being drawn twice the desired width to counter `MAP_FRAME_TYPE=inside` cutting off half the line?

Some code to play with:

``````gmt begin map-dimensions
# gmt set MAP_FRAME_TYPE=inside
# gmt set MAP_FRAME_PEN=0
gmt coast \
-R-210.25/210.25/-148.5/148.5+uk \
-Jl9.25/54/53.5/54.5/1:500000 \
-Bg0.5 -Ggrey -Slightblue -N1/1p,- -I1/2p,lightblue
gmt end show``````
1 Like

Isn’t there something with `figure` and the padding parameter?

Hi @PlanetGus, I’m not sure what you mean? Maybe `PS_MEDIA A1` to force plot size? In my understanding padding just gives me some margin around my plot?

I was (maybe) thinking about a workaround using `gmt figure` and padding “-“0.1mm to compensate your delta… but it’s probably completely irrelevant ^^

How do you measure those dimensions?

``````gmt coast -R-210.25/210.25/-148.5/148.5+uk -Jl9.25/54/53.5/54.5/1:500000 -Bg0.5 -Ggrey -Slightblue -N1/1p,- -I1/2p,lightblue --MAP_FRAME_TYPE=inside --MAP_FRAME_PEN=0 -eps lixo.ps
``````

and take the the `%%HiResBoundingBox: 0 0 2383.9379 1683.7919`

julia> [2383.9379 1683.7919] .* (2.54/72*10)
1×2 Matrix{Float64}:
841.0 594.004

Hello @Joaquim, in my original post I took the easy route and got the document dimensions from the document property pane of the macOS Preview application.

In the meantime I also checked with Adobe Acrobat Reader. Additionally I opened the PDF with a text editor to extract the dimensions handed over to GhostScript for the PDF conversion and did the conversion from Points to Millimeters myself using Points * ( 2.54 / 72 ) = Millimeters. The results are identical to the Adobe Acrobat Reader values.

GMT default settings

``````gmt coast -R-210.25/210.25/-148.5/148.5+uk -Jl9.25/54/53.5/54.5/1:500000 -Bg0.5 -Ggrey -Slightblue -N1/1p,- -I1/2p,lightblue -pdf plot_width_default
``````
width (mm) ∆ width (mm) height (mm) ∆ height (mm)
841.0 594.0 DIN A1 format (target size)
842.3 +1.3 595.4 +1.4 macOS Preview
842.3 +1.3 595.3 +1.3 GhostScript

In general they are almost the same, Preview apparently doing something different when rounding numbers. I assume that this oversizing the plot comes from the border being plotted centered.

`MAP_FRAME_PEN=0`

``````gmt coast -R-210.25/210.25/-148.5/148.5+uk -Jl9.25/54/53.5/54.5/1:500000 -Bg0.5 -Ggrey -Slightblue -N1/1p,- -I1/2p,lightblue --MAP_FRAME_PEN=0 -pdf plot_width_pen_0
``````
width (mm) ∆ width (mm) height (mm) ∆ height (mm)
841.0 594.0 DIN A1 format (target size)
841.4 +0.4 594.1 +0.1 macOS Preview
841.3 +0.3 594.0 ±0 GhostScript

Apparently Preview still rounds differently but what I can’t explain is the increased width. I expected it to be spot on as it is in height.

`MAP_FRAME_TYPE=inside`

``````gmt coast -R-210.25/210.25/-148.5/148.5+uk -Jl9.25/54/53.5/54.5/1:500000 -Bg0.5 -Ggrey -Slightblue -N1/1p,- -I1/2p,lightblue --MAP_FRAME_TYPE=inside -pdf plot_width_type_inside
``````
width (mm) ∆ width (mm) height (mm) ∆ height (mm)
841.0 594.0 DIN A1 format (target size)
841.1 +0.1 594.1 +0.1 macOS Preview
841.0 ±0 594.0 ±0 GhostScript

Except for Preview doing things differently again, `MAP_FRAME_TYPE=inside` seems to be the way to go.

Conclusion

• GMT can generate exact outside plot dimensions.
• If outside plot dimensions are crucial, use `MAP_FRAME_TYPE=inside` even if you specified `MAP_FRAME_PEN=0`
• macOS Preview likes to calculate things differently.

What I don’t understand is the 0.3mm wider plot when using `MAP_FRAME_PEN=0` compared to `MAP_FRAME_TYPE=inside`. In my world it should be the same regarding plot width? 0.3mm aren’t really affecting my result. I’m just curious if I did something wrong.

1 Like

I don’t understand either with `inside` gives the exact sizes since there is a border line that is plotted and we probably should expect to see the pen width added to the map size (half at each side). But remember that there is no such thing as pen=0. The minimum, if I recall correctly, is 0.25 points. Even when we tell it `--MAP_FRAME_PEN=0`

pane 0 is “device dependent” so if we have a default psconvert setting of 600 dpi then that is the pixel with of a 0 pen. I think so. In PDF of course it lives as zero until rendered on whatever you are viewing or printing. But in raster it must be converted. For diagonal lines we get into subpixeling etc.

Also note tons of modifiers to psconvert -A for rounding etc.

The thing I don’t understand is that I get an increase in x- but not in y-direction. Looking at the Cookbook it says:

Minimum-thickness pens can be achieved by giving zero width. The result is device-dependent but typically means that as you zoom in on the feature in a display, the line thickness stays at the minimum.

So in case the assumption `MAP_FRAME_PEN=0` != 0 width is correct, wouldn’t that mean that I should get a bigger plot not only in x- but also in y-direction?

Ok, taking a step back. I’m chasing fractions of a millimeter here. There is a way around that and therefore I think we can put that threat to rest. Thank you for your thoughts and ideas!