Printing via Reflection for HP

[Williamwwk]

I have made a migration from a HP-UX server which have the same OS version HP-UX B.11.11. I access the server using Reflection for HP, my software prints to output /dev/tty(which is the terminal) and Reflection gets the output and redirects it to windows printer queue. The printing is directed to EPSON dot-matrix printers 1600K3/K4, 1900K, etc(all these printers have built-in chinese simplified fonts). The output comes out fine when using Reflection to access the old server and the software, but when using the same Reflection to access the new server and the software, the printing is shrunk, the number of lines are the same but the output is compacted to a smaller size. All the products and patches which the old server has, the new one has too. My impression is when the printing function is called, the env variable COLUMNS is somehow changed to a bigger number affecting the screen output, but thats only a guess and I can't find where it is modified in the process. The print shrinking affects only the printers which have built-in chinese fonts, both outputs which contains simplified chinese and english are both shrunk. I have attached a sample where I cut and pasted the two outputs into one picute.I would appreciate any suggestions, I don't know where to start to debug this problem.

[Bill Hassell · Accepted solution]

As you can see, the fonts in the two images are different. Unfortunately, Xwindows (actually, the Reflection/X emulator) will not reject the display of font that wasn't intended and is attempting a best match, Now it's important to separate a custom Xwindow application program from a terminal emulator such as dtterm or xterm running on the HP-UX server.

The COLUMNS and LINES variables are normally set during a normal login, but in Xwindows, the normal /etc/profile and .profile files are not run. Terminal-based applications require that the emulator be properly identified. This is done with the ttytype program. So if this is a terminal window, run the command:

ttytype -s

on each server. If the results are the same, then the Reflection/X emulator needs to choose an HP-UX font server for the latest fonts. This would also be true for application windows (non-terminals). If the LINES/COLUMNS are different between the two servers, you need to set the same geometry for each terminal window. Remember that the terminal window did not originate on the PC, it is created and drawn by the remote HP-UX machine. Reflection/X is a passive program that just waits to be told what to do by the remote systems. You can configure Reflection/X to handle some Xwindow features like fonts as well as actions to take when font features mismatch.

[Williamwwk]

Thank you very much for replying Bill. I have checked the env variable with ttytype -s and found them are exactly the same. Your suggestion is to choose an HP-UX font server for the lastest font, but the entire process doesn't involve Xwindows at all. The connection is made through telnet and does not use Xwindow(Reflection for HP is not for Xwindows like Reflection X). It just uses the command line interface like using the command prompt of windows for telnet, and the application itself is just a text character based application. Does using the font server helps in this situation too?

[VIKAS AGRAWAL]

Hi William ,

Your problem looks like to be CPI & LPI Setting problem, U can solve the issue in the following way.

U have to select Model for printer ESCP
go to directory /usr/lib/lp/model

one file will be there called ESCP just change the value of LPI & CPI , or secound method can be just find the name of your printer, there will be 2 files of your printer name , one will be the copy of ESCP just made changes there, or u can ftp the same driver file from the old server

[Bill Hassell]

Reflection for HP simplifies the task quite a bit. No, a font server is not used in Reflection for HP so this is not a concern. Now the printing process needs to be characterized. In R/HP, you can print the screen with the standard Windows print menu item with R/HP with choices like selected text, visible window content, or entire screen memory. In this case, HP-UX is not involved in printing at all, your PC is doing the work. In that case, R/HP should produce the same results on any telnet connection with the caveat that the screen character space is the same (ie, 80x24). R/HP will change the printer font to fit on the paper in case the screen is denser (ie, 132x48).

However, since your printing is performed as an application task (you select printing using the program), then HP-UX is not involved in the actual printing, that is, the printer is connected to the PC. So the assumption is that the same characters are sent by the program to R/HP for pass-thru printing. And I'm also assuming that the same R/HP settings file is used for both servers. In looking at R/HP settings for printing (-> Setup -> View Settings, then search for print in the Search box), there are a few options you might look at:

Bypass Printer Driver
Printer Auto Row Size
Printer Columns Tied To Display
Printer Fit Font to Page
Use Default Printer Font

Now don't change multiple items as it will get complicated to find the right setting. I would try Fit To Page, or Use Default Printer Font. My guess is that the new server has a different version of the Curses library and that the width of the screen text is slightly wider. There have been some subtle Curses library changes in the past that may change the line width (perhaps inserting a space). Since this is an Epson printer and the Windows printer driver is being told what to do by R/HP, it looks like the actual text sent to the printer has been preceeded by a font width directive.

There may be other patch differences between the HP-UX systems that could cause this condition. You might try printing to a file and compare (carefully) the two servers' results. Look for inserted spaces and also trailing spaces. For instance, the second server may send an extra space in front of every line which makes the line longer and R/HP compensates by reducing the font size for the Epson.

R/HP has a wide variety of controls for printing and for tightly controlled applications, the defaults will usually work as expected. The key is that many applicatgions depend on OS libraries which can create subtle differences when patched. Turning off the R/HP automatic scaling options should help.

[Williamwwk]

Thanks again Bill for your opinion, I was thinking towards this direction too. Here are some more detailed information about this issue I would like you to know. The output job is sent by the application which contains the printer control information and the text to be displayed, the outputs are then directed to /dev/tty which is the R/HP, the terminal is set to Bypass printer driver and the column size is 80, other settings are default. The print tests were made with the same terminal and of course with the same configurations, the only thing that were changed are the servers.
To verify the outputs, I have printed some samples from both servers. Surprisingly, both samples were exact the same. This compression printing phenomenon seems to affect only the dot matrix EPSON printers with chinese fonts built-in. If the cuses library or patches were affecting the line spacing, then it should affect all the printing outputs, right? Anyway, I will try to search for the different patches of servers and see if they have any side-effects on the printer jobs.
By the way, do you know any method to capture the complete output(including the printing, line spacing, etc control commands) to the terminal so that I could inspect any difference between the servers?

[Bill Hassell]

Yes,you can direct the actual print job to a file on the PC. Configure your current printer using:File -> Print Setup and check the box: Print to file. Now this will show exactly what was sent by the HP-UX system. HP-UX code does not know anything about page widths or fonts, at least not automatically. Anything inserted into the print stream will be saved in the file. You'll need a program that can show the control characters.

An alternative to saving the output to a file is to use the R/HP Display Functions feature. Display Functions is turned on with ALT+M (Alt key plus letter M) then press f7 to enable this feature. Now, every control character will be shown on the screen. Once you enable this feature, normal text processing (like cursor position, video enhancements, etc) are ignored and the characters simply displayed on the screen. So if you trigger a print task (after enabling Display Functions), the text will be dumped to the screen and you can then use the File->Print button to copy the screen contents to a printer. The special control characters will be printed using a special font.

[Bill Hassell]

One comment about the attached GIF file: The first display shows a tall serif font, similar to TimesRoman, but the second example shows a sans serif font similar to Arial. So this isn't a simple adjustment of the page width, it is a font change triggered in the printer. So there is definitely a code change being sent by HP-UX. I had forgotten that the printout included Chinese characters which means that there are numerous control characters imbedded on each line. The difference between the server output may be related to the current LANG variable and/or patches related to languages.