Use PCL for OfficeJet Pro 8210

[ClausSporer]

I've bought a new printer hp OfficeJet Pro 8210. 

I'm software developer and I want to use this printer for an embedded device, where I use a PCL-compatible driver. 

The device works well with a current printer hp LaserJet Pro M203dn and with an older printer hp Deskjet 5940. 

But, with the new hp OfficeJet Pro 8210 I have problems: 

The text and grafics seem to be ok, but some additional horizontal lines are printed. The horizontal lines start from a character with descender, e.g. "p" or "g" or "j". The line is printed like an underline (I could post an example page, if useful). 

I think that my device and the PCL-driver are ok, because I have two printers, that work correctly. 

So, I suppose, that maybe the error could be in the PCL- protocol of the hp OfficeJet 8210 printer? 

Thank you in advance! 

[dansdaduk]

>> ... some additional horizontal lines are printed. The horizontal lines start from a character with descender, e.g. "p" or "g" or "j". The line is printed like an underline ...

>> ... (I could post an example page, if useful) ...

As the old saying (roughly) goes, "... pictures are (often) worth a thousand words ...".

What would also be useful is a sanitised-data (i.e. redacted) sample of the data & PCL escape sequences which you send to the device.

As an aside:

• According to their datasheets, the LaserJet Pro M203dn and the OfficeJet Pro 8210 printers both support the PCL5 Page Description Language (as well as PCL6 (a.k.a. PCL XL), etc.).
• But the DeskJet 5940 (a photo printer) only supports PCL3 GUI or PCL3 Enhanced (depending on which datasheet you look at); it does not support PCL5.

Unlike PCL5, detailed specifications of these extended PCL3 languages do not appear to be published outside of HP.

As far as I can tell, they support a few of the basic PCL escape sequences, but most of the rendering is performed using (proprietary)  compressed raster image mechanisms.

So I'm a little bit surprised that your 'PCL' works OK with the DeskJet printer.

[ClausSporer]

Thanks for your quick reply! 

We're doing mostly plain text and only simple grafics for laboratory measurement. This could be the reason why PCL-3 GUI works. 

Yes, I also don't understand why LaserJet Pro M203dn is working and OfficeJet Pro 8210 is not. They should have the same PCL protocol... 

We also have another measurement device with a very similar PCL-driver. This device is doing well with both printers. 

Is there a possibility to read out the PCL escape sequences, that arrive at the printer? So, maybe I could send it to you? 

Attached please find our data (ok and error version): 

[dansdaduk]

I'm not sure what to conclude from your images (which have just become visible in the past few minutes - posted images may take some hours before they are "approved" for viewing).

In the 'error' cases, it looks as if some (although not all) of the text has been written with underlining switched on.

>> ... Is there a possibility to read out the PCL escape sequences, that arrive at the printer? ...

With standard Windows printer drivers, most of them provide a "print to file" option in the Print dialogue, which enables the generated print job to be 'captured' to a nominated .prn file.

I don't know enough about your operating system (shown as "Other"), or your "drivers", to guess as to whether or not this is applicable in your case.

Of course, such a capture does not take into account any alteration or corruption of the print stream that could theoretically take place between leaving the driver and arriving at the printer - but this is perhaps not very likely?

>> ... So, maybe I could send it to you?  ...

If you can manage to capture a print job to a file, you could analyse the file yourself, using the PRN File Analyse tool in the PCL Paraphernalia application (available via http://www.pclparaphernalia.eu).

Note that this is a Windows .Net application.

... or you could send the file to me via the support mailbox 'at' pclparaphernalia.eu

[ClausSporer]

My operating system is Windows Embedded CE 6.0 R3. It's used in an embedded device, a "mini-PC". The driver is a file called "pcl.dll". It is written by Microsoft, I think. If you have a hp-version of this driver, please tell me. 

The strange thing is, that both, error and ok case, is done by the same "pcl.dll"-driver. With the LaserJet Pro M203dn it's working, with the OfficeJet Pro 8210 it's not. Both printers support PCL-5c and PCL-6, according to the data sheet. What is the difference of "LaserJet-PCL" and "OfficeJet-PCL"? Could you maybe give me a list of 2 or 3 inkjet printers that support the "LaserJet-PCL"? 

Thank you for the hints about the prn-file. I'll check it. 

[ClausSporer]

Or maybe could you tell me 2 or 3 printers, that support the same tyoe of PCL-3GUI as the Deskjet 5940 does? This printer is ok with my driver. I could do a test with these printers.

The point is: I only need printers which our customers could use in combination wih our mesurement devices.

So, if OfficeJet Pro 8210 is not working, I could take another one...

Thank you in advance! 

[dansdaduk]

>> ... What is the difference of "LaserJet-PCL" and "OfficeJet-PCL"? ...

Theoretically, there should be no difference between printers (whether LaserJet or OfficeJet) which support one of the PCL5 dialects (PCL5e for monochrome devices, PCL5c for colour devices).

Note that no PCL printers are likely to support every PCL sequence; some sequences are only supported on higher-end devices, whilst other (older) sequences which were supported years ago may now be considered obsolete and not supported on modern devices.

(Most) PCL5 devices should just ignore sequences which they do not recognise/support.

One situation where this may cause unwanted extra output is is the unrecogonised sequence is one of the (relatively few) which are followed by one or more bytes of binary data.

[dansdaduk]

Edit: please ignore this - I updated the wrong question here. 

>> ... No Windows printer driver, except Generic Text Only, will accept ASCII data ...

I have to disagree with this statement.

Windows printer instances provide two main functions:

•  To provide a means of converting objects in a source document into equivalent printer-format objects in the Page Description Language generated by the driver (and hopefully supported by the target printer!). This is regardless of wheher the 'source objects' are plain text characters in a text file, or formatted text or images in (e.g.) a Word document, or images in a Photoshop document, etc.

• To define how the generated print stream is to be 'transported' to the target device; this is as specified by the 'port' definition.

As far as I'm aware, with DOS applications (which typically output via the LPT1: (pseudo-)device):

• The 'net use' mechanism merely redirects the LPT1: traffic to the target device via the port definited by the Windows printer instance.

• The conversion/formatting part of the driver is not invoked.

[dansdaduk]

I'd still like to see a 'captured' print stream to see just what is being sent to the target printer.

Analysis of such a captured print job would perhaps allow us to determine whether the problem is likely to be:

• With the printer itself - a fault in the (PCL) language interpreter in the firmware.

• With the driver - generating sequences which are perhaps ignored/not supported by the LaserJet device, but acted upon by the OfficeJet device.

[ClausSporer]

Thanks a lot for your support. 

I'm trying to get a "captured" print stream  and will provide it to you.