Correction !!! on Special char printing (fwd) ✗ Answered: red (solid confidence) — This message forwards the poster's own original question in full (embedded printer escape sequences breaking 4GL PRINT COLUMN alignment); no reply is captured in the archive.

Advisory only.

It might bve a mail glitch, but the copy I got back of my own message shows a line missing in the text I prepared. There should be two command lines in the example herein. I'll say it here and try to correct it in the text below. print column 11, String_1, column 71, String_2 ---------- Forwarded message ---------- Date: Thu, 13 Jan 1994 12:42:00 -700 (MST) From: Con Woodall <cwoodall@vth1.vth.colostate.edu> To: informix-list@rmy.emory.edu Subject: Special char printing 4gl report writing under unix-special printing to HP deskjet 500 (or probably any other printer). A brief appeal for some expertise from someone who has tried embedding printer escape sequences into character strings for special print functions. Without all the gory details, we have a problem controlling informix print output if we have embedded escape sequences in the string being printed. For example, String_1 has embedded escape sequences to provide for printing exponentiation in the form of reduced size numerals raised above the line. There are four sequences, one for the small numerals, one for the elevation, and after the numberal itself, one sequence for normal numerals and one for orientation back to the normal line elevation. String_1 is fifty characters in length and the information and escape sequences occupy 41 spaces. String_2 has normal text. Using 4gl output commands of print column 11, String 1, column 71, String_2 produces the correct information but String_2 begins at column 46. This is also true if "clipped" is indicated after the first command. Further examination of the print file shows that the file was created without consideration for the fact that unix will not acually print those escape sequences, but act on them. There is no reason for informix printing to know otherwise. Has anyone dealt with and overcome this problem. One possibility seems to be analyzing string_length and appending extra space to the "real" data field to make up for the characters that will not be printed. That's becomes rather complicated and requires that you give away a lot of line space on reports. Any ideas. -- Con Woodall Colorado St. U.; Veterinary Teaching Hospital; Ft. Collins CO 80523; 303-491-1244 FAX 303-491-4414 cwoodall@vth1.vth.colostate.edu Opinions not nec. employer's, but mine might be right. Then again... --