external pdf conversion broken

[jarnowic]

Followed the instructions at issue #4261 and the conversion failed.

The same happened with the previous gs9.23. I am using SumatraPDF 3.5.2 64 bits on Win10.

[GitHubRulesOK]

GS has some different switch methods in v10 compared to v9 so you have not said why it does not work.

I showed a set that at the time worked with 3.5.2 for convert viewed PS 2 PDF so they should still work ?

To clarify current position SumatraPDF will read PS files when GhostScript is available from the Registry so Viewing PS is unaffected but "Save As" can ONLY now (without assistance) be PostScript. e.g. Same File.

Although currently using a personal special version (dbg-3.6.16864.x32mod-32) it should be no different when using GS v10

That PS file is at "C:\Users\K\Desktop\Apps\pdf\GS\gs10040\printer.ps" and that too is where my "not installed" version of GS is.
again I have a variant there of C:\Users\K\Desktop\Apps\pdf\GS\gs10040\bin\gs.exe so to prove a non installed standalone (or even an installed) copy can be used will use the more conventional gswin32c.exe or gswin64c.exe as an EXTERNAL Viewer.

When the ExternalViewer is added manually I can do a convert and the intentional PAUSE allows me to see it ran.

We can see it is the Printer.PS converted to Printer.PS.pdf

Once you are happy it is functional you can remove the && PAUSE

	[
		CommandLine = c:\windows\system32\cmd.exe /r " "C:\Users\K\Desktop\Apps\pdf\GS\gs10040\bin\gswin32c.exe" -sDEVICE=pdfwrite -o "%1.pdf" -f "%1" && pause "
		Name = Convert &To PDF
		Filter = *.ps;*.eps
	]

In fact you can simplify the command just down to the exe like this by remove all before the ".exe" and after the input -f "%1"

		CommandLine =  "C:\Users\K\Desktop\Apps\pdf\GS\gs10040\bin\gswin32c.exe" -sDEVICE=pdfwrite -o "%1.pdf" -f "%1"

[jarnowic]

Report: the second option: namely,

CommandLine =  "C:\Program Files\GS\gsXX.XX\bin\gswin64c.exe" -sDEVICE=pdfwrite -o "%1.pdf" -f "%1"

works fine on Win10 (64bit).

Apparently the interface (for lack of a better name) through c:\windows\system32\cmd.exe /r is the broken piece; it should be replaced by a call to a proper 64bit shell, but I have not been able to figure that out.

Interestingly enough, the following also works:

CommandLine = c:\windows\system32\cmd.exe /c " gswin64c.exe -sDEVICE=pdfwrite -o "%1.pdf" -f "%1" && pause "

if the gswin64c.exe is in the %PATH% environment variable.

Otherwise,

CommandLine = c:\windows\system32\cmd.exe /k " "c:\program files\gs\gs10.04.0\bin\gswin64c.exe" -sDEVICE=pdfwrite -o "%1.pdf" -f "%1" && pause "

fails with the following message:

"c:\program" no se reconoce como un comando interno o externo,
programa o archivo por lotes ejecutable.

So perhaps the quoting system is failing at some point,

Notice that I used the /k switch to debug the command line, as the call to the shell failed without warning with the /c flag.

[GitHubRulesOK]

"c:\program" not runnable or equivalent
means the space in the command was not correctly allowed for.

This can in some cases be overcome by use %ProgramFiles%\ to replace c:\Program Files\ so as to avoid such issues,
however that will usually need to be run in the system32\cmd.exe line as it is part of the 32/64 shell "environment"

[jarnowic]

"c:\program" not runnable or equivalent means the space in the command was not correctly allowed for.

Indeed.

This can in some cases be overcome by use %ProgramFiles%\ to replace c:\Program Files\ so as to avoid such issues, however that will usually need to be run in the system32\cmd.exe line as it is part of the 32/64 shell "environment"

tried to no avail:

c:\windows\system32\cmd.exe /s /k " "%programfiles%\gs\gs10.04.0\bin\gswin64c.exe" -sDEVICE=pdfwrite -o "%1.pdf" -f "%1" && pause "

Exit message: El sistema no puede encontrar la ruta especificada.

So I fear the shell quoting system is truly broken on Woe10.

[GitHubRulesOK]

This will be a long haul as SumatraPDF DOES adjust for "%" and "

Take a simple case on command line this will be acceptable to CMD but not permitted in SumatraPDF

>%comspec% /k echo result = "test"

response

result = "test"

However when run as a SumatraPDF command line it will not run for several security and parsing reasons starting with the external environmental %comspec% is not called (not allowed for an initial command).

Thus for that case we need to use the longer system call or simpler call a fixed location batch file by name !

SumatraPDF 3.5.2 will "interfere" with the calling by automatically append the filename and alter the " (agreed that is unwanted interference)

That in not uncommon in Windows VBA or VBS ! but is not the case here!

The solution is similar to override the " handling by using triplets

[jarnowic]

neither doublet nor triplet worked, if that's what you meant to imply in your post; so, for the time being, I'll stick to the previous solution:

commandline = c:\windows\system32\cmd.exe /c  " gswin64c.exe -sDEVICE=pdfwrite -o "%1.pdf" -f "%1" && pause "

since my system has gswin64c.exe in the path.

I'll test the other solution tomorrow in the machine at school.

[jarnowic]

hello! tried another, older gs (portable) installed at school, and the space seems indeed to be the problem:

CommandLine = c:\windows\system32\cmd.exe /k " "C:\portapps\napps\GSView\gs8.64\bin\gswin32c.exe" -sDEVICE=pdfwrite -o "%1.pdf" -f "%1" && pause "

and

CommandLine = c:\windows\system32\cmd.exe /k " "C:\portapps\moreapps\CommonFiles\Ghostscript\bin\gswin64c.exe" -sDEVICE=pdfwrite -o "%1.pdf" -f "%1" && pause "

run without issue, with paths without spaces.

Interestingly, the setting

CommandLine = "C:\Program Files\gs\gs9.23\bin\gswin64c.exe" -sDEVICE=pdfwrite -o "%1.pdf" -f "%1" 

runs without trouble, but there seems to be no way to debug it.

[jarnowic]

So, does the space parse problem qualify as a bug?

[GitHubRulesOK]

I previously opened an issue cant remember the number when I first had to use """
Spaces in commands are always an issue since Windows alowes them in folder paths and filenames where other systems do not.
So this may be a duplicate? but letting it ride as it adds to the discussion as to what may be useful when using external commands !