Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!intercon!amanda From: amanda@intercon.com (Amanda Walker) Newsgroups: comp.lang.postscript Subject: The Woody and Amanda show continues... Message-ID: <1686@intercon.com> Date: 5 Jan 90 23:15:33 GMT References: <4386@amelia.nas.nasa.gov> <17544@rpp386.cactus.org> <1679@intercon.com> <17557@rpp386.cactus.org> Reply-To: amanda@intercon.UUCP (Amanda Walker) Organization: InterCon Systems Corporation, Reston, VA Lines: 187 First, a couple caveats, both to Woody and the rest of you who are out there spectating: It was a little late when I wrote my last article, and so its tone was a little sharper than I intended. That being said, I still stand by my position that the stuff we're talking about shouldn't be considered part of "official PostScript", simply because (a) it *is* different from printer to printer, and (b) a lot of things (like HPLJ emulators etc.) are put in by the manufacturer, not Adobe, and so asking Adobe to document and support them is silly. Now, to fulfill my promise, here is an example of defining a custom page size on an Apple LaserWriter, PostScript v38.0. It defines a page size called "statement" (named after the built-in page size on a Dataproducts LZR-2665) which has an imageable area of 5.5 by 8.5 inches, oriented portrait-style in the center of a standard U.S. letter-size page. Changing the orientation or placement (so you could use actual statement-sized paper fed in sideways) is left as an exercise for the reader. It may take some editing to make it work on other printers (it's free--you get what you pay for :-)). I've included comments for the curious. /statement [ % device matrix for framedevice: 300 dpi, origin at lower left [300 72 div 0 0 -300 72 div 0 2550] % bitmap dimensions, bytes followed by scan lines 208 2550 % output procedure for this device { % set the job state for status queries statusdict /jobstate (printing) put % stop LED blinking 0 setblink % corrected offsets for image (stored in EEPROM) margins % center image on letter size paper exch 450 add exch 750 add 8 div round cvi % set timeout if manual feed manualfeed { manualfeedtimeout } { 0 } ifelse % send the image to the Canon engine #copies frametoprinter % set the job state back statusdict /jobstate (busy) put % start blinking the LED again 1 setblink } /framedevice load % set a default screen frequency & spot function for this page size 60 45 { dup mul exch dup mul add 1.0 exch sub } /setscreen load % default transfer function for this page size { } /settransfer load % do initgraphics & erasepage to prepare the framebuffer for use % and set up the new graphics state. /initgraphics load /erasepage load ] cvx statusdict begin bind def OK, all of you who are just here for the code can leave now :-). In article <17557@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker) writes: interesting. Can you enlarge the input buffer as well this way? I imagine that depends on how the code for that printer was written. If the person at QMS who did the parallel I/O code used a statically-allocated buffer, you're out of luck. you are the one doing the judging of whether these fit your criteria of "intensely useful", Actually, I was just going to watch the discussion on the net. I wasn't intending to define you away :-). Superexec overrides nearly all invalid access errors. This allows you to realy get into the internals of the PS interpreter. Well, one problem is that it isn't always there. It doesn't seem to be in my LaserWriter, for example, and I did look when Don mentioned it in Computer Shopper a few months back. On the NEC 890, the operators for writing message to the front panel, and for reading the menu options on the front panel are in an internal dictionary, that is accessed by operators in server and statusdict. OK, I'd say that's useful, especially since you can put stuff into the PS prologues that your software downloads to take advantage of it. It's too bad QMS evidently didn't document them the way custom operators usually are (such as ones for tray selection or sometimes custom page sizes (on the L300, for example)). [paper tray woes omitted for brevity's sake] Not a bad point either. This is not documented behavior, as it is in the serverdict and statusdict and most of those are classed as "undocumented" and not part of normal ps. It happens that this "bug" if you will, is common to a large number of printers. Well, but they *aren't* part of "normal PS." They are defined and implemented by the manufacturer of the printer, not Adobe (or so I would think). And they are different for every printer. I could see an argument that it would be helpful to document them in the printer-specific supplement for a particular printer, but if they were to become official parts of PostScript, people would start using them to write code that would break on other printers. I am quite strongly of the feeling that PostScript as such should be defined as a guaranteed subset of all possible implementations, not the inclusive superset of them... if you are writing an emulator for a machine that has dual trays, and the printer you are emulating supports it, why ignore it? I still wouldn't call a bug in the LJ emulation a PostScript problem :-). Serial port opening in transparent mode is also there. Yes, I know, I gripe about that one. My contention is that it shoud be both documented and available to the end user. Perhaps, but it's still printer-specific. There may well be intervening hardware or software that only guarantees 7 bit printable ASCII (let's say you are driving a PS printer from an EBCDIC machine through a protocol converter, for example), and since an arbitrary PostScript program cannot rely on always being able to do transparent I/O, it should not be defined as part of the language. The red book isn't a printer manual, it's a language manual. Besides, I'd guess that half of the reason for 'eexec's existence is to guarantee a virtual 8-bit channel as it is to provide encryption, just because you can't rely on having a transparent communiucation channel. The one gotcha there, is that it is awfuly hard to regain control. Well, if they were intended for general use, they might be easier to use :-). ROMnames, an internal array of font names is there, and saves quite a bit of code space. What if you're on a machine (or interpreter) that doesn't have any fonts in ROM? Why not just use the FontDirectory and test for a fonts directory on a file system if it exists? These are documented, and I can't think off hand how looking at ROMnames would be any more useful... It is manufacturer specific kind of code, and not realy part of the interpreter, so there is nothing to prevent you from doing that. Re-burning PROMs seems a little extreme, but aside from that, this exact printer-specificity is why I don't think that it should be documented as part of PostScript. I admit that I don't spend much time trying to solve specific problems for specific printers, as you evidently do, and that does give me a different slant on things. My major uses of PostScript (preparing illustrations and documentation) in fact require me to think in as universal terms as possible, so that code I write will run on a LW, or a Linotron 300, or a QMS ColorScript, or a window on a Sun running NeWS, or a NeXT machine, or whatever. It is true that the set of instructions accepted by any particular PostScript implementation is a superset of the red book, but I don't think that difficulties in solving particular problems with particular printers are grounds for complaints about the state of PostScript or Adobe in general, which is how I perceive a lot of what Don Lanacaster has written, and a fair amount of what you've posted. The fact that printer manufacturers could often do better jobs with their docs is almost a truism :-), I'll admit. At least you can write code to get around a lot of the problems. Non- PostScript printers don't even let you do that, after all. ... avuncular sleezoid. You perhaps will appreciate that this term could apply to it's author as well? True :-). As I've said, I do have a certain fondness for Don's work, which is I guess why I get so annoyed when he takes valid specific problems and makes them the basis for wild general claims and ad hominem (ad corporationem? I don't know much Latin) attacks. A final word, go read pages 366-367 of real world postscript. Well, I haven't bought it, mainly because I couldn't justify it's cost to information content ratio, at least for my level of familiarity with PostScript. What's on those pages? Amanda Walker InterCon Systems Corporation