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.
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"
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.
Context:
I am writing a program, which uses pcap to capture packets in the monitor mode on the openwrt router with ar9331 chip.
I tested the program on a desktop with pcap 1.1 (which existed in my openwrt version) and found an issue: pcap_can_set_rfmon returned true, pcap_set_rfmon returned success, but attempt to activate capture resulted in “monitor mode isn't supported” error.
Google search showed a bug report of similar issue with wireshark. One of the comments says that with some wi-fi devices the issue is caused by an old version of pcap, which uses old version of another lib.
I updated pcap version to 1.5.3 and the issue was resolved.
Problem:
The issue appears again when I port our program to Openwrt. But now update of libpcap package to version 1.5.3 from newer openwrt branch doesn't help.
Sadly, the libpcap monitor-mode code on Linux works best when libpcap is linked with libnl, and it's often not linked with libnl for various reasons (including problems with a program using libpcap and libnl, and linked with a different version of libnl than the one with which libpcap is linked).
This needs to be redone in libpcap. It may end up being done with a "helper process" that libpcap runs to do various things; that would also improve cleanup if the program using libpcap exits abnormally and would allow packet capture operations requiring special privileges to be confined to the helper process rather than requiring the program using libpcap to run with those privileges. This is on my rather long to-do list.
The best workaround is probably to use airmon-ng to turn monitor mode on, as described in the Wireshark Wiki page on Wi-Fi capturing.
I am running into hardware issues that perhaps someone here knows a workaround. I am using a PC and windows.
For several years I have been making interactive installations using video tracking: the Jmyron library in Processing, which has functioned marvelously for me. I use this set up: cctv type microcameras to a multiplexer, the I digitize this signal via a firewire cable to a pci card. Then Processing reads these quads (sometimes more) as a single window, and it has always worked (from windows xp all the way to 7). Then comes windows 8: Processing seems to prefer the built-in webcam to the firewire bus. On previous version of windows, the firewire bus would naturally override the webcam, provided I had first opened a video capture in Windows Maker, and then shut it down before running the Processing sketch. In Windows 7, which had no native video capture software, I used this great open source video editor called Capture Flux. The webcam never interfered. With Windows 8, no matter what I try, Processing defaults to the webcam, which for my purposes is useless. I have an exhibition coming up real soon, and there is no way I am going to have the time to rewrite all that code for Open CV or other newer libraries.
I am curious if anyone has had similar problems, found a work around? Is there a way of disabling the webcam in Windows 8 (temporarily of course, because I need it to be operational for other applications), or some other solution?
Thank you!
Try this:
type "windows icon+x" choose device manager (or use run/command line: "mmc devmgmt.msc")
look for imaganing devices, find your integrated webcamera
right click on it and choose disable - now processing should skip the device.
Repeat the steps to reenable the device.
Other solution would be using commands in processing:
println (Capture.list()); (google it on processing.org) this way you will get all avaliable devices and you can choose the particular one based on its name.
Hope this helps.