Re: [GLE-general] Problems with QGLE on windows 10

[Laurence A. <lau...@yo...>]

I'm loving that there is still interest in GLE!

:-)

On Thu, 15 Aug 2019 at 12:00, Francois Tonneau <fra...@gm...>
wrote:

> A few belated comments --
>
> 1. About QGLE: I am on Debian (minimal netinst) and I could never run QGLE
> successfully, it always complains about not finding a Ghostscript library.
> This is a mismatch between ghostcript versions, QGLE looks for an older
> version of ghostscript than the one installed on current Debian. I guess I
> could fix this by downgrading my ghostscript libraries to older versions
> but I never went through the trouble. I think of GLE as basically a
> command-line application, no need for a gui.
>

I got qgle to work on debian (admittedly, self built rather than packaged
qgle) by maually locating ghostscript as:
/usr/lib/x86_64-linux-gnu/libgs.so.9

Having said that, it still falls over randomly (with ghostscript 9.27).
This seems to be because of API changes that appear with this version.
Quoting from https://www.ghostscript.com/doc/current/History9.htm:

the changelog for 9.27 includes:
"Incompatible changes
The process of "tidying" the Postscript name space should have removed only
non-standard and undocumented operators. Nevertheless, it is possible that
any integrations or utilities that rely on those non-standard and
undocumented operators may stop working, or may change behaviour.

If you encounter such a case, please contact us (either the #ghostscript
IRC channel, or the gs-devel mailing list would be best), and we'll work
with you to either find an alternative solution.

One case we know this has occurred is GSView 5 (and earlier). GSView 5
support for PDF files relied upon internal use only features which are no
longer available. GSView 5 will still work as previously for Postscript
files. For PDF files, users are encouraged to look at MuPDF."

So it looks like they broke gsview with their changes too! By the sounds of
it, we're using something that is undocumented or non-standard with the gs
API.

The only gs calls I can find are in src/gui/glegs.cpp, src/gui/qgs.cpp and
src/gui/qgslibloader.cpp so it might not be too bad to check them off
against any API changes. (I might try to look over the weekend to see if
anything jumps out.)

Another thing that is a little annoying under windows is that gle is only
available as 32 bit and so needs 32-bit ghostscript. I had the 64-bit
version of ghostscript available nicely packaged by my institution but had
to go install the 32-bit version "by hand" (requiring elevated privileges).

It's a while since I've built anything under windows so I don't know
whether it's simply a compiler switch to generate 32- or 64-bit code, or
whether it's a lot more involved than that.

Cheers,

Laurence
-- 
Dr Laurence Abbott <lau...@yo...>
Department of Chemistry,
University of York,
YO10 5DD, UK