× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.