Illustrator 8-10 puts wrong byte count for hex thumbnail

bug-ID: ILL8-2002-02-01

Illustrator 8.0 & 9.x & 10.0 generate an invalid DSC comment at the top of EPS files; this causes dvips  to reject these files when comment elision (-K) is turned on. Essentially, the byte count for the hex thumbnail (as expressed in the %%BeginData comment) is incorrect, so does not conform to the DSC specification.

Software Versions

• Illustrator 8 and Illustrator 9
• all platforms

Reported by:

Tomas Rokicki, 1 February 2002.

Example

(Click on an image to download the corresponding file.)

created with (Illus8.0)	resaved: (Illus9.02)	resaved: (Illus10)
rokicki/sample.eps	rokicki/sample-ill9.eps	rokicki/sample-ill10.eps
%%BeginData: 4312 Hex Bytes	%%BeginData: 4314 Hex Bytes	%%BeginData: 4466 Hex Bytes
created with (Illus9.0)	resaved: (Illus9.02)	resaved: (Illus10)
rokicki/sphcoor.eps	rokicki/sphcoor-ill9.eps	rokicki/sphcoor-ill10.eps
%%BeginData: 6956 Hex Bytes	%%BeginData: 7244 Hex Bytes	%%BeginData: 7052 Hex Bytes

The changes in the number of Hex Bytes, when the original EPS file is resaved with a later version of Illustrator , indicates actual differences in the thumbnails produced by these different versions.

In each case, the number stated is 2 x the count of `virtual' data (see below); hence agrees with the count of `physical' data, but only after ignoring the white-space (line-ends) and `comment' characters (%) preceding each line.

Further Information

Tomas writes as follows:

This note is to report a bug in Illustrator 8.0 and 9.0; its use of %%BeginData does not conform to the DSC specification.

Specifically, in the thumbnail section at the top of the document comments section, it includes comments such as         %%BeginData: 4312 Hex Bytes

According to the specification (PostScript Language Reference Manual, Second Edition, page 648, describing the %%BeginData DSC):

``Note that $\langle$numberof$\rangle$ indicates the bytes of *physical* data, which vary from the bytes of *virtual* data in some cases. With hex, each byte of *virtual* data is represented by two ASCII characters (two bytes of *physical* data). Although the PostScript interpreter ignores white space in hex data, these count toward the byte count.

``For example,        FD 10 2A 05         is 11 bytes of *physical* data (8 bytes hex, 3 spaces) and 4 binary bytes of *virtual* data.''

I am enclosing two such broken files sent to me by two of my users (of dvips ). In both cases, the byte count seems to be the total number of valid hex characters, not including the extraneous % character that Illustrator  inserts at the beginning of the line, nor the line terminators. A simple analysis of the file shows that, in the data section, we have:

Total bytes: 4531
Hex: 4312     White: 146     Misc: 73

So the DSC comment *should* be:         %%BeginData: 4531 Hex Bytes

The example on the following page (649) clearly indicates that the byte count, even for hex, should include *all* characters (the example they give includes an image operator, and they specifically mention that all five characters of ``image'', plus the newline following it, must be included in the byte count).

The impact on my users is that, for a very widespread version of dvips , they cannot include Illustrator  files when they are using certain combinations of options. I am currently testing a workaround for the next release of dvips , but clearly Illustrator  must be fixed.

I am always happy to help in any way, so contact me at rokicki@cs.stanford.edu if you have any further questions, or if there is any way I can be of help.

Thanks!

Tomas Rokicki

Suggested Fix/Workaround

 
Adobe: either follow the published DSC specification, or rewrite this specification to agree with what actually is done by the software.

Users:
Tomas has a patch to dvips 5.86e that works around this problem, for the next release of dvips .

If you have broken EPSF files, Tomas has written a Perl script that may fix them. If your system insists on executing scripts with the PL extension, you can also get it as text.