cplai@daisy.UUCP (Chung-Pang Lai) (04/12/89)
I have a simple picture created by Adobe Illustrator 88. It consists of
about 200 lineto + curveto operations. The file was saved in EPSF format.
Before I did this using Adobe Illustrator 88, the original was done in
hand-built PostScript. The printing is pretty fast. At least I never
had the impatient feeling.
I redid this picture in Adobe Illustrator 88 because I need a screen preview
for imbedded graphics. The resulting number of l + c operations are
the same. However, the file size grew 5 times, from 10k to 50k+ partly due
to the preview rasterized Screen Image in Hex format (I actually used the
EPSI format) and partly due to a leeeeengthly Illustrator prolog. The
printing time is now making me impatient. I do not have the timer
program to do any benchmark. I guess it is about 5 min verses 1-2 minutes.
I simply like to make it print faster.
This triggered several questions:
1. Why does the Illustrator software dump out the full prolog, including
blah-blah-CustomColor... blah-blah-cymkcolor... while my
drawing doesn't even use any color? Would it make the printing much
faster if the prolog is shrinked to what the "meat" (or the "script"
if put in PS jargon) of the file really asked for? The software could
keep track of what type of operations are being used in the file and dump
out only the subset of prolog really needed.
2. In case that the creator is not care enough to improve, is there a post
processor that trim EPSF down to the minimum?
3. Could the slow down be caused by the hugh preview image alone?
Thanks in advance for any suggestions.
--
.signature under construction ...
{pyramid, osu-cis, uunet, killer}!daisy!cplai C.P. Lai
cplai%daisy.UUCP@uunet.UU.NET cplai%daisy@killer.DALLAS.TX.USA
Daisy Systems Corp, 700B Middlefield Road, Mtn View CA 94039. (415)960-6961cplai@daisy.UUCP (Chung-Pang Lai) (04/12/89)
In article <2926@daisy.UUCP> I wrote:
]
]3. Could the slow down be caused by the hugh preview image alone?
I take back this question. I looked at the file being sent to the
printer. The software which handles the EPSF import is smart enough
to strip out the Preview image before printing the file. So the
slow down is most likely caused by the lengthly over-done prolog.
--
.signature under construction ...
{pyramid, osu-cis, uunet, killer}!daisy!cplai C.P. Lai
cplai%daisy.UUCP@uunet.UU.NET cplai%daisy@killer.DALLAS.TX.USA
Daisy Systems Corp, 700B Middlefield Road, Mtn View CA 94039. (415)960-6961roger@homxc.ATT.COM (Another Technical Editor) (04/13/89)
In article <2926@daisy.UUCP>, cplai@daisy.UUCP (Chung-Pang Lai) writes:
< (compares file size and printing speed of home-brew PostScript
< vs. Adobe Illustrator 88, which took 5x as much space and time)
<
< This triggered several questions:
< 1. Why does the Illustrator software dump out the full prolog, including
< blah-blah-CustomColor... blah-blah-cymkcolor... while my
< drawing doesn't even use any color? Would it make the printing much
< faster if the prolog is shrinked to what the "meat" (or the "script"
< if put in PS jargon) of the file really asked for? The software could
< keep track of what type of operations are being used in the file and dump
< out only the subset of prolog really needed.
<
< 2. In case that the creator is not care enough to improve, is there a post
< processor that trim EPSF down to the minimum?
<
So why doesn't Adobe borrow a feature from compiler design and
link in only the procedures that make sense for a particular picture?
It would significantly speed up downloading, postprocessing,
and execution in the printer. Heck, the software industry has
had smart linkers for years.
I'm not trying to bash Adobe here. In fact, Adobe is, IMHO,
probably about the only developer whose PostScript output
files are consistently clean enough to post-process at all.
MacDraw files require too much manual diddling, Cricket files are
still mysterious, and I haven't tried anything from Aldus.
< .signature under construction ...
< {pyramid, osu-cis, uunet, killer}!daisy!cplai C.P. Lai
< cplai%daisy.UUCP@uunet.UU.NET cplai%daisy@killer.DALLAS.TX.USA
< Daisy Systems Corp, 700B Middlefield Road, Mtn View CA 94039. (415)960-6961
------------
Roger Tait ..att!homxc!roger
AT&T Bell Labs Technical Publications Holmdel, NJ
"Abbie Hoffman is dead and I don't feel too good myself."greid@adobe.com (Glenn Reid) (04/18/89)
In article <2926@daisy.UUCP> cplai@daisy.UUCP (Chung-Pang Lai) writes: >This triggered several questions: >1. Why does the Illustrator software dump out the full prolog, including > blah-blah-CustomColor... blah-blah-cymkcolor... while my > drawing doesn't even use any color? Would it make the printing much > faster if the prolog is shrinked to what the "meat" (or the "script" > if put in PS jargon) of the file really asked for? The software could > keep track of what type of operations are being used in the file and dump > out only the subset of prolog really needed. > >2. In case that the creator is not care enough to improve, is there a post > processor that trim EPSF down to the minimum? The simple solution is to save the file in "Adobe Illustrator 1.1 compatible format" or whatever the button is labeled in the dialog box. Then the prologue is very short. The bigger problem with subsetting the prologue is that you can't interchange prologues between documents or to factor them out (one prologue is downloaded, but 100 individual illustrations can use it). We started out with the idea of subsetting it, since it gets pretty big, but kept running into difficulties. I think it still makes sense, though, and I will re-enter the suggestion into the Illustrator tech group. Glenn Reid Adobe Systems Developer Tools & Strategies