Practical applications of printer control codes - second of a two-part series
From "VS Workshop", Access to Wang, May 1990
|[ Prior Article ] [ Return to the Catalog of articles ] [ Next Article ]|
In our last installment I described one means of remotely controlling industry-standard printers by imbedding control characters into the text portion of a VS print file. This month I'll refine those concepts and offer some practical applications.
The techniques described in this and last month's columns have been tested under several real-world situations, including remote and local access under 2110 terminal emulation, file transfer software over the 928 link (coaxial cable), alternative printer control software, and non-Wang laser printers. Specifically, the following products were tested:
2110 terminal emulation: VSTERM from MacSoft; VsCom from M/H Group; VS2110E from Software Business Applications, Inc.; 2110 emulation and VS-Transit from DPZ Systems.
Industry-standard printers (connected through serial and parallel connections): Hewlett-Packard LaserJet IIP, II; Texas Instruments OmniLaser 2015 (acting as a LaserJet); HP DeskJet; NEC, Panasonic, and Okidata matrix printers.
Non-Wang printers (connected through 928 connections): Applied Computer Science HP LaserJet II.
Miscellaneous printer approaches: Powerdriver from Creative Process (through 2110 and 928 connections); VSPC928 from Software Business Applications.
In all cases, the text area of the original VS print file was allowed to pass directly to the target printer and affected it - even though the file's Printer Control Codes (bytes 1 and 2) were often converted to industry-standard control code equivalents by intermediary software. In short, I haven't found any case where imbedded control codes are filtered, modified, or otherwise rendered ineffective.
Some readers may need help to make sense of their printer manuals. As I mentioned last month, many printer technical manuals come with helpful examples in BASIC. The CHR$ function is usually shown, often mixed with literal values. CHR$ refers to the decimal value of a character, and compares directly with the &BYTE function in Procedure language. Since most of us are familiar with the hexidecimal value of characters, such examples usually require a translation from hex to decimal.
There are several valid ways of representing the same character string. For example, the following control character combinations are identical in function, and initialize Epson-compatible printers:
BASIC-80, GW-BASIC, BASICA:
PRINT CHR$(27);"@"; - or - PRINT CHR$(27);CHR$(64);
ASSIGN &X = &BYTE(27) !! "@" - or - ASSIGN &X = &BYTE(27) !! &BYTE(64)
Procedure language using the HEXPACK VSSUB:
DECLARE &X STRING (04) INITIAL "1B40" DECLARE &Y STRING (02) RUN HEXPACK IN VSSUBS ON VOLUME USING &X, &Y, 4
COBOL example using FIGURATIVE CONSTANTS:
FIGURATIVE-CONSTANTS. HEX-1B = "1B" HEX-40 = "40". . . etc. WORKING-STORAGE SECTION. 01 PRINTER-CONTROL. 05 FILLER PIC X(01) VALUE HEX-1B. 05 FILLER PIC X(01) VALUE HEX-40.
If hexidecimal notation is most convenient to you, the HEXPACK and HEXUNPK subroutines in the VSSUB library will be of interest. The conversion could even be performed within a procedure using the &INDEX function and a small table of valid hexidecimal characters, like this:
PROCEDURE HEXTEST - demonstrates hexidecimal conversions DECLARE &HEXIN STRING (04) INITIAL "1B40" DECLARE &CHAROUT STRING (02) DECLARE &HEXTABLE STRING (16) INITIAL "0123456789ABCDE" ASSIGN &CHAROUT = &BYTE (((&INDEX (&HEXSTR, &HEXIN (1,1))-1)*16) + ((&INDEX (&HEXSTR, &HEXIN (2,1))-1)))
Control codes and their use are not the only differences between VS print files and comparable PC files. Many VS applications start the file with a page eject and end with the last line to be printed; PC print files usually work in the opposite manner.
In addition, some PC applications (i.e. the MS-DOS PRINT command, DPZ 2110 emulation) add a forced eject at the end of the print file regardless of what the file contains. This disparity of approach provided me with piles of blank waste sheets because one or two sheets were advanced in between print files. With a two-year supply of scratch paper (and growing), it was time to take control of form control as well as pitch and other printer characteristics.
The PRINTCTL subprocedure (Figure 1) represents one possible method of controlling printers. It merges printer control information from a previously-created parameter file with a print file, creating a file containing all necessary control information. I have assumed that you have a library of printer control files in a library called @PRTCTL@ on the system volume that contain the combinations of print characteristics you wish to use. These files could have been created using the TESTCHAR procedure in last month's column or through any other means.
Accepts the name of a VS file and the mode (the name of print file containing control codes)
Creates a revised print file with the contents of the printer control file at the beginning
Suppresses any page feeds at the start of the file; instead, inserts a page feed at the end
On successful operation, scratches the original print file and renames the new file to take its place.
PRINTCTL uses Wang's CREATE utility to perform the byte splicing. Note the care taken in padding records with spaces prior to entering any other information; this is necessary to flush the buffer of characters remaining from the last WRITE operation.
Naturally, there are many other aspects to printer control that could be exploited using these techniques. Many other valid printer, connection, and control combinations exist; the PRINTCTL procedure is intended to illustrate some possible approaches.
I hope that this information is of interest and benefit to you. If it is, please share some of your techniques with me for a future column.
Figure 1: Procedure PRINTCTL
PROCEDURE PRINTCTL - merges files for printer control USING &FIL STRING (08), &LIB STRING (08), &VOL STRING (06), &PRTCTL STRING (08) DECLARE &RC, &RS, &RCODE INTEGER DECLARE &SYSVOL STRING (06) EXTRACT &SYSVOL = SYSVOL ASSIGN &RC = RECORDS USED BY &FIL IN &LIB ON &VOL * Extract file's record count, size, and type RUN READFDR IN VSSUBS ON &SYSVOL USING &FIL, &LIB, &VOL, 0, "RS", &RS, &RCODE R1: RUN CREATE IN @SYSTEM@ CANCEL EXIT IS X ERROR EXIT IS X O1: ENTER OUTPUT FILE = &FIL, LIBRARY = #PRTWORK, VOLUME = &VOL, TYPE = P, RECSIZE = &RS, RECORDS = &RC + 2 * Block 1: printer control records ENTER INPUT 02 ENTER PAD POSITION = 1, LENGTH = &RS ENTER INPUT FILE = &PRTCTL, LIBRARY = @PRTCTL@, VOLUME = &SYSVOL ENTER FILE ENTER INPUT 16 * Block 2: first record of file (disable page feed) ENTER INPUT 02 ENTER PAD POSITION = 1, LENGTH = &RS ENTER INPUT 02 ENTER PAD 02 ENTER PAD PAD = 00, POSITION = 1, LENGTH = 1 I1: ENTER INPUT FILE = &FIL, LIBRARY = &LIB, VOLUME = &VOL ENTER FILE INPOS = 2, OUTPOS = 2, LENGTH = &RS - 1, START = 1, END = 1 ENTER INPUT 16 * Block 3: append remainder of print file ENTER INPUT 02 ENTER PAD POSITION = 1, LENGTH = &RS ENTER INPUT (I1) ENTER FILE INPOS = 1, OUTPOS = 1, LENGTH = &RS, START = 2, END = LAST ENTER INPUT 16 * Block 4: insert page feed at end ENTER INPUT 02 ENTER PAD 02 ENTER PAD PAD = 80, POSITION = 1, LENGTH = 1 ENTER PAD 02 ENTER PAD PAD = 00, POSITION = 2, LENGTH = 1 ENTER INPUT 16 * No more input; end ENTER INPUT 16 ENTER EOJ 16 IF R1 <> 0 RETURN CODE = 99 SCRATCH (I1) [ Scratch input file ] RENAME (O1) TO (I1) [ Rename output file ] X: RETURN
Copyright © 1990 Dennis S. Barnes
Reprints of this article are permitted without notification if the source of the information is clearly identified