Not a PyGMT problem per se, but after an update to the newest versions of pygmt and gmt (and probably ghostscript), my plots are now being cutoff. I have tried setting PS_MEDIA with no change, I’ve also tried changing the PS_PAGE_ORIENTATION with no change. When I pull the resulting file into illustrator, there is nothing being plotted outside of what is shown in preview. Should I fallback to a previous version or is there a command or flag that I’m missing?
If I run your code with a PyGMT dev version + GMT 6.5.0 and ghostscript 10.03.0. The map isn’t cut off. However, in both topics, higher gs versions are used. So, maybe there is a problem with higher gs versions. I have to make an environment with gs higher than 10.03.0 and test on my own.
Maybe share the PS file. PyGMT uses only modern mode and in it the paper size is wall sized (11 meters) so it’s difficult to imagine how this happens and even more that it’s ghostscript issue (but something is).
I can report the exact same issues as @wthelen with a slightly different configuration (see below). Have played a bit with width/height ratios and it seems that in my case the maps with a N-S:E-W ratio of >1.5 seem to be ok, although there the inset map is getting cut off (only if the map title is wider than map width + inset map, the map is not cut off in width). Maps with a height:width ratio < 1.5 are all getting cut off at the top.
EPS and PDF attached, pygmt doesn’t want to write out *.ps:
File "/Users/christian/Library/Python/3.12/lib/python/site-packages/pygmt/figure.py", line 228, in savefig
raise GMTInvalidInput(msg)
pygmt.exceptions.GMTInvalidInput: Extension '.ps' is not supported. Use '.eps' or '.pdf' instead.
@yvonnefroehlich & @Joaquim - here are a *.ps of @wthelen’s script translated to plain GMT. This one get chopped off at the right
#!/usr/bin/env zsh
gmt begin
gmt figure test ps,pdf,png
# region = [-155.72,-155.62,19.45,19.55]
gmt coast -R-155.72/-155.62/19.45/19.55 -JM8i -Ggray -Bafg
gmt end
I downgraded versions of ghostscript from 10.04 to 10.03,10.02 and 9.56 (No other libraries changed). All had the same behavior (cut off the map).
Returning to gs 10.04, I can recreate the behavior of @Joaquim and @mkononets. I will note that the “-ps lixo” result cuts the plot on the right. It also retains the portrait orientation (unlike the .eps output from .savefig.
Now I tried different things. Overall, I think the issue is related to the “ps” format, and for me, the maps are cutoff also for gs versions lower than 10.4.0.
This works fine for me:
gmt begin
gmt figure test_no_ps pdf,png
gmt basemap -R-155.72/-155.62/19.45/19.55 -JM8i -Bafg
gmt end
but adding “ps”, leads to cutoff maps for all formats:
gmt begin
gmt figure test_with_ps ps,pdf,png
gmt basemap -R-155.72/-155.62/19.45/19.55 -JM8i -Bafg
gmt end
I face the same behaviour here, wherey png (or pdf) work:
OK, so this is what is happening.
In modern mode (PyGMT) only the non-(e)ps formats are plotted in a wall size paper (11 m), which is latter trimmed to the figures BoundingBox. With the (e)ps format, the figure is plotted on a A4 (default) paper size and if the figure overflows it, it get cropped.
Things are more clear on classic mode where we get a warning.
gmt psbasemap -R-155.72/-155.62/19.45/19.55 -JM8i -Bafg -P > lixo.ps
psbasemap [WARNING]: Your plot (WxH = 20.32 x 21.43 cm) placed at (2.54, 2.54 cm) may exceed your PS_MEDIA (WxH = 20.99 x 29.70 cm)
Now I’m trying to figure out how best to solve this issue. Setting the PS_MEDIA doesn’t change the behavior (tried a fixed size, like “B1” and a custom size). Is there a parameter that needs to be passed through the PS_CONVERT config to keep from trimming the BoundingBox? I’ve tried a few different iterations using the I flag (I+m3i, I+sm10i, I+s10i). The results are so similar that I’m not sure its actually doing anything at all.
Not sure this observation is relevant, but both users reporting the issue on PyGMT use macOS-...-arm64-arm-64bit. My Linux x86_64 system does not experience the PyGMT issue.
I have to confess that this issue got over my PostScript knowledge. I did an experiment in Julia where I do always set the wall paper size and asked an eps output … which is also cut. e.g.
Now the bloody crazy thing. Even if I delete the “BoundingBox” and “HiResBoundingBox” lines from the .eps file (attached) it still bloody knows the paper size. How’s that possible?
I’m not an expert, but I think the .[e]ps viewer software always has some specific paper size pre-set. Like my gv sets A4 by default and GMTjl_j.eps gets cut. If I change paper size to A3 the GMTjl_j.eps gets enough paper to be fully displayed. Another viewer (xreader) sets US Letter paper size by default and does not let me to specify paper size manually.
if I run gmt ps2raster GMTjl_j.eps -A -Tg I get a correctly displayed and cropped png image.
It’s a bit more convoluted than that. If you take the original ps (attached) and do:
gmt psconvert GMTjl_j.ps -Te -A
you get a nice croppedeps. But if we do
gmt psconvert GMTjl_j.ps -Tg -A
than we get a nice full png image. Now the puzzling thing is that the good png was created from the bad(?)eps file (psconvert internals). How can that be?
Note, I loaded the eps file in Inkscape and even if I increase the page width, the right size remains cropped.
