Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!ginosko!uunet!intercon!amanda@intercon.uu.net
From: amanda@intercon.uu.net (Amanda Walker)
Newsgroups: comp.lang.postscript
Subject: Re: Eexec documentation?
Message-ID: <1445@intercon.UUCP>
Date: 12 Sep 89 15:21:50 GMT
References: <7670@microsoft.UUCP>
Sender: news@intercon.UUCP
Reply-To: amanda@intercon.uu.net (Amanda Walker)
Organization: InterCon Systems Corporation
Lines: 22

Don Lancaster (who writes "Ask The Guru") had a hacked-up way to reconstruct
eexec files, but the algorithm itself was described on this newsgroup a while
back by someone who's name I have momentarily forgotten (but I know he does
not work for Adobe :-)).  He'll probably post his stuff yet again in response
to your message.

It's not particularly useful, though.  Most things that are distributed in
eexec form are fonts and PostScript extensions, and the use of eexec seems
to be as much to preserve all eight bits of the file as to keep it from
prying eyes.  If you decrypt a font, it gets smaller but stays just as
incomprehensible.  You basically get the definition of a few procedures
(which are kind of nifty, actually) and a bunch of strings.  The fonts
are still magic, though.  Evidently the strings encode subpaths, hints,
and composite characters, but they're still locked up.  PostScript extensions
(like Apple's bitmap smoothing function) are once again represented as
strings, which contain (in this case) 68000 machine code plus some linkage
information.  Unless you understand the structure of PostScript from the
inside, this is also pretty useless.

--
Amanda Walker
amanda@intercon.uu.net    |    ...!uunet!intercon!amanda