Turning a PJL to a PCL macro

[dansdaduk]

... and here is a modified file macro_x01.pcl (and analysis) where the raster image is encapsulated within a macro (identifier = 2) which is 'executed' at the start of the simple PCL 'second half'.

As expected, the only difference in output is that both the text and the image are now on the same sheet.

[dansdaduk]

... and just a few more comments and/or questions:

• The raster image in the supplied macro.pcl file supplied by @Reed_I shows a  a small 'sample' signature on a much larger background of vertical and horizontal lines.
• I've no idea what the purpose of these lines is; can we assume that this is not the 'garbage' referred to (I think we can , because it is not "pages of garbage").

So, we assume that the "pages of garbage" only occurs if:

• The raster image is encapsulated within macro definition escape sequences;
• It is 'sent' separately to the device;
• The subsequent simple print job references this macro (by identifier), and (attempts to) 'execute' it.

If so, I'd need to see copies of both of the files actually used.

Other thoughts:

• I've always been a bit 'wary' of the '-o raw' option; use of this to pass through data to the target printer (presumably?) relies on the model script supporting the option.
• Supposing it doesn't? But then, why would the inline code raster image print?
• With modern LaserJet (and business OfficeJet) devices, you can't rely on downloaded PCL macros (or fonts) to remain in RAM until explicitly deleted , or until the device is powered down (when everthing in RAM is lost).
• This is because (I think) incoming print jobs using a different Page Description Language (PCL XL or PostScript) will clear the current PDL 'work space' in RAM.

[Jim_Asman]

---

@dansdaduk wrote:

... and just a few more comments and/or questions:

• The raster image in the supplied macro.pcl file supplied by @Reed_I shows a  a small 'sample' signature on a much larger background of vertical and horizontal lines.
• I've no idea what the purpose of these lines is; can we assume that this is not the 'garbage' referred to (I think we can , because it is not "pages of garbage").

 The lines we see are from the mkpcl demo. It would make more sense if the scan had been cropped to the

signature.

So, we assume that the "pages of garbage" only occurs if:

• The raster image is encapsulated within macro definition escape sequences;
• It is 'sent' separately to the device;
• The subsequent simple print job references this macro (by identifier), and (attempts to) 'execute' it.

If so, I'd need to see copies of both of the files actually used.

Certainly there is some, as yet unknown, agent that is corrupting the raster data.

Other thoughts:

• I've always been a bit 'wary' of the '-o raw' option; use of this to pass through data to the target printer (presumably?) relies on the model script supporting the option.
• Supposing it doesn't? But then, why would the inline code raster image print?
• With modern LaserJet (and business OfficeJet) devices, you can't rely on downloaded PCL macros (or fonts) to remain in RAM until explicitly deleted , or until the device is powered down (when everthing in RAM is lost).
• This is because (I think) incoming print jobs using a different Page Description Language (PCL XL or PostScript) will clear the current PDL 'work space' in RAM.

I think it unlikely that any model script that does not understand "-o raw" is cooking the output, thus eliminating the problem to begin with. The cooked mode is injecting a FF after a specified number of LFs, and this is what can give you pages of "garbage". Quite likely there are hundreds of LFs in any raster image. One injected byte into the middle of raster data will produce the pages of garbage.

Of course you can't rely on a downloaded macro to have a long life, and none of it is an issue if you can insert the macro file whenever you want. If you are calling or overlaying the macro any number of times in the print run, you ideally will ony download the macro ONCE for the entire print run. A **bleep** of checks for example.

@Once @Reed_I can sucesssfully print the sigs.pcl file, then we can figure out the most "tidy" way to get the raster data to the printer unmolested

---

[Reed_I]

Gentlemen,

sig.pcl prints fine.  The form prints fine too.  The problem is when I make sig.pcl a macro.  As soon as I make it a macro and call it to print, it produces junk.  Someone earlier said that the issue could be mixing PCL5 code with PCL6 code.  Could that be it?

Thank you,

Reed

[Jim_Asman]

---

@Reed_I wrote:

Gentlemen,

sig.pcl prints fine.  The form prints fine too.  The problem is when I make sig.pcl a macro.  As soon as I make it a macro and call it to print, it produces junk.  Someone earlier said that the issue could be mixing PCL5 code with PCL6 code.  Could that be it?

Reed_I,

sigs.pcl IS a macro that is then called 4 times giving 4 signatures on the sheet. The macro by itself was in the hancock.mac file while the macro calls were in the hancock.txt file. BOTH files were combined to create sigs.pcl

You cannot use a PCL5 macro on a PCL6 job, period!  As I suggested previously, see if you can find a PCL5 driver for your printer; otherwise, you can probably give up the idea of using a macro for the signature. Also, describe briefly the entire process, particularly what application is behind all this. You want the scan of the signature to contain ONLY the signature and you position it on the page with x,y coordinates. It looks as though you were using a scan of the full page to locate the signature. That is the VERY long way around the block.

Some programs, Microsoft Word for example, provide a mechanism whereby you can insert raw pcl code into the document. Ideal of course for calling a macro, but it does presuppose the macro is resident in the printer.

---

[Reed_I]

Sorry Jim!  I had misunderstood you earlier...Yes, SIGS.PCL prints fine.  I sent HANCOCK.MAC to the printer, then sent SIGS.PCL

[Reed_I]

Sorry Jim!  I had misunderstood you earlier...Yes, SIGS.PCL prints fine.  I sent HANCOCK.MAC to the printer, then sent SIGS.PCL to the printer and the 4 John Hancock signatures printed.

And you are correct...I am not going to send a full page of the signature as a macro to the printer.  That was only to test it.  I was hoping that the full page with the signature would print on top of the form.  Then, I would figure it's going to work for me, purchase the product, make a small version of the signature, etc...

Reed

[dansdaduk]

As sigs.pcl contains what is in Hancock.mac, that test is not really telling us much.

What happens if you send the contents of Hancock.mac to the printer, and then send the contents of Hancock.txt to the printer?

[Reed_I]

I see!  I sent Hancock.mac and then hancock.txt to the printer and it printed the 4 signatures.

[dansdaduk]

So we've finally established that a macro can be stored in RAM, and then referenced in a subsequent PCL print job.

We've now got to work out just what it is that you are doing differently, compared to this simple sample, which causes garbage.

I think that you need to list EXACTLY what commands you are using, and the exact content of the files you are referencing, when your 'print'' results in 'garbage'.