Adam West wrote:
It looks like it can be done using *IPDS data stream not *AFPDS. The *AFPDS is much
easier, you just have to use the code BARCODE on a PRTF field and it does the
conversion, as we discussed this week.
OK, as Charles has said, there isn't much practical difference between
*IPDS and *AFPDS. I wish Paul Tykodi were weighing in on this; he's a
true guru. Let me spend a moment talking about printer datastreams from
a bits and bytes perspective.
Imagine yourself to be a printer, listening to the wire for work. When
characters come down the wire, you simply print them at 10CPI, 6LPI.
This is the simplest sort of printer. It hears a character and prints
it. But printers can do more complicated stuff than simply print
monospaced characters. Imagine you can print bold. How do you do that?
Well, the datastream reserves a special character that says 'here is a
command, don't print it!.' So you hear x'1b01' ABC x'0100' and you
recognise the 1b01 as the command to turn on bold mode, then you print
the ABC, then you recognise the command to turn bold mode off.
So, mixed in the data coming down the wire are commands to be
interpreted and characters to be printed. The commands tend to be
specific to a particular manufacturer, except where the printer can
emulate some other manufacturer, for instance an IBM printer may
implement HP PCL5 commands.
On our platform, the RPG program almost never sticks commands in the
datastream. That is, your O specs don't have any funny hex characters
in them; just the characters you want to print. The operating system
gets those characters from your program and wraps commands in where
needed. You can have the OS wrap several different languages: *SCS,
*IPDS and *AFPDS.
Of course, the printer needs to understand the language being used. If
your printer does not understand *IPDS commands, it will consider them
to be printable characters, and you'll have some truly strange stuff on
the paper. No matter whether you hand-code the *IPDS commands in your O
specs, or let the operating system do it for you via printer file
DEVTYPE(*IPDS), if the printer does not understand *IPDS, you can't use
*IPDS commands.
The Printronix manual with examples is here:
http://www.printronix.com/library/assets/public/tech-pubs/PTX_PRM_VGL_P7000_253099.pdf
I've never dealt specifically with a Printronix printer, and have almost
no experience trying to print graphics with HPT. If I had to do this,
I'd look to chapter 3 (page 170 is Code 128), and start writing a test
bed that implements the graphics commands there. After dealing with
ASCII data or conversion and possibly transparency, you'll soon see why
we've been spoilt by OS/400 printer support.
There *may* be a way to have host print transform interpret IPDS down to
Printronix graphics language but I can't help you there, never having
even thought about trying that before.
midrange.com
