🚀 go-pugleaf

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
> --