Re: Special char printing
Posted in 1994
Topics: Connectivity: ESQL/C, 4GL & Embedded SQL
I'm slow on following this one up, but I think I have something I can add.... Live, from the scene, Con Woodall reports (Film at 11:00): > > 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. [ ... ] > 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. This is a problem inherent to printing with escape sequences with fixed columns in any programming environment, not just Informix. One way around it, as suggested is adding extra spaces. However, rather than analyzing the string length, a better way to go about doing it is simply determine which characters don't print. For example if by turning on an underline, everything prints two characters short, then you know that you have to compensate for those two characters for the remainder of the line. This gets to be a little more complex if you're doing a report that uses escape sequences on multiple models of printers. Using this particular method, I generally calculate a variable I call "offset", and then everytime I print a non-printing character, I increment the variable appropriately. From there, in making the designation for column, rather than saying: print column 11, variable_name, column 21, variable2_name I would do: print column 11, underscore_on, variable_name; let offset=offset+2 print column 21+offset, variable2_name and so forth. Again, it gets trickier if you're doing this for a report that will run on different models of printers, as the number of non-printing characters will vary. In this case, in calculating the offset, you have to figure it for each printer. A second method is to use the "absolute horizontal position" function, where you ignore the column number entirely, and use the appropriate escape sequence to get the precise point you want on the line. I found this to be particularly helpful for printing column-formatted output using a proportional-spaced font. Without it, I could never get my columns lined up right. In HP's PCL language, the necessary escape sequence would be: ASCII 27,"*pNNNX", .... where "NNN" is the number of 1/300ths of an inch you need. At 10 pitch each character is an even increment of 30; at 12 pitch, it's 25. Thus, to print at column position 4 at 12 pitch (that is, 3/12th of an inch from the left margin) it would be 100/300th of an inch, which would make the command look like: ASCII 27,"*p100X", .... This again is something that will vary from printer to printer. On the other hand, I've found it particularly useful for the purposes of printing column-format reports using a proportional-spaced font such as Times/Roman. The visual effect of the report is a big improvement over printing in a courier font. I've been successful using this method using both 4GL and ACE. Hope this helps. -- George Peavy | | He who dies with the most toys, INTERNET: george@lfa.wciu.edu | still dies.... UUCP: elroy!wciu!lfa!george |