GS 9.18 - does not seem to recognize \\spool\printer_name device

[dspiatkowski]

Describe the bug Attempting to print a PDF to a known PostScript printer (Brother HL5470DW), produces an error about unrecognized device:

=== START === Printing: G:\Desktop\AMAZON-PolishBooksOrder.pdf using: 600 DPI resolution!

GPL Ghostscript 9.18 (2015-10-05) Copyright (C) 2015 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. GPL Ghostscript 9.18: Could not open the file \spool\PSCRIPTB . Unable to open the initial device, quitting. === STOP ===

To Reproduce Steps to reproduce the behavior: 1) Execute the following command line to print:

'gsos2.exe -sDEVICE=ps2write -sOutputFile="\spool\PSCRIPTB" -dDEVICEXRESOLUTION=600 -dDEVICEYRESOLUTION=600 -I"G:\usr\share\ghostscript\9.18\resource\init" -sFONTPATH="g:\psfonts;g:\usr\share\fonts\default\ghostscript" filename'

WHERE: "filename" is the sample PDFf file you are attempting to print

Expected behavior The file should spool to the printer's queue and print accordingly.

Additional context There was a BUG logged against a much older OS/2 GhostScript port (see https://bugs.ghostscript.com/show_bug.cgi?id=687542) where the author at that time claims to have developed a patch which allows the OS/2 port to work similarly to other platforms. However, this does not appear to work either.

[SilvanScherrer]

In the bug report above I could not find any reference to the patch. So w/o the patch described above I see a slim change we ever add it. If you dig it out we will look at it.

[dspiatkowski]

@SilvanScherrer Well, the patch referred to in that BUG report is meant to allow GS to deal with '%printer_name%' type of names, which would effectively allow it to sync up with how some of the other platforms reference printers. I agree, the fact that there is nothing there pointing to ANY sort of a patch sucks!

In the meantime, can you (or is there a read.me type doc out there that) spell out how to actually use a printer on our OS/2 platform with the current AS-IS port of GS???

I expected the '\spool\printer_name' to work all along, but that's generating the 'Unable to open the initial device' error message. if that however does not work, or is an incorrect way to reference a printer, what actually does work?

Thanks!

[SilvanScherrer]

one thing is wrong for sure. you typed -sOutputFile="\spool\PSCRIPTB" instead of -sOutputFile="\spool\PSCRIPTB". as in theorie it should work. I checked the code and the handling is in. please run the printer.exe found in http://rpm.netlabs.org/test/ and put the output here

[dspiatkowski]

Out of the printer.exe is:

=== START === [G:\test]printer "PSPRINTB" (DEFAULT) "PSCRIPTB" "ePDFPrin" "FxPrint" === STOP ===

Yes, you are right about what you spotted, however the mistake was on the screen capture I did. Prior to opening this incident I tried numerous combinations in order to exclude all the variosu possibilities (including the ones that the above noted BUG patch apparently fixed). In this case, I also tested the "\printer\PSCRIPTB", unfortunately that did not work either.

[SilvanScherrer]

ok your printer look ok. when time permits I will check the code further. but no timeframe given.

[dspiatkowski]

Glad to hear that the output appears to be a "good" result.

I had actualy downloaded the GS source ZIP file from here, and started to look at the source. I see a bunch of printer routines in gp_os2.c, such as gp_open_printer for example, that appear to account for the printer name and specifically seem to call out the "\spool\queue" naming convention. Strangely enough though, that does not appear to be how the actual code itself works.

Anyways, my question to you is: is there a particular source that I should look at to better understand this? Happy to spend a little time looking at this, maybe even build a DEBUG version of GS to capture some additional details.

Thanks!

[dspiatkowski]

FYI, what I just noticed is that the comments here strip out the double-slash, so even though I had entered "(double slash)spool(slash)queue" only "(slash)spool(slash)queue" showed up.

[SilvanScherrer]

if you use %printer% instead of \spool it should run. %printer% is the new way of doing it since some versions. \spool should also work, but there seems to be a bug

[SilvanScherrer]

this is not a bug, this is how it works. you need %printer% in the -sOutputFile. then you can use either \\spool\yourprinter or just yourprinter

[dspiatkowski]

I'm sorry, but your last comment makes no sense to me:

1) -sOutputFile accepts either "%printer%" or "(double-slash)spool(slash)printer", it can not accept both

2) so when you state "...you need %printer% in the -sOutputFile. then you can use either \spool\yourprinter or just yourprinter..." how exactly are you thinking of using this?

Either way, I re-tested this again (as I pointed out previously I went through multiple combinations of this having reviewed the source and how this was implemented on other platforms) and using '-sOutputFile="%printer%"' does not work, here is what GS produces instead:

=== START === Printing: test.pdf using: 600 DPI resolution!

GhostScript CLI Parameter: -sDEVICE=ps2write -sOutputFile="%printer%" -dDEVICEXRESOLUTION=600 -dDEVICEYRESOLUTION=600 -I"G:\usr\share\ghostscript\9.18\resource\init" -sFONTPATH="g:\psfonts;g:\usr\share\fonts\default\ghostscript" -sInputFile=test.pdf

GPL Ghostscript 9.18 (2015-10-05) Copyright (C) 2015 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. GPL Ghostscript 9.18: Device 'ps2write' requires an output file but no file was specified. **** Unable to open the initial device, quitting. === STOP ===

Please explain further. Thanks!

[SilvanScherrer]

it's like I said %printer%printername, where printername is one of your printers. This is also explained in the docu iirc.

[dspiatkowski]

Using (-sOutputFile="%printer%pscriptb") does NOT work Silvan, it simply creates a FILE named 'pscriptb' in the current directroy, the file is the PS printjob. As I said, I had previously tested all this, I have also read all the documentation, and as you saw my reference to the BUG patch, I tested this specific combination already.

So have you actually been able to make this work on your DEV/TEST system? If YES, then I have a problem elsewhere on my machine, if NO, then you can't really say this works, right?

[SilvanScherrer]

i might look at it later on, but no promise. As I'm not payed to do so and I run out of time.

[dspiatkowski]

No problem. I will continue to review the code base you guys have here with an attempt to build next. If I can get that far I will debug further and update this record with my findings. Appreciate the time you have spent looking into this already!