amanda@intercon.com (Amanda Walker) (01/06/90)
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 Corporationken@cs.rochester.edu (Ken Yap) (01/06/90)
Hey I know, let's create the newsgroup comp.lang.postscript.hacker and Woody can moderate it. :-) (Personally I'm more interested in using a PS printer as an appliance. If I want to hack, I have a soldering iron and an 8088 machine at home. :-))
woody@rpp386.cactus.org (Woodrow Baker) (01/07/90)
In the interest of brevity, and ease, I've started a new message block
here. The comments refered to here, can be found in the other
post with the subject The Woody and Amanda show.
First, QMS didnot do the NEC890. That is a NEC printer.
Second, 8 bit transparent i/o should be allowed. I don't have any problem
with permitting it by a special switch setting, or even a software switch
setting, but it should be there for you when needed.
Thirdly Adobe totaly controls what goes on the rom. QMS cannot even look
at it, using a dissasembler without violating thier contract. The way
it works, or at least USED to work, is that the OEM would specify the
address of the i/o port hardware, and the hardware specific stuff. Adobe
would then generate a version of PS for them, complete with the printer
specific stuff, and send them a set of master roms. This was the way
it was explained to me. QMS didnot write either the emulators, or
the paralell code. They were furnished by Adobe. QMS has had many
years of experience with printer emulators. Any emulation that they
did would be a LOT better than the Adobe implementations of the HP and
DIABLO emulators. I know this, because they had no knowlege of things
that they would have if they had written these. In addition, conversations
with Adobe confirmed the fact that they did the emulators.
In addition, QMS did not write the centronics drivers. If they had, they
certainly would not have made them available to Apple, but there they are.
The DIABLO emulator is far from complete.
The HPLJ emulator does NOT behave like the HP. Specifically, if you
tell a true HP that there are 66 lines per inch, it will do 6 lines
per inch. The emulator in the Adobe printers will happily do 66 lines
per inch. Looks wild.
The HPGL emulator gets lost on certain commands.
I realize that your areas of work and my areas of work are vastly different
in regard to Postscript. I have used it in a production enviornment doing
the typesetting for a local penny-shopper type rag of 16-20 pages. I
did all of the layout, and typesetting for it, for about a 3 month
period. I know how it impacts work schedules.
Superexec seems to exist on versions above 41. So yes, it is not on
all printers. The ones that it is on, however, allow you to understand
more about the earlier ones.
Your code is most interesting and useful. Thanks.
Cheers
Woody