In our software we need to be able to convert SPL files which printer drivers write to the C:\Windows\System32\spool\PRINTERS folder to PDF files. For SPL files in PCL format we perform this conversion using pcltool.exe from VeryPDF, which mostly works fine. However we are having trouble with SPL files generated by the printer driver "Canon iR-ADV C5235/5240 PCL6". As an example, the following SPL file results from printing out a single page in notepad with the word "something" on it:
http://files.etvdzs.info/00025.spl
Converting 00025.spl using pcltool.exe results in a 70-page PDF with a row of garbage characters at the top of each page. Attempting to open 00025.spl using other PCL viewers gives similar results. We asked VeryPDF and they told us it is not a valid PCL file.
Can anybody tell me what exactly is invalid about this file? Is there any possibility of converting it to valid PCL or otherwise extracting usable data from it?
Incidentally, we had a similar problem with Postscript files generated by the "Canon iR-ADV C5235/5240 PS3" printer driver. There were binary sequences beginning with $CDCA10 and ending with $FFFF000000000000000001 at various positions in the files. After removing these sequences, we were then able to convert the files as normal. I tried a similar solution for the files generated by "Canon iR-ADV C5235/5240 PCL6", but unfortunately was not successful.
EDIT (13 Sep 2013): It seems that the binary sequences are CPCA codes. I was able to obtain documentation about CPCA by signing up for the Canon Developer Support Program at the following URL:
https://www.developersupport.canon.com/user/register
After reading this documentation, I wrote a program to remove CPCA codes from spool files. This is the result of running the program on the file 00025.spl from above:
http://files.etvdzs.info/00025.cleaned.spl
Unfortunately this still doesn't seem to be a valid PCL file :-( Can anybody tell me what exactly is wrong with this file? Is there any possibility of converting it to valid PCL or otherwise extracting usable data from it?
P.S. The program I wrote does successfully convert spool files generated by the printer drivers "Canon iR-ADV C5235/5240 PCL5c" and "Canon iR-ADV C5235/5240 PS3" to valid PCL and Postscript respectively, so I don't think it is a simple matter of the program not working.
Odds are you have something like an EMF or similar file here. Ensure that the server queue (if you are printing to a network printer) is set to 'Render on client computer'. I would also look to set the Print Processor to Winprint RAW. It could also be that the Canon PCL printer isn't as generic as you'd like. You can always try a different PCL driver and see if your converter and the Canon device support the format. To confirm that the issue isn't the Windows Spooler you can set the port to FILE and/or use a capture utility to write out what the printer would actually receive post all processing. If that works but the SPL doesn't then you have a Windows Spooler and/or processor issue.
vclpdcap Capture utility
Related
I'm using PDFCreator Free, which uses Ghostscript (gswin32c.exe) behind the scenes to produce PDF files by printing to a virtual printer. I'm using it in batch mode, which generates the PDF, then launches a custom batch file.
Some large files take several minutes to complete, during which time there is no way to determine progress (my batch file doesn't launch until the process is done). I can see the gswin32c.exe file running in Task Manager, and in the %Temp%/PDFCreator directory, the Spool and Temp directories get some content.
Is there a way to determine Ghostscript's progress (or at least the number of pages already generated) so I can report this from somewhere? I can't see or change the command-line arguments sent to Ghostscript, since it's called from the proprietary PDFCreator software. Is there a file somewhere that contains some type of status or metrics on the running GS process?
Basically, no. It depends slightly on the exact command-line arguments (which you haven't given), but I imagine all the feedback is being suppressed.
Note that pdfwrite doesn't create any pages at all until its finished processing the input, and there's no easy way to determine how many pages are in the input PostScript program.
I would like to make my own "PDF printer" using Ghostscript.
Most of solutions I find on the internet involve a 3rd party like Redmon to redirect the PS printer to the Gs executable.
Is there a way to do the same without a 3rd party (other than Gs) ?
Here is my 2 ideas:
Bypass the printing driver and generate Postscript directly by software (From GDI to postscript, using maybe a custom device context like the Metafile device context exist)
Create programmatically a new local port for each document to convert. Maybe using this technique : https://stackoverflow.com/a/1331777/99276
The first solution would be great, but can't find anything about it.
And I am efraid the second is not efficient at all (and detect when the document is fully printed can be tricky)
Update: I used print apis to print in a temp file (the print is synchronous) and then convert the PS file with Gs
Firstly; note that the Windows printing system has been redesigned in Windows Vista and beyond. While the old system still works in WIndows 7 and 8, I am unsure of exactly how usable it is in Windows 10. In Windows 10 everything goes via XPS, and I think (could be wrong) that PostScript is generated by going via XPS first.
Your first idea doesn't sound plausible to me. How can you have a printer (and allow your application to print to it) if you don't have a printer driver ? Even if you could do so, why would you create PostScript from GDI just to send it to Ghostscript and have it create PDF ? It would be far more reasonable to create PDF directly.
In the second case I don't see how adding a new local port would help you at all. Ports are simply where the output of the printer driver is directed. What a Port Monitor (RedMon is a Port Monitor) does is redirect the data stream sent to the port, and 'do something' with it. In the case of Ghostscript + RedMon the 'something' is create a PDF file.
I'm unclear why you don't want to use RedMon, given that you are apparently happy with using Ghostscript. However, if you really don't want to do that then write your own Port Monitor. The process is documented in the Windows Device Driver Development Kit and isn't especially hard. If you get stuck you can even look at the RedMon code as a guide. For example, see here
I have a compiled program which runs great after being compressed, copied to another computer using a USB key, extracted and ran.
However, if I upload the compressed file to Google Drive or Dropbox, download it and extract it, the program will not run. It gives me an error "program.exe has stopped working".
Using a tool called WinMerge, I compared the program that was extracted from a USB drive with the program that was extracted after being downloaded. Every file, both binary and text, was identical.
Next I used attrib -r -a -s -h on every program file in both folders, thinking perhaps one of the file attributes was incorrect. I still had the same problem; the copied program works, the downloaded one does not.
I also tried changing the name and location of the folders the program was in but it had no effect.
The only thing I can think of is some additional attribute that Windows gives files which were downloaded from the internet, to possibly trigger an additional UAC check which is interfering with the program. Does this exist?
This is on Windows 7.
Found the problem. Windows adds an Alternate Data Stream (ADS) to every file downloaded off the internet. For some reason, these streams were preventing the program from running. Stripping the ADS from each file allows it to run.
I used a Windows Sysinternals program called Streams to strip the ADS data.
I'm having an issue with parsing the information from a Google Protocol Buffer binary.
The scenario is:
I have two computers, a Mac and a PC.
They are both running Ruby 2.0.0p481.
They both have the ruby-protocol-buffers gem, version 1.5.1.
The protocol buffer binary file is 219 bytes on both computers, which leads me to believe that their contents are exactly the same.
I have the same ".proto" files on both computers, as well as the same pb.rb files that I am using to interpret the protocol buffer binary.
I wrote a short script that uses the auto-generated pb.rb files to parse the binary file, and have the same copy of the script on both computers.
However, when I run the script that interprets the binary file, the outputs are different on the Mac versus the PC.
When I run the script on the Mac, I get the exact information that I am expecting, which is all the information the protocol buffer contains. However, under the conditions mentioned above, when I run the same script on the Windows machine the output contains significantly less information.
I'm not sure why the output is so different, because I've made sure many of the variables (Ruby version, gem, gem version) are the same in both environments (Mac and PC). I also got the binary file individually on both the Mac and the PC from the same source at almost exactly the same time. I made sure to retrieve the binary file separately on both computers in case this might be an issue with line endings across Mac/PC, but it does not seem to make any difference.
What is causing this difference in output between Mac and PC?
I managed to answer my own question, here. Mainly by the help of the creator of the ruby-protocol-buffers gem.
He suggested: "It's possible you're hitting a problem with a file getting opened in text mode rather than binary mode."
See his full answer here:
https://github.com/codekitchen/ruby-protocol-buffers/issues/35#issuecomment-55759174
I then searched for how to open a file in Ruby in binary mode and found this stackoverflow question:
Automatically open a file as binary with Ruby
The following is a direct quote from that post:
While it's true that there is no "text" mode in Unix file systems, Ruby does make a difference between opening files in binary and non-binary mode:
s = File.open('/tmp/test.jpg', 'r') { |io| io.read }
s.encoding
=> #<Encoding:UTF-8>
is different from (note the "rb")
s = File.open('/tmp/test.jpg', 'rb') { |io| io.read }
s.encoding
=> #<Encoding:ASCII-8BIT>
The latter, as the docs say, set the external encoding to ASCII-8BIT which tells Ruby to not attempt to interpret the result at UTF-8. You can achieve the same thing by setting the encoding explicitly with s.force_encoding('ASCII-8BIT'). This is key if you want to read binary into a string and move them around (e.g. saving them to a database, etc.).
I have a little project at work, but I'm stuck in my tracks at the moment. We have quite a few Motorola MC1000 hand held barcode scanners at work, doing nothing at the moment, and I want to get them working again for stock takes and what not.
Now, these were pre-installed with a program called MCA, which is a simple barcode scanner and quantity program, which I'm not sure where it saves this information (maybe in memory), but I am unable to get the data from just connecting the device via USB.
On the program, there is a section called "send data" which then outputs data via COM1 port. I have managed to intercept the old program we used to read the barcodes (there is no way to export from this old program), so I need something new, where I can export barcode, quantity via CSV.
Using serialmon, I have found that I can read the barcode, plus some extra confirmations? then the quantity, plus more confirmations, then the next barcode.
Now I need to know if there is a program out there already that can connect to the com1 port, and then read/respond to the device to download all the barcodes and quantities and then export this to a csv, or even if a simple command prompt bat file could do this?
After some testing earlier, I know the device needs to receive an ack in some way as it times out without this (I could manually do this by sending %0 on a regular basis).
Thanks in advance.