philip@hubcap.clemson.edu (Philip L Harshman) (07/13/90)
I have recently been working on trying to force PostScript output from a Mac through a non-Apple PostScript printer (actually, a PostScript translater on an IBM mainframe). I have used (and greatly appreciated) the resources of the net to get modified LaserPrep files that will let me print my Mac files. This all seems to be working, but I still have a question remaining. Why is this necessary? Why is Apple's PostScript so non-standard? And just what is it about the Apple LaserPrep file that gives other printer so much trouble? I'd appreciate any info people can pass on about this. -- Philip Harshman uucp: ... !gatech!hubcap!philip Employed by Clemson University inet: philip@hubcap.clemson.edu although they have no idea that bitnet: philip@clemson I'm doing this. (So don't tell!) phone: (803) 656-3697
ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (07/16/90)
Here's my 2 cents' worth:
* The Laser Prep definitions are there to ease the job of translating
graphics (including text) from the QuickDraw mindset to the
PostScript mindset. To do this, they add another level of interpretation,
on top of PostScript, which is already interpreted.
* They also include a number of eexec's--3 in the 5.2 version of
Laser Prep: one which redefines the "tonerlight" operator on
LaserWriter NT's (fix for a ROM bug?), and two more to define
Apple's special bitmap stretching and smoothing operators. The
worst thing about these eexec's is what the check that the preceding
PostScript code does if it finds these are already defined:
it simply does a "flushfile", which causes the entire rest
of your print job to be ignored. This really only causes a
problem a) if a Mac user has already done a print job to that
printer, which means that Laser Prep is already loaded, and b)
your printer interface software isn't smart enough to check for
the presence of Laser Prep itself.
I managed to hack the code about to do a "readstring" and
eexec from that, rather than direct from "currentfile" (so that
I could just discard the string if the operator was already defined),
but that required getting the length of the readstring exactly right.
Also, those hex characters are stored as a few *extremely*
long lines. This may cause problems with software which is trying
to process the PostScript a line at a time.
* The Mac LaserWriter driver was never designed to produce encapsulated
PostScript (after all, how would you handle a multiple-page print job?).
If you're trying to turn Mac PostScript output into an EPS file, I wish
you luck.
By the way, I don't understand this business about requiring "<" and ">"
brackets on the hex input to "readhexstring": I just tried talking
to one of our LaserWriters over an RS-232C line, and readhexstring
works just fine without the "<" and ">".
It's not needed on readstring either; my hacked Laser Prep gets
away without it just fine--also over RS-232C lines.
Lawrence D'Oliveiro
Computer Services Dept fone: +64-71-562-889
University of Waikato fax: +64-71-384-066
Hamilton, New Zealand electric mail: ldo@waikato.ac.nz
It's a commentary on the state of the industry when the breakthrough
is seen to be, not getting an idea to work, but getting it to work
under Unix.liam@cs.qmw.ac.uk (William Roberts) (07/16/90)
In <9674@hubcap.clemson.edu> philip@hubcap.clemson.edu (Philip L Harshman) writes: >Why is this necessary? Why is Apple's PostScript so non-standard? And just >what is it about the Apple LaserPrep file that gives other printer so much >trouble? I'd appreciate any info people can pass on about this. Mac LaserPrep files are a problem because they make use of such a wide range of PostScript esoterica and have built-in assumptions about the kinds of printers they might be used with. This is one reason why programs like PageMaker offer the option of using their own (awful) PostScript prep files which they supply for a wider range of printers. As an example of the "gee whizz" approach that the Mac stuff uses, they create a procedure which records the default clip region in device coordinates, and call it at the beginning of every page. Each page is started by executing a string containing the names of some PostSCript routines (hence it executes those routines - I have no idea why they do this...) Some of the eexec stuff actually contains a string of gibberish which is passed to cexec (is this 68000 code?), so that may cause some hassle with printers onther than the LaserWriters. The reason behind all this? I think it is just intended to be non-encapsulated PostScript. Apple may simply be trying to make it hard to include Mac postscript in other documents, presumably on the grounds that PostScript is an output language intended only for printers, and that document composition should be done at an earlier stage. -- William Roberts ARPA: liam@cs.qmw.ac.uk Queen Mary & Westfield College UUCP: liam@qmw-cs.UUCP Mile End Road AppleLink: UK0087 LONDON, E1 4NS, UK Tel: 071-975 5250 (Fax: 081-980 6533)
SRWMCLN@windy.dsir.govt.nz (Clive Nicolson) (07/16/90)
In article <9674@hubcap.clemson.edu>, philip@hubcap.clemson.edu (Philip L Harshman) writes: > Why is this necessary? Why is Apple's PostScript so non-standard? And just > what is it about the Apple LaserPrep file that gives other printer so much > trouble? I'd appreciate any info people can pass on about this. After working on a number of versions of Apple's laserPrep I can only conclude that the guy who wrote it did so in the few minutes he had before being run down by a bus. Clive.
amanda@mermaid.intercon.com (Amanda Walker) (07/17/90)
In article <2514@sequent.cs.qmw.ac.uk>, liam@cs.qmw.ac.uk (William Roberts) writes: > Apple may simply be trying to make it hard to include Mac postscript > in other documents, I suspect that they simply don't care if it's hard or not. After all, capturing the PostScript file in the first place isn't even a "real" feature. This attitude may be annoying to many of us, but Apple can sometimes be awfully narrow-minded (and often it's not the engineers' fault :)). -- Amanda Walker <amanda@intercon.com> InterCon Systems Corporation
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) (07/18/90)
In article <2514@sequent.cs.qmw.ac.uk>, liam@cs.qmw.ac.uk (William Roberts) writes: > In <9674@hubcap.clemson.edu> philip@hubcap.clemson.edu (Philip L Harshman) writes: > > > Mac LaserPrep files are a problem because they make use of such > a wide range of PostScript esoterica and have built-in > assumptions about the kinds of printers they might be used > > Some of the eexec stuff actually contains a string of gibberish > which is passed to cexec (is this 68000 code?), so that may > cause some hassle with printers onther than the LaserWriters. Yes it is 68000 machine language. I would appreciate it if someone would email me the eexec portions of the laser prep file, as I don't have a MAC to get it from. I'd like to look at the 68000 code a bit. I'm currently tearing Cexec stuff appart, and documenting how it works. I'm looking for all the cexec stuff I can get my hands on. I suspect that Apple does these sorts of things, to encourage people to buy THIER laserprinter, rather than someone elses. I'm sure that is why the original laserwriters didnot have a centronics port...etc... Cheers Woody
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) (07/19/90)
Thanks to all who sent the eexec stuff from the laser prep files. I'll tear it appart, along with any cexec stuff, and report back....as soon as I can... Cheers Woody