amanda@mermaid.intercon.com (Amanda Walker) (01/04/90)
OK, Woody, I'm gonna call you on this article. A lot of what we've been disagreeing about is more attitude than anything else, but this is getting ridiculous :-). In particular [about undocumented operators in statusdict and $printerdict]: > One can completely alter the actions of the switches. My, how ... useful. Sort of like rewiring the buttons on an elevator, I guess. This might be useful if you could write out your new assignments to EEPROM in some standard way (so that you could flip between AppleTalk and 57600 baud, for example), but as it is I can't figure out any real practical use for this... > There are many other magical things hidden here, and some of them are > intensely useful. OK, I'll bite. In several years of speaking to PostScript printers, I have found two and only two "intensely useful" operations hiding in $printerdict, and they're even half-documented. They are printer-dependent, but anything that plays with $printerdict will be by its very nature. The first operation is to define a new page-size procedure that calls framedevice to make the page frame buffer smaller, thus allowing more memory for things like font storage. For example, reducing the frame buffer to 5.5 by 8.5 inches (which just happens :-) to be the size of a normal half-size manual page), you end up with almost 700K of free VM on a LaserWriter, which means you can permanently load in 16 or so more Adobe fonts that you usually can. In order to make this work right, you need to look at the definition for an existing page size in order to get the arguments to "frametoprinter" or "frametoroket" right, but this is hardly "magic." The second is to invoke resident printer emulators (such as the Diablo 630 emulator in a LW, or the HPLJ emulators in some other printers) under program control (and even better, over AppleTalk). Once again, sometimes useful but hardly magic. I challenge you to come up with a single other "intensely useful" capability that you can get by using your "magical" operators, and post the code to do it. If so, I'll post my page resizing code, just to be fair. Even if you don't want to post code, for fear of losing consulting money, I'd just honestly like to know what "many things" you think are so nifty... I don't mean to flame at you, Woody, it's just that the more you post, the more I wonder whether you work with the same PostScript that I do :-). Amanda Walker InterCon Systems Corporation --
woody@rpp386.cactus.org (Woodrow Baker) (01/05/90)
In article <1679@intercon.com>, amanda@mermaid.intercon.com (Amanda Walker) writes: > > OK, I'll bite. In several years of speaking to PostScript printers, I have > found two and only two "intensely useful" operations hiding in $printerdict, > and they're even half-documented. They are printer-dependent, but anything > that plays with $printerdict will be by its very nature. > > The first operation is to define a new page-size procedure that calls > framedevice to make the page frame buffer smaller, thus allowing more memory > for things like font storage. For example, reducing the frame buffer to 5.5 > by 8.5 inches (which just happens :-) to be the size of a normal half-size > manual page), you end up with almost 700K of free VM on a LaserWriter, which > means you can permanently load in 16 or so more Adobe fonts that you usually > can. In order to make this work right, you need to look at the > definition for an existing page size in order to get the arguments to > "frametoprinter" or "frametoroket" right, but this is hardly "magic." interesting. Can you enlarge the input buffer as well this way? It appears that the paralell printer routines have a *much* smaller buffer than the serial routines. I haven't worked out a way to increase it yet. e > The second is to invoke resident printer emulators (such as the Diablo 630 > emulator in a LW, or the HPLJ emulators in some other printers) under program > control (and even better, over AppleTalk). Once again, sometimes useful > but hardly magic. to parahrase A famouse sci-fi writer "any suffciently advanced or undocumented code is indistinguishable from magic" h > I challenge you to come up with a single other "intensely useful" capability > that you can get by using your "magical" operators, and post the code to > do it. If so, I'll post my page resizing code, just to be fair. Even if > you don't want to post code, for fear of losing consulting money, I'd just > honestly like to know what "many things" you think are so nifty... o.k. What good it will do, I don't know, because you are likely to disagree with nearly everything here, and you are the one doing the judging of whether these fit your criteria of "intensely useful", but to me they have been.e u here are some. Sorry for the overall size of this post. Before we get started, let me take the time to say that this will undoubtable generate tons of email. I'm NOT interested in getting flames over this stuff. Some of it will probably make Adobe upset, and that I can't help. It is not posted to be taking pokes at Adobe, but enevitabley (sic) something here will offend someone there. I appologize for that, and especialy to who ever wrote the tray selection code. We should start perhaps with the internal dict. It is not documented, and was dug up both through the serverdict and statusdict and through cracked fonts. It has superexec. Superexec overrides nearly all invalid access errors. This allows you to realy get into the internals of the PS interpreter. 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. These are extremely useful, being that there is no audible bell to ring, when your software needs something done, and can't always count on talking back to the host. For example, you can prompt for special forms to be inserted when needed, toggling into and out of manual feed. Consider the situation when someone is filling out many forms such as tax forms, or insurance forms. Being able to prompt through the front panel is extremely nice. If you want to, you can make the error handler emit messages to the front panel as well. Why does changing the paper tray clear the image. A problem that recently bit me and a client of mine was as follows: The client downloaded a form, selected the legal tray, then rendered the form. He then invoked the downloaded Diablo/Nec pinwriter emulator that I wrote for him, and selected as part of his standard forms processing package running on a mini, legal size. Printed the form. Only the printing came out, the form did not. After much hair pulling by both of us, I dug around through a dump of the serverdict and statusdict that I had grabbed over a year ago from a NEC 890, and discovered that who ever the software person was that wrote the code, was to lazy to check to see what tray was selected. He just did an initpage and an erase page, blowing everything out of the water, with no regard to what tray was currently selected. It flat would not have been possible, given the time constraints and conditions to have solved this problem otherwise. 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. Another example is the dual tray PS 800II. The hplaserjet emulation would not recognise the standard tray switch escape codes. All this brought from Adobe, was "Oh, you didn't ask for it". For crying out loud, if you are writing an emulator for a machine that has dual trays, and the printer you are emulating supports it, why ignore it? Anyway, to make a long story short, I poked around enough to discover that the emulator was using the DEFAULT paper tray, rather than the tray selected by the user. The documentation implies that the tray selected by the user stays in effect. Once the problem was spotted, I was able to write them a patch. It also enabled me to make a sale of 2 of the printers into a network enviornment that I would not have otherwise been able to. As you mentioned, switching emulations is one of those intensly useful things that is hidden here. Internaldict and secretdict are also buried here. These have many magic and wonderful things in them including superexec, which overrides most invalid access stuff. 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. The one gotcha there, is that it is awfuly hard to regain control. Open appletalk is there, so you can drop into apple talk if needed. Setblink lives there. You can control the blinking pattern of the leds on the front panel. This is useful. You can use it to indicate lots of things, like errormessages, and internal states of the program. Watchstreams is there. It is essential to *properly* access the built in emulators. ROMnames, an internal array of font names is therer, and saves quite a bit of code space. The code for the startup page is there. You can change it to whatever you want, by re-burining the roms. Try putting the owners name, and equipment id number there. It is manufacturer specific kind of code, and not realy part of the interpreter, so there is nothing to prevent you from doing that. I have several more pages of goodies I am getting tired of typing. Let me assure you that all of the above have proven useful, and all have been used at one time or another to solve problems for clients. They have all been worth goodly chunks of change. NOW: one for you, Don came up with this thing he calls an avuncular sleezoid. Draws 2 splines, then executes the spline functions by a simple ps routine that emulates the splines, and connects the 2 splines with lines. It makes for some facinating graphics. You, perhaps will appreciate that this term could apply to it's author as well? A final word, go read pages 366-367 of real world postscript. Cheers Woody > > I don't mean to flame at you, Woody, it's just that the more you post, > the more I wonder whether you work with the same PostScript that I do :-). > > Amanda Walker > InterCon Systems Corporation > --