Have you tried it on a different model of printer, and do you get the same issue? If you suspect a firmware issue, testing on a different model of printer is a good test to do. If it works fine on another PostScript printer, it could very well be a printer issue.

Any reason why you can't use Optimized PostScript? Is it a printer-resident form, and you send data directly to the printer? Are you using PlanetPress Workflow at all?

it works on every model of HP printer and Canon copier/printer that we have in the company, this is a new model HP printer that we were looking to use. Currently all of our forms are printer resident (printer-centric) with a trigger that precedes the data sent to the printer. We are not using Planet Press Workflow.

If it works on every other models of printers, including other HPs, then it's most likely some kind of firmware issue, or postscript interpreter issue. It may be worth calling HP, and ask them why all their models works except this one, and what's different.

Chuck,

What emulation are you using?
Have you tried testing this printer with a basic Form, using basic text data? This might give us (and HP) a clue as to what's causing the issue.

line printer emulation. I will try and set up a basic form test. forms print fine from the design app, its when they are sent from our custom application we get the extra page.

thanks
chuckl

Sounds like each line in the file ends with CR instead of CRLF.
PlanetPress can handle those just fine, but when you send the file directly to the printer, it sees it as one long line.

That may be something you can control on the printer itself, though. You might want to ask HP if there's an option to automatically interpret CR characters as CRLF pairs.

chuckl,

I know you aren't using Workflow right now, and not sure if you've got a license for it, but we have a "Binary Filter" plugin available for it here:

http://www.objectiflune.com/OL/en-CA/Download/ResourceCenter/PlanetPressSuite/Plugin.aspx#1

It's an advanced filter that can, amongst other things, replace lonely CR character by CRLF. Perhaps you could try it, just to see if it works. At the very least, it would confirm a problem with the data.

Regards,
Raphaël Lalonde Lefebvre

I have performed the most basic test I can which is a form with no data, just the trigger and I still get the extra page. The trigger looks like this:

%!PS-Adobe' || chr(13) || '(%disk0%Form0040) run Form0040' || chr(13) || chr(10))

Are all of the newer model HP printers going to react this way? Does anyone know of any newer HP Laserjet models that are working in a printer-centric environment? I'm running out of options.

chuckl

chuckl,

I don't have any specific model to recommend you, but if your printer supports postscript and has a hard disk, it should support printer-resident forms.

Looking at your trigger, however, it appears you do have a lonely CR character, as you are only using chr(13), and not chr(13) + chr(10). Have you tried replacing it with a CRLF instead, chr(13) || chr(10)? This might work better.

Regards,
Raphaël Lalonde Lefebvre

I modified the trigger to include the LF after the lone CR with no luck. We have opened a ticket with HP and hope to hear back from them soon. I'm still open to any and all suggestions.

thanks for all help
chuckl