[OS X TeX] EPS to PDF conversion fails in graphicx (but not in preview)

[Peter Dyballa]

Am 03.12.2010 um 18:02 schrieb Themis Matsoukas:

> I have followed the various suggestions. The question remains,  
> however, that the problematic eps file is converted properly by  
> preview but not by epstopdf. Here is a more recent version of that  
> file. This version was annotated heavily in AI and, paradoxically,  
> epstopdf converts it properly, unlike the earlier version. This too  
> contains Adobe garbage but, apparently, not toxic enough to give  
> eps2pdf a bad stomach.

Themis,

it's not a question of complexity of the image or the PostScript code.  
The problem is that the *obvious* PostScript code ends and *obvious*  
garbage starts, as this screenshot shows:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: aic5c.eps.png
Type: image/png
Size: 15325 bytes
Desc: not available
URL: <http://tug.org/pipermail/macostex-archives/attachments/20101203/b432ee62/attachment.png>
-------------- next part --------------



I opened your original EPS in GNU Emacs and scrolled down, browsing  
the code. At some point GNU Emacs became inoperable, consuming all the  
remaining CPU power. By means of binary searching I could determine a  
line number at which GNU Emacs could still be operated. So I removed  
all text between the beginning of the file (some binary garbage,  
*obviously* again) and the end of this line. I then saved the  
remaining contents under the name aic5c.eps with a slightly changed  
encoding: The original encoding is Mac-Roman with Classic Mac line  
endings, ^M or Carriage Return or RET, the new contents has UNIX line  
endings that all the UNIX tools understand. The ls command shows that  
I had erased half of your original file (changing all the remaining 59  
Carriage Returns into Line Feeds or ^J or LF/NL or New Lines does not  
change the byte count):

	-rw-r--r-- 1 pete    658294  3. Dez 18:20 aic5b.eps
	-rw-r--r-- 1 pete    333990  3. Dez 20:25 aic5c.eps

This allowed me to invoke the filter command you see in the screenshot  
(still guessing a bit about the lines remaining). The actual  
PostScript code ends latest at the first black line, the comment `` 
%AI9_PrivateDataEnd??. Then follows a line of mostly binary  
characters (ASCII NUL or ^@) and CARETs ?. The length of this line is  
approximately 314,899 characters ? not including the LF character at  
its end. This line isn't PostScript. It's scrap from a defective disk.  
Or a defective programme.


Your original file has 10,919 lines. The first 10,861 lines are (more  
er less) useful PostScript. Preview *obviously* discards the trash on  
the last 58 lines. The Ghostscript documentation is not clear whether  
it can perform the same. In reading the scrappy last 327,759 bytes of  
your file Ghostscript can fail somewhere inside this trash. The trash  
might also vary, from day to day, maybe depending on the moon's phase  
(I never wrote programme code for Adobe, so I don't know exactly)...  
or the disk sectors.


Check your disk (with Disk Utility). Maybe install SMART Reporter,  
which periodically checks whether your disk wears out (http://www.corecode.at/smartreporter/ 
).

--
Greetings

   Pete

The day Microsoft makes something that doesn't suck is the day they  
start selling vacuum cleaners.
				? Ernest Jan Plugge