Send Raw Print Jobs do not print

[Joe_Terp]

Hi, 

  I have read through the different problems listed here. I see things that are similar, but I see no exact duplicate.

   I have software that generates pure PCL files.  We have been using the standard Windows RawPrint solution (StartDocPrinter, StartDocPage, ...) to send to printers for years (like 20).   We have sent files to HP, Canon, Lexamark, Kyocera, Brother, etc.    We just upgraded our printers in our Demo Room to brand new M506dn (to get the duplex).    Well, we have run into problems.   We cannot print to the printers from our code, it goes into the print driver, we can see it being 'printed' in the Print Queue for the printer, but the printer never prints the paper.   The three (3) printers are hooked up by network and USB to different PCs.   I have tried the code from Serve 2008 R2,  Windows XP,  Windows 10 1709,  and Windows 7 Enterprise.  All respond the same now.    I do have one printer the code still works on, a Lexmark E260d.   The code works fine sending to the printer (USB port) on my machine.   But the same code to any of the M506 no go.   Checked the queue, the size of the file in the queue is the exact size of the file on disk.     

They only way I can get a file to print on any of the printers in the network is to issue a 

  copy    <file>     \\Machine\Share   for the specific printer.   This works.      

Normal Windows Print (an application doing GDI stuff) like Word, Excel, etc. work fine printing to the printers.

The simple code to just print a provided file to a printer and a sample Print file are on this DropBox Link:

https://www.dropbox.com/sh/cokbckx3i4a0ec8/AABYHS8eTDBQD00OvD2J8QMga?dl=0

Would appreciate any help.

Thanks!

[dansdaduk]

I don't know why your printer(s) fail to print your raw PCL documents, so just a few comments:

First regarding the PCL 'raw' data:

• The raw PCL (the file, together with several analyses, is contained in the attached .zip file) is relatively straightforward, although it is not what would be considered a 'complete' PCL print job.

• For example, it is not encapsulated within Universal Exit Language escape sequences (with the relevant PJL ENTER LANGUAGE command after the initial UEL and before the 'printer reset' escape sequence); this may be relevant if the 'personality' on the printer is set to something other than PCL or Auto, although that then doesn't explain why your 'copy' mechanism subsequently works! 

• It does not set various attributes, hence will default to user-default settings on the printer; for example, no page size is selected, nor is any particular font selected; however, I don't think that these omissions would affect whether or not the job would print (it prints, in simplex, on a couple of my local printers (LaserJet M475dn, PageWide 556), albeit with the bottom of the pages missing (I use A4 paper - I suspect that you are assuming Letter size)).

As regards the (Windows) API calls to print the raw data, the calls (at a cursory glance) appear to be valid, although:

• The initial 'open' uses the OpenPrinterA interface; I'm not that familiar with this, but i think that it is just the ANSI variant of OpenPrinter; with raw data, I doubt that it makes any difference.

• Similarly, the document is started with StartDocPrinterA rather than StartDocPrinter.

• But is quite difficult to diagnose an issue with someone else's code. 

You could try using the PRN File Print tool in the PCL Paraphernalia application (available via https://www.pclparaphernalia.eu ) to send the content of your PCL file to the target device, to see if that also fails like your mechanism, or not; the target device can be defined in one of two ways:

• As a 'network' printer, in which case the data is sent via the TCP/IP 'socket' mechanism (socket.Connect, socket.Send, socket.Close) which is (I think) essentially the port 9100 mechanism.

• As a 'Windows' printer, in which case the data is sent via the same mechanism (OpenPrinter, StartDocPrinter, StartPagePrinter, WritePrinter, EndPagePrinter, EndDocPrinter, ClosePrinter) which (I think) you are using.

[Jim_Asman]

Your file prints as expected with my pcl viewers and printers.

Have you done a checksum on the disk file compared to a checksum on the spool file?

[dansdaduk]

I've been notified of an issue where PCL Parapahernalia doesn't work with a USB-connected Laserjet Pro MFP M180n printer.

The application doesn't fail, or produce any error message, but the Windows Event Viewer shows Event 1000 messages associated with "... Faulting application name: printfilterpipelinesvc.exe".

I've no real idea what this is, or how to find out why it fails.

With a USB-connection, the PCL Paraphernalia application is using the same "standard Windows RawPrint solution" as you, so perhaps there is some common problem, with newer HP devices, or drivers, which causes them to no longer support this (Microsoft-documented) mechanism?

[dansdaduk · Accepted solution]

The problem may be associated with use of "v4 printer model" drivers (although I haven't had time to investigate this yet).

With the older "v3 printer model" drivers, 'passthrough' of raw (printer-specific) data is achieved with the 'raw print data' solution by specifying a datatype of RAW.

But with the newer (XPS-based) "v4 printer model" drivers, 'passthrough' appears to require use of a datatype of XPS_PASS.

[Joe_Terp]

This solution worked perfectly.   I tried all different tricks with the RAW and when using the XPS_PASS everything worked fine.   Now trying to get the customer to let be update some old solutions to use the new format for the driver to work with.