Check status of ghostscript before releasing 6.1.0

[PaulWessel]

Once again a ghostscript release (9.51) comes with bugs affecting GMT, in this case a loss of transparency. The problem has already been reported and hopefully distributions will get a patch or there will be a 9.52 soon. Whatever the situation is, when GMT 6.1.0 is released we may need to warn against 9.51 or add a warning in psconvert when users request transparency.

A secondary issue in 9.51 was the unannounced breaking of backwards compatibility by now requiring the option -dALLOWPSTRANAPARENCY to activate the PDF transparency machinery. GMT enabled this in #2902 but due to the above bug it has no effect yet.

[joa-quim]

I can see transparency directly on the PS files when using the, now abandoned by Artifex, gsview6.0.

[PaulWessel]

9.52 has been released but apparently not addressing the bug in transparency reported above.

[PaulWessel]

Update: Per Chris Liddel, next gs 9.53 is slated for September. They do one very 6 months apparently. So 9.50 for a while for us.

[remkos]

Have you tried the solution that is posted on the ghostscript website, i.e. using -dALLOWPSTRANSPARENCY ?
See: https://www.ghostscript.com/doc/9.52/News.htm (Section 1.1.)
And: https://www.ghostscript.com/doc/9.52/Use.htm#ALLOWPSTRANSPARENCY

Although, reading https://www.ghostscript.com/doc/9.52/Language.htm#Transparency, I'm not so certain this will do it.

Update: Tried running psconvert -C-dALLOWPSTRANSPARENCY with ghostscript 9.52. It did not work. So the approach of downgrading to 9.50 still holds.

[PaulWessel]

Thanks @remkos for checking. We will probably need to look at the transparency setup more carefully going forward, but plate is full right now....

[seisman]

FYI, ghostscript 9.53 is released.

[seisman]

One of the biggest changes is that the ghostscript version is 9.53.0, not 9.53. It may break some codes.

[PaulWessel]

I think we only check gs --version output in psconvert where we take the string returned and do this:

int n = sscanf (cmd, "%d.%d", &gsVersion.major, &gsVersion.minor);

If the string "9.53.0" is given I think (because of %d) that we still will return 53 and the ".0" is not used. We should add a &gsVersion.patch entry going forward and if we get 3 or 2 it does not matter. I guess once we install 9.53.0 we will know if this causes any problems.

[joa-quim]

Windows installer is already using pre-9.53.0, which because it was built from master claims to be 9.54.0

[seisman]

I installed gs 9.53.0 on macOS via homebrew. It works perfectly for me, although it gives me annoying warnings for transparent figures:

   **** WARNING: .setopacityalpha is deprecated (as of 9.53.0) and will be removed in a future release
   **** See .setfillconstantalpha/.setalphaisshape for the improved solution

In the Windows CI, we install Ghostscript from Chocolatey. It used to work fine, but after updating to gs 9.53.0, GMT can't find gs anymore:

psconvert [ERROR]: Cannot execute Ghostscript (gswin64c).
end [ERROR]: Failed to call psconvert
end [ERROR]: gmtinit_process_figures returned error 78

[PaulWessel]

I guess we will have to implement the new scheme under a version if-test...

[seisman]

I suspect that the new gs 9.53.0 installer doesn't modify the Windows registry or use a different name, thus GMT fails to find it.

[joa-quim]

Yes, we have this

if (psconvert_ghostbuster(GMT->parent, C) != GMT_NOERROR)  /* Try first to find the gspath from registry */
	C->G.file = strdup ("gswin64c");     /* Fall back to this default and expect a miracle */]

But no miracle expected anymore on 64 bits systems because we now ship a gswin64c in the installer.
If Artifex changed the registry key they would break all softs that depend on ghostcript.

[seisman]

But no miracle expected anymore on 64 bits systems because we now ship a gswin64c in the installer.

It doesn't help solve the problem in the Window CI.

For Chinese users who want to typeset Chinese characters in GMT, the gswin64c shipped in the installer doesn't work due to the lack of some CJK configurations files, so they still have to install the official ghostscript.

If Artifex changed the registry key they would break all softs that depend on ghostcript.

I asked @sqdeng to try ghostscript 9.53.0 and report some details. When he installed GMT 6, he didn't choose the builtin ghostscript component, and he installed ghostscript 9.26, which works fine.

He then uninstalled gs 9.26, and installed gs 9.53.0. Here are the error messages:

end [DEBUG]: gmtlib_get_graphics_item: Fig: 0 Subplot: 2 Panel: () Inset: 0
end [DEBUG]: psconvert: 'C:/Users/sqdeng/.gmt/sessions/gmt_session.11968/gmt_0.ps-' -Tg -Fmag_hist -A
end [DEBUG]: GMT now running in modern mode [Session ID = 11968]
end [DEBUG]: Revised options: 'C:/Users/sqdeng/.gmt/sessions/gmt_session.11968/gmt_0.ps-' -Tg -Fmag_hist -A
end (gmtlib_free_tmp_arrays): tried to free unallocated memory
psconvert [DEBUG]: Ghostscript not found in registry. Fallback to PATH.
psconvert [DEBUG]: gmt_check_executable: Pass to popen: [gswin64c --version 2> NUL]
psconvert [DEBUG]: gswin64c --version 2> NUL failed
psconvert [ERROR]: Cannot execute Ghostscript (gswin64c).
psconvert (gmtlib_free_tmp_arrays): tried to free unallocated memory
end [ERROR]: Failed to call psconvert
end [ERROR]: gmtinit_process_figures returned error 78

Obviously, GMT can't find the newly installed gs 9.53.0 in the registry.

This is the screenshot of the Windows registry for gs 9.53.0:

This is the screenshot of Windows registry for gs 9.26 (he renamed the old gs 9.26 registry to "aaaaa"):

Does anything seem weird to you?

[joa-quim]

That's not what I have. It misses the GS_DLL key that stores the dll location.

[seisman]

FYI, ghostscript just released a patch version 9.53.1 yesterday. Will try and report later.

[seisman]

I just installed ghostscript 9.53.1 in a Windows 10 Virtual Machine environment. Here is the registry for gs:

It looks normal to me, but GMT (again, I don't choose the built-in gs when installing GMT) still can't find it in the registry.

[seisman]

gmt/src/psconvert.c

Lines 2767 to 2768 in d3d64d0

	sprintf(ver, "%.2f", maxVersion);
	strcat(key, ver);

I can't say that I fully understand the codes, but it seems the codes assume the ghostscript version is a "float"-like value, e.g., 9.53, but ghostscript now uses version strings like 9.53.1. It may explain why GMT can't find the registry.

[joa-quim]

Yes, they f it up when they changed the format of that registry key. Please try #4223
But note that for the Chinese users they will need to remove the gswin64c.exe (and dll) that we ship because it will be picked first, before even checking the registry. This is not ideal. The best is that we provide also the missing files.

[seisman]

It seems we can close the issue as gs 9.53.3 was released a few months ago and works well with GMT.