Tru64 to HP-UX: print formatting

[Matt Hearn]

Hey all, we're migrating a fairly sizable application from Tru64 to HP-UX 11.23, and we've hit a bit of a brick wall. On Tru64, the application folks are able to print their stuff with special formatting using the "-l" option that lp provides on that OS. HP-UX doesn't have a -l option, so it's just printing out the special characters as it sees them.

I'm trying to determine if there's anything I can do to get HP-UX to actually format the data (with fonts, italics, bolds, etc.) the way they need it. There's some indication I may be able to use "filters", but 1) I don't know how to do that and 2) I don't believe any filters are in use on our Tru64 box. Apparently the vendor for the application has made this work, and other customers of theirs have as well, on HP-UX; we're trying to determine how. Is there some kind of custom interface script I need to find?

Thanks!

[David Bellamy]

look at the -o option in HPUX and also do a man on the pr command

[OldSchool]

it appears that the Tru64 system uses "printcap", something which HP-UX doesn't know about.

The migration tool you noted in your other thread appears to handle the conversion (build the filter?) for you...now if you could only get your hands on it....

[Bill Hassell]

HP-UX uses SysV print spooler whereas printcap belongs to the BSD school of thought (so to speak...) As such, special characters in the data stream are sent to the printer. Each printer will have a printer script which typically has only one filter, the ux2dos converter that adds CR to every LF (the Unix end of line character). You can certainly create a filter and insert it into the printer scripts. There are essentially 2 major printer languages in the world, PCL (which is ASCII with extra features) and Postscript (which is an ASCII page definition language). For completeness, EBCDIC is still used (in dark corners of mainframe print rooms) but is not a formatting language.

There are indeed filters on the Tru64 box since something has to interpret the embedded codes and then output the required codes for the printer. Windows does this by using an intermediate printer metalanguage which is then interpreted by printer drivers. This allows for the same application to remain printer neutral and the OS takes care of the myriad of printers. So for HP-UX, you would take all the formatting codes, pick a target printer and perform the translation within the printer script. Simple matter of scripting (big smiley)

[Matt Hearn]

What I THINK I have is a situation wherein the jobs are being sent from the Tru64 box unfiltered to the Windows print server. My understanding was that the Windows print server was responsible for handling the escape codes that control font, color, etc. I can't find any active filters in Tru64, so it's gotta be happening on the Windows side, right? Why is that working in Tru64 but not HP-UX?

Thanks!

[OldSchool]

"My understanding was that the Windows print server was responsible for handling the escape codes that control font, color, etc. I can't find any active filters in Tru64..."

In that case, I would've thought sending a plain file to the windows box would do the same.

Have you tried configure this a "remote" printer (using SAM) as opposed to a network printer. SAM -> Printers & Plotters -> LP Spooler -> Printers & Plotters -> Actions -> Add Remote Printer.

Printer name will be the name you want to use on the UNIX box...probably want to keep it the same as the printer on the Tru64 one. The you need the name (or IP might work???) of the Windows box and the Windows Printer Name to use...

If you can capture the print output of the program, you might try ftp'ing it direct to the printer just to see if the control codes embedded in the file work...

[Matt Hearn]

Here's an example of what they're sending; a bunch of data with escape sequences looking like this:

