For a research project about printing nanofluids with an Piezo electric printer I want to see the the code that the computer sends to the printer. I am running Ubuntu 16.04 and have an Epson Stylus SX600FW printer.
Using Ghostscript 9.18 I want to print a simple ps file and obtain the output file that is being send to the printer. This file should contain some ESC/P sequences if I am right. Now I have some problems with the rigth driver is Ghostscript.
I want to print the file using : gs -sDEVICE=epson -sOutputFile=%pipe%lpr test.ps. The printer starts the print gibberish. Just some letters and symbols on page, not the two words that are in my test.ps.
So probably ghostscript doesn't use the rigth driver. How can I get gs to use the escp2-of-sx600fw or Epson-Stylus_Office_SX600FW driver, as stated on the gutenprint site?
Kind Regards Rick
If you want to use a non-standard device, then you will have to rebuild Ghostscript and tell it to include the device's source in the build.
Nobody has supplied us with source to an Epson SX600FW device, so we don't supply it, not even in the contrib directory. There is a 'vector' Espon device in there, but its not built in as standard.
Looks like Gutenprint itself drives the printer. Presumably it only uses Ghostscript to render PostScript and PDF files into some intermediate format that it can then convert onwards to the specified device format. If I'm right, then you can't make Ghostscript use the Gutenprint device driver, as that will be specific to GutenPrint. You'll have to use Gutenprint to do that.
Related
I've been using GSView 5.0 and GhostScript 9.52 to do postscript printing on vellums. However, today GSView started throwing error codes on every .ps file I've attempted to print. I'm using Windows 10 Pro and the printer is an Epson Artisan 1430.
The error is as follows:
GPL Ghostscript 9.52: **** Could not open file 00000e60.
Unrecoverable error: invalidfileaccess in showpage
Operand stack:
--nostringval-- 1 true
gsapi_execute_cont returns -9
gsapi_exit returns 0
I've tried changing permissions for the files and different printer drivers to no avail. I'm sorry I can't be more descriptive on this issue as it's hard to articulate.
OK... You must have recently updated to a new version of Ghostscript. I can reproduce your problem, and it comes down to a recent (documented) change in behaviour for Ghostscript.
Due to the well-documented public disclosure of security exploits using Ghostscript a couple of years ago, the current version (and any version since 9.50) now defaults to running in SAFER mode.
When running in SAFER, Ghostscript prevents access by the PostScript interpreter to the file system. For those unaware of the problem; PostScript is a full-blown programming language and, by design, permits programs to access the underlying file system. SAFER mode prevents this so that malicious PostScript programs cannot, for example, run arbitrary code on your computer.
It seems that GSView is using Ghostscript in a way which requires it to read the PostScript program to be printed using the PostScript interpreter, instead of the more normal practice of specifying the input file as one of the arguments. For simplicity the input file is granted read availability by the Ghostscript executable. I suspect that GSview is using the DLL directly and not adding that extra information.
Now there are ways to permit access to specific files or folders, so that existing PostScript programs can continue to work, but obviously this requires some changes in the calling application. GSview has not changed in, literally, years so obviously it does not take any such action.
You can, however, get GSview to work as before. Under Options select Advanced Configure. In the resulting dialog look for the 'Ghostscript options' text box. In there add -dNOSAFER, that should get it to work again, though you may have to reboot the computer if the OS print subsystem has stalled.
Yes, this does open you up to the sorts of exploits I alluded to above, you should only do this with PostScript programs that you trust.
I am invoking the following from a windows service under Windows 10 or Windows Server 2012 (C# program that shells out to execute the command), but nothing is being printed. I can copy and paste the command being sent into a command prompt, but it pops up a print dialog and I have to click ok for the file to print (which it does). What switch do I need to add such that the dialog won't come up and the file will be printed directly without user intervention since the intention is for this to work unattended as a windows service? This is ghostscript 9.50, which is the latest as of today. In an earlier version of ghostscript this worked if the device was set to ljet4 but this was causing an error with 9.50. Also, the output file did not have the %printer% prefix on the outputfile and previously it was prefixed with \\spool\. I have tried all of these combinations. Is it the mswinpr2 that is causing the unwanted dialog? I'm guessing this is what is preventing the printing to occur.
gswin64c -dPrinted -dBATCH -dNOPAUSE -dNOSAFER -q -dNumCopies#1 -sDEVICE#mswinpr2 -sOutputFile#"%%printer%%HP LaserJet Professional P1109w" "\\2-DYQJKC2\c$\Webs\myfolder\Public\Reports\HIPAACert\189\H01519447A2191016103332.pdf"
The mswinpr2 device needs to be able to select the Windows printer, yes. If it cannot for any reason (mistyping the printer name is a classic reason for example) then it will pop up the printer selection dialog. It has to otherwise it doesn't know where to send the output. I'd have to guess this is your problem (nothing to do with adding extra switches)
You should be using %printer% from the command line, you only need to double the % in a batch file, because batch file processing tries to interpret the % so you have to escape it. So if you are doubling the % in the command line then yes, it will indeed pop up a dialog box, because %printer% is not the same as %%printer%% so Ghostscript won't recognise this as a printer.
I'd suggest that you keep on working from the command line until you get a result, so don't double up the %.
Other than that, its difficult to comment. Do you get anything on the back channel (you'll want to drop the -q while debugging too) ? Obviously I'm not sitting in front of your system, so I can't see what the printer is called.....
FWIW I tried it here with the "Adobe PDF" printer and it works, but using the "Microsoft XPS Document Writer" does not, and in fact even selecting that from the dialog fails "Unable to open the initial device".
[edit]
A little debugging later....
The function DocumentProperties() fails with the Microsoft XPS Document Writer. I suspect this is because the printing system on Windows was significantly reworked for Vista and above, and Windows 10 does away with much of the legacy code. I suspect this old Win32 API call simply doesn't work with newer devices.
If your printer works when you select it from the print dialog, however, this is not the same problem. For me this printer fails even when selected from the print dialog. Seems its just not compatible with the old Win32 API.
NB this also displays the error "Printer StartDoc failed (error 00000006)".
So I still suspect that you have some problem with the printer name. Maybe a quick test would be to set the name to something really simple like '"Printer1' and try that.
I can't think of anything which has changed in the ljet4 device which would cause a problem, you don;t say what the error is, or even where it occurs, on the printer or reported by Ghostscript, so there's really nothing I can offer on that front.
I recently ran into the same issue. I added a -dQueryUser=3 argument. The documentation on the use of -dQueryUser=N can be found at:
https://www.ghostscript.com/doc/9.25/Devices.htm#Win
in the
10.2 Supported options (device properties)
section.
The code that illustrates this, in a batch file on Windows 10, is:
SET MY_EXECUTABLE_PATH=C:\Program Files\gs\gs9.53.3\bin
for %%i in (*.pdf) do "%MY_EXECUTABLE_PATH%"\gswin64c.exe -sDEVICE=mswinpr2 -dBATCH -dNOPAUSE -dPDFFitPage -dQueryUser=3 -sOutputFile="%printer%Printer_Name" "%%i"
I am having difficulties to print a pcl file to a gdi printer via ghostpcl. On some forums a suggested solution is to set mswinpr2 as the output device. This should produce GDI output for a windows printer. The problem is, there seems to be no mswinpr2 built into ghostpcl. When running ghostpcl -? there is no such device listed. Can anyone clarify this?
I'm not sure what version you are using, but for me the executable is called pcl6.exe, not ghostpcl. In any event the mswinpr2 device is not built into the PCL interpreter by default. While it may work with the PCL interpreter, it depends how the device was written. If you want to use it you'll have to build GhostPCL from source.
This might sound like a very foolish question but I've been reading around and haven't been able to understand the lifecycle of a print job.
Program → PostScript → GhostScript → ? → Printer
My doubt is, what ( if any ) comes in the place of ? ?
To be honest, in general Ghostscript isn't in that loop at all, though it depends very much on your printer and operating system.
In general you would send PostScript directly to the printer, which would have a PostScript interpreter built in. If you don't have a PostScript printer, then you would (normally) produce some other page description language (eg HP PCL) and send that to the printer.
However (expanding slightly on what george said above) on Unix systems you may be using CUPS (Common Unix Printing System), which does use Ghostscript to render PostScript to a raster format (CUPS raster) for non-PostScript printers. The CUPS printer drivers repackage the raster into a form suitable for the specific printer.
Note that modern versions of CUPS use PDF as an intermediate format and so Ghostscript may be involved twice, once to create a PDF from the PostScript, and once to render a PDF to raster (or indeed, to convert it back to PostScript.....)
Also, there is the gsprint application, which works on Windows, it uses Ghostscript to render a bitmap which is written to a printer canvas and then using GDI calls printed to the printer using the Windows printer driver.
If you want to go the ghostscript route, the question mark would be filled in with "gsprint" which is part of the "gsview" package.
gsview allows postscipt files to be viewed with ghostscipt, where gsprint allows postscript files to be sent to a printer with ghostscript.
http://pages.cs.wisc.edu/~ghost/redmon/index.htm
Then to create a windows printer to be able to send the postscript output to, which would then run gsprint and output to a printer, you need "redmon".
http://pages.cs.wisc.edu/~ghost/redmon/index.htm
Your OS printer driver would fit in that spot. It receives the rendered output from ghostscript and converts it to a printer-specific format.
When connected, my Zebra printer the S4M is recognised by Windows with the "ZDesigner S4M-203dpi ZPL" driver and I'd like to use the EPL Driver "ZDesigner S4M-203dpi EPL".
I tried to install it manually, delete the ZPL driver, use the Zebra utility setup, upgrade the firmware to the last version but I didn't find the switch option.
I found one answer : http://www.fixya.com/support/t1950296-zebra_sm4_label_printer_change_zpl_epl
You will need to change the firmware on this printer in order to be able to change the language. I don't believe this printer will allow you to change the language using the advanced options in the menu unless they have recently changed this.
I found also a web page which proposed to download old driver for the S4M but I prefer to avoid it. http://www.jamfrance.com/site/support/download.asp?categorie=13
Note : To verify if the EPL driver was working, I used a custom application which send EPL data and I tryied to use Zebra firmware downloader which have 2 interesting options : Send EPL page and Send ZPL Page. You probably guessed, only the ZPL page works.
well i found the solution : https://km.zebra.com/kb/index?page=answeropen&type=open&searchid=1324718583535&answerid=16777216&iqaction=5&url=https%3A%2F%2Fkm.zebra.com%2Fkb%2Findex%3Fpage%3Dcontent%26id%3DSO8156%26actp%3Dsearch%26viewlocale%3Den_US&highlightinfo=6292684,73,91#
The EPL firmware is listed in the Special Firmware section on Zebra.com.
I have to install the special firmware of the S4M and it works .. it's sad that they don't explain the "Special" term (and in the release note also)