lishka@uwslh.slh.wisc.edu (Chris Lishka (hang loose...) ) (06/27/90)
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) writes: [I deleted some of Woody's original test to save bandwith C.L.] >In article <1990Jun25.141336.16312@uwslh.slh.wisc.edu>, lishka@uwslh.slh.wisc.edu (Chris Lishka (friend of jabberwockies) ) writes: >> woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) writes: >> >> real solution is *not* to try and write everything in PostScript. >> >Not all of the escape sequenced are pur printable characters. >In fact while a lot of them are, if you look at say the graphics primitives >you will find that the bit-maps and some of the positions are binary. The "LaserJet Handbook" states that PCL commands appear as the following: ESC X y # Z data where "X" is a "parameterized character" within the (decimal) range 33 through 47; "y" is a "group character" within the (decimal) range 39 through 126; "#" is a "value field" consisting of digits, an optional decimal point, and an optional "+" or "-" character; "Z" is a "terminating character," which is an uppercase or lowercase ASCII letter, and "data" is a sequence of eight-bit bytes. Therefore, only commands which have data following them possibly contain non-ASCII characters. Referring to appendix A in the LaserJet II User's Manual, the only commands which use binary data are: * Create font (font header) * Download character * Transfer bitmap data * Transparent print data Therefore, *all* PCL 4 commands except those listed above consist of printable ASCII characters plus the non-printable escape character (which PostScript has no trouble with). A statement from your original article: > So, If you wrote an HPLASERJET emulator in postscript and downloaded it > to the printer, you could not do graphics, could not position to certain > positions on the page, etc. etc While I agree that *graphics*bitmaps* (and downloaded fonts, and transparent print data) cannot be achieved, positioning on the page is fully achievable. As I have shown above, PCL page motion commands (like all PCL commands that do not require binary data) can be transferred to a PostScript printer without any characters being misinterpreted. In fact, *all* PCL 4 commands except those listed above can be transferred without a hitch, provided you have written a PostScript scanner/parser to read them in over the serial line. >For example, to set a tab on most printers (I haven't looked the >HP up recently) you do something like do an absolute tab to a given spot >on the page, then issue an ESCAPE code sequence. While this may be true of other printers, it is not true of LaserJets. To my knowledge, I don't think you *can* set tab stops in PCL. >In the emulator that I wrote, >we wound up having to modify the operating system driver to check for >these characters (anything below a space) and emit them with a special >marker. What has this got to do with PostScript? This sounds more like an operating system problem to me. >As for as downloaded emulators vs conversion to postscript, it is more >desireable to be able to take a package such as perhaps a General >ledger package, or someother package that knows nothing about postscript >and have it be able to print to the printer directly, rather than >hijacking the output to a file and converting it. Indeed, in some cases >that would be impossible. In the case of the emulator that I wrote, that >would not have worked at all. The application and OS werenot designed >to do that. While I agree that it would be nice to use PostScript to write an emulator of another printer, I think it is going to be *much* too slow. The LaserJet emulator that I wrote in C is not the quickest, and that is *after* I hand-tuned the scanners and profiled the code. In PostScript it would be at least an order of magnitude slower, because PostScript is interpretted. A better solution is to use print spooling software which allows a filter to be inserted between the print command and the printer. Berkeley UNIX allows this, and in fact it is very necessary that this exist, so that PostScript printers can be used "transparently" to print normal text files (i.e. the translation from normal text to PostScript is invisible to the user). This is part of what the Adobe TranScript software provides. If a person wants to, they could stick my lj2ps program in as a filter (it would require I front-end shell-script), and use their PostScript printer transparently as a LaserJet. Still, any program worth its salt should be able to redirect printer output to a file. Given this capability, it would be easy to run a program such as lj2ps over the file and send this output to the printer. Given the speed problem with printer emulators written in PostScript, I would rather run an extra program. >Now, while I think that all programs should support Postscript directly, >there are many that don't. Take our compiler for Relay Ladder Logic. >It currently does not support postscript. I certainly could make it do >so, but generaly in an industrial enviornment you don't have $5000 printers >acting as a printer for some process control. One of these days, however, >it will be necessary I am sure. In the mean time, people use a dotmatrix >graphics printer to do thier printing. Wordstar 3.3 for example, does not >know about Postscript. It does know about Epsons etc. [Although I am not sure what this has to do with LaserJet emulation on a PostScript printer, I'll address it anyway.] If a program does not support PostScript, then use a printer spooler and a filter that does! Part of the role of a true operating system (or OS plus utilities) is to provide a device-independent means of printing text files. The Amiga does this, with great success. Microsoft Windows (more of an operating system than MS-DOS ;-) does this as well. >Most users are not >going to understand how to print to a file, and if they do, they certainly >don't want to be bothered with printing to a file, then running another >program to see thier results on the printer. If you are talking about PC's and MS-DOS, then I think it is a problem in the "operating system" (not that MS-DOS is much of one). Like I said above, the operating system should provide printer drivers and spoolers to make the printing transparent. PostScript should not be taken to task for this. -- Christopher Lishka 608-262-4485 "Dad, don't give in to mob mentality!" Wisconsin State Lab. of Hygiene -- Bart Simpson lishka@uwslh.slh.wisc.edu "I'm not, Son. I'm jumping on the bandwagon." uunet!uwvax!uwslh!lishka -- Homer Simpson
tj@gpu.utcs.utoronto.ca (Terry Jones) (06/28/90)
The commercial product Hijaak from Inset systems will convert HP PCL (The native language for a LaserJet) to PostScript. BUT It really only supports the PCL graphics stuff. It fails on font stuff. For example I cannot take a WordPerfect laserjet page file and translate it into PostScript. If I take something like a Lotus graph I could though. It is especially hard to translate fonts (Laserjet) into PostScript. tj
vgopal@cbnewsc.att.com (venu.p.gopal) (06/29/90)
In article <1990Jun23.184530.1326@cbnewsl.att.com> rl@cbnewsl.att.com (roger.h.levy) writes: >>In article <2414@acorn.co.uk>, pcolmer@acorn.co.uk (Philip Colmer) writes: >>>Yes, yet another convertor required. I noticed that someone has done a >>>HPGL to Postscript convertor. How about a HP Laserjet to Postscript convertor >>This request seems to come up continually but I have never seen a definitive >>statement as to whether such a convertor exists or is reasonable to >>implement. Can some Postscript knowledgable person please enlighten Post- >>script naieve people like me whether this is a pipe dream? Why not have the application generating the Laserjet stuff output postscript directly ? Most programs now support postscript - you might have to get the latest update or whatever. At least, this is true for the IBM PC world. For the handful that don't, you can screendump into postscript at least. Venu P. Gopal UUCP: ..!att!cbnewsc!vgopal Internet: vgopal@cbnewsc.att.com