Invoking Ghostscript on different systems

[haakym]

The method of invoking Ghostscript can vary on systems, e.g. Windows vs. Linux. As mentioned in the docs:

The command line to invoke Ghostscript is essentially the same on all systems, although the name of the executable program itself may differ among systems

In my situation, when using Ghostscript on Windows 7 64-bit there are two available executables:

1. gswin64 - opens a new type-in window
2. gswin64c - runs commands in the console

So gswin64c is what I want to use in combination with my PHP applications.

In Xthiago\PDFVersionConverter\Converter\GhostscriptConverterCommand the method of invoking Ghostscript is gs, however, when running this on my system it won't work and I get the expected error:

RuntimeException: 'gs' is not recognized as an internal or external command, operable program or batch file.

I'm guessing the quick solution is to rename the Ghostscript executable from gswin64c to gs, but would you consider some modifications to the pdf-version-converter package to either allow the user to modify the name of the executable (via some form of config?) or perhaps even by detecting the environment (overkill maybe?) or perhaps something simpler?

I'd be happy to submit a PR for this but would appreciate any thoughts/guidance first on how this should be dealt with even though I imagine this probably affects a small minority of users.

[xthiago]

@haakym nice catch! Thank you to share your thoughts. Your contribution are welcome.

I think we can go ahead with both approaches that you mentioned. My idea:

• add $executable attribute to GhostscriptConverterCommand and a setter method - it will allow someone to change the binary to fit they needs. Maybe the gs is not configured in their $PATH and the absolute path should be provided (e.g: /opt/gs).
• add a private method getExecutable() that will return $executable if not empty, otherwise will return the value based on the Operation System.

What you think?

[edegaudenzi]

I wish to share my experience with you on a Mac (MAMP).

It throws an error because GS is not found. To make it work, the command should reports the full path of gs (/usr/local/bin/gs).

Not to touch the library, you can simply extend the GhostscriptConverterCommand and override protected $baseCommand

[kartik7dev]

@xthiago do we have to install ghost script on the live server as well in order to use your plugin ?

[haakym]

@kartik7dev I'm pretty sure you would, unless the binary is included in the package. I don't recall if it is or not!

[xthiago]

@kartik7dev

@xthiago do we have to install ghost script on the live server as well in order to use your plugin ?

Yes, you have to install it on the server.

[kailasb]

@xthiago
I've install the ghost script but not able to access with "gs" but I can access "gswin64c" using this in windows terminal. when I access it from code it's not working. 'gswin64c' is not recognized as an internal or external command, operable program or batch file getting this error. the command getting from "baseCommand" run in windows terminal it's working.

can you guide me where I wrong.