^[&k2G ^[&dD^[(s3BPrintout Test Page^[(s0B
^[&d@
^[&dD^[(s3B^[(s0B^[&d@



^[(s3B^[(s1SUsing Plain Text Printing^[(s0S^[
(s0B
^[(s3B^[(s1S^[(s0S^[(s0B


I can't even determine what language that is. PCL? Postscript? I'm lost.

[OldSchool]

Missed one thing....when / if you try setting up the remote printer, make sure the "BSD" selection is "on"

[OldSchool]

It very well could be the exact escape sequences to trigger a specific function on the particular type of printer. That's kind of what "printcap" was for.

given a printer type and known function, it would provide the control / escape codes to do that on the given device. These get added to the file and are "processed" by the printer as they are found in the data stream. It is somewhat like "termcap/terminfo" processing for terminals...ie. tput clear will clear any terminal it knows about, tput sgr0 resets defaults, and so on. The actual characters to provide those functions are provided by the terminal definition info, while "clear" and "sgr0" are function names.

or (and I've seen this a couple of times) the application itself writes the control codes...which is really ugly, as it can tie you to a particular type/model of printer.

[Matt Hearn]

I did indeed add it as a "Remote" printer; I can't add it as a "Network" printer because I don't have any of the JetDirect software. I've tried adding the printer as BSD and not BSD, no dice either way.

I've done some editing in the file so that it seems to send out the file as Postscript data, but now I'm getting the following:

PostScript Error Handler
Offending Command = &k2G
Error = nametype : undefined
Stack =

Any idea what this means?

[OldSchool]

when you set it up as remote / bsd, did you use "rmodel" as the model script, or something else? The reason I ask is it appears that the printer is in "postscript" mode, but it's seeing something else.

it looks like the output is actually PCL, but contains the postscript header. I based this on the following snippet from PCL5 / Laserjet4 model scripts:


# Definitions of functions used within this script

# PCL banner
do_banner()
{
echo "\033&k2G\c"
# Print the standard header


It appears that the printer definition for the queue you're using on the Windows side may be set up to default to postscript???

Maybe a printer can be defined over there that defaults to PCL????

[OldSchool]

or perhaps a "raw" print queue..pass thru only w/o formatting on the windows side.

note that the "rmodel" script, shouldn't pre-pend the postscript header, which is why I think that may be getting done when windows goes to process it

[OldSchool]

Okay, FWIW, the JetDirect software is available here:

http://h20180.www2.hp.com/apps/Lookup?h_query=jet+direct+printer+installer&h_tool=software&h_lang=en

If the printer has a JetDirect card in it (not just a network card), this is really worth installing, and it's free..

You never mentioned what kind of printer this was either...that would be helpful

[Bill Hassell · Accepted solution]

> ^[(s3B^[(s1S^[(s0S^[(s0B
>
> I can't even determine what language that is. PCL? Postscript? I'm lost.

This is indeed PCL, the standard ASCII-on-steroids language in use by the majority of printers in the world today. So this is not a special markup language from Tru64, it is just standard PCL code that was generated by an application. No filtering is necessary at all. And your Windows server did no filtering either. lpr/ldp remote printing in Wondows is just a pass through to the printer.

So termcap/printcap are meaningless...this code is ready to send to the printer. The only translation is to add CR to each Unix LF (end of line) character.

> PostScript Error Handler
> Offending Command = &k2G
> Error = nametype : undefined
> Stack =

OK, you have successfully added the printer to HP-UX and are sending text to the printer. But &k2G is a PCL codce and has no business being inside a Postscript job. Start by sending a plain-old-ASCII file to the printer using the lp command, something like this:

lp -dmyprn /etc/profile

If the result slides off the right edge of ther page, run this command:

ux2dos /etc/profile | lp -dmyprn

If that works OK, you're done. The printer is working.

Now the spool jobs on the Tru64 were generated by some application. That is where the code must be changed to match the printer. If this printer is not an HP PCL printer or a printer that supports PCL, then none of the special codes will work. Since there are several versions of PCL, your Tru64 app may have been creating codes for a LaserJet 4000 but your HP-UX printer is a LaserJet 3 and some of the codes will be meaningless.

To really, really complicate all this is the fact that many new printers (always "value priced") do not understand ASCII, PCL or Postscript. Instead, the printer is simply a dot printer and requires a stream of bits to form the image. That means the computer must have all the needed font definitions, graphics and raster conversion code to match this printer's language.

Now you are lucky because the one error message above (PostScript Error Handler) indicates that the printer understands plain ASCII, PCL and even the PostScript language. Now it is just a matter of matching your application to the current printer.

One last note: JetDirect software is useless unless the printer is an HP printer or uses an external HP JetDirect adapter card. This software is simply a connection tool, to take files from the HP-UX system and deliver the content to the printer using port 9100. Now if the printer is an HP printer and already has a built-in HP network card, then use the JetDirect software already installed on your system. To add the printer, simply run this command:

addqueue -q myprn_name -h 12.34.56.78 -t off -b off

where -h is the IP address of the printer. Now test it with: lp -dmyprn_name /etc/profile

Then delete the old remote Windows printer. You don't need (or want) a Windows box as a print server.

[Matt Hearn]

Thanks! The printers definitely do NOT have jetdirect boxes, so I'll stop working along those lines.

When last I talked to the users, they revealed that on Tru64, lp has a "-l" option that, according to "man lpr":

-l Prints control characters and suppresses page breaks.

I see that the interface script for the printers I've added on HPUX have the following similar option:

-l Use a filter that suppresses page breaks.

So it seems like all they have to do is run "lp -dprinter -ol file-they-wanna-print", right? They're testing that now, hopefully it'll work for them.

[Matt Hearn]

FOUND IT! The -ol option to lp will do what we need, BUT we had to make an adjustment to the interface file (the default rmodel one) to remove the "BSD" from the case statement. Specifically, we changed:

BSDl) # Files assume no page breaks.
BSDformat=-$ii
;;

to

l) # Files assume no page breaks.
BSDformat=-$ii
;;

Now they issue lp -dprinter -ol file and it works like a champeen. Thanks everyone for your replies!