When I print a line on a PCL5 printer, that is over 132 colums long, it prints fine, but when I do the same on a PCL6 printer, it prints a blank line afterward
I initialize the printer with
~E~&l2A~&l1O~&l2S~&l5.2602
then print a line that is 8.3" long, but fits well on the 11" wide paper.
On an HP PCL6 printer, it skips a line after any line 133 or more characters long (but does print the whole line).
On a PCL5 printer, it prints the whole line, and does not skip a blank line.
I do not use any print driver, as I am printing from an IBM Mainframe, not Windows.
~E~&l2A~&l1O~&l2S~&l5.2602
then print a line that is 8.3" long, but fits well on the 11" wide paper.
On an HP PCL6 printer, it skips a line after any line 133 or more characters long (but does print the whole line).
On a PCL5 printer, it prints the whole line, and does not skip a blank line.
I do not use any print driver, as I am printing from an IBM Mainframe, not Windows.
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
The term PCL6 has different meanings, depending on where it is used; it was originally used in marketing documents, where the distinction was made between:
With modern devices, reference to a PCL6 printer will generally mean that both of these PDLs will be supported, but reference to a PCL6 driver usually means a PCL XL driver.
The PCL XL PDL does not understand plain ASCII text data; as both printers print your data, then they must both support PCL5.
You've provided a snippet of PCL5 which you are using as an initialisation sequence; an interpretation of this is:
But just what is the format of the line that you subsequently print? Is it terminated by a LineFeed control -code character, or CarriageReturn + LineFeed pair, or what?
The sequences you give are only a subset of the initialisation that would normally be done using a Windows (or *n*x CUPS) driver.
In particular, perhaps you need to include a 'Line Termination' escape sequence, to define how CarriageReturn, LineFeed and FormFeed control-code characters should be treated (there may be different defaults set on the two printers); the options are:
PCL6 standard - supports PCL5 Page Description Language.
PCL6 enhanced - supports PCL XL PDL.
With modern devices, reference to a PCL6 printer will generally mean that both of these PDLs will be supported, but reference to a PCL6 driver usually means a PCL XL driver.
The PCL XL PDL does not understand plain ASCII text data; as both printers print your data, then they must both support PCL5.
You've provided a snippet of PCL5 which you are using as an initialisation sequence; an interpretation of this is:
<Esc>E Printer Reset
<Esc>&l2A Page Size: Letter
<Esc>&l1O Orientation: Landscape
<Esc>&l2S Simplex/Duplex: Duplex Short-Edge Bind
<Esc>&l5.2602739726C Vertical Motion Index (5.2602739726/48 inches)
<Esc>&l3E Top Margin (3 lines)
<Esc>(s16.6H Primary Font: Pitch (16.6 characters per inch)
<Esc>&s1C End-of-Line Wrap: Disable
But just what is the format of the line that you subsequently print? Is it terminated by a LineFeed control -code character, or CarriageReturn + LineFeed pair, or what?
The sequences you give are only a subset of the initialisation that would normally be done using a Windows (or *n*x CUPS) driver.
In particular, perhaps you need to include a 'Line Termination' escape sequence, to define how CarriageReturn, LineFeed and FormFeed control-code characters should be treated (there may be different defaults set on the two printers); the options are:
<Esc>&k0G Line Termination: CR=CR, LF=LF, FF=FF
<Esc>&k1G Line Termination: CR=CR+LF, LF=LF, FF=FF
<Esc>&k2G Line Termination: CR=CR, LF=CR+LF, FF=CR+FF
<Esc>&k3G Line Termination: CR=CR+LF, LF=CR+LF, FF=CR+FF
If you use a PCL5 and PCL6 driver on the same printer, does it then print differently? If it doesn't, then the problem is caused by differences in printer settings between your PCL5 and PCL6 printers.
From the mainframe, there are no printer drivers, it is all sent to the printer RAW. For CR/LF options, the EBCDIC character set does not contain such things, so it must be applied as part of the translate table to ASCII, as it leaves the mainframe. The way it works for all other lines of text, at the end of each record, it does a CR/LF of some fashion that looks perfect. If I send 140 characters, the printer prints all 140 characters, but then leaves a blank line, but only on the one printer.
I tried all 4 Line Termination options, and two of them (0G and 2G) left a blank line as before, but the other two (1G and 3G) left blank lines between every line (double spaced), and extra blank lines after the long lines.
I checked further into the Translate table, and found out that the one that works uses a different translate table than the one that doesn't work. I had them switched and now it works. It is something very odd in the translate table that was causing it, nothing that was lacking in the initialization sequences.
Thanks for your help.
I tried all 4 Line Termination options, and two of them (0G and 2G) left a blank line as before, but the other two (1G and 3G) left blank lines between every line (double spaced), and extra blank lines after the long lines.
I checked further into the Translate table, and found out that the one that works uses a different translate table than the one that doesn't work. I had them switched and now it works. It is something very odd in the translate table that was causing it, nothing that was lacking in the initialization sequences.
Thanks for your help.
His suggestion had me look into the CR/LF options, which led me to describe the mainframe to printer process, which led to the translate table, where the problem was found.
I'm pleased that:
You've resolved the problem.
You've briefly explained the resolution, since (after I posted my earlier reply), I couldn't really see how the "Line Termination" value would affect only long lines!
Mention of EBCDIC brought back some memories (although for me it was using ICL VME/B mainframes, rather than those from IBM); I think that the character set included the NewLine control code at hex(15).
Premium Content
You need an Expert Office subscription to comment.Start Free Trial