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

[Siep Kroonenberg]

On Sat, Dec 04, 2010 at 11:01:28AM +0100, Peter Dyballa wrote:
> 
> Am 04.12.2010 um 10:07 schrieb Siep Kroonenberg:
> 
> >>The file starts with the hex c5d0d3c6 (or ≈–”Δ as string). Then
> >>comes a SPACE (or 20) followed by three ASCII NUL. So the number is
> >>20,000 hex or 131,072 dec. This leads into the middle of some
> >>PostScript code. Then follows 7B50 hex (^G^K^E^@) or 31,568 dec. The
> >>"scrappy" last 327,759 bytes then are a TIFF image of the EPS
> >>image...
> >
> >Byte order. Postscript start is 0x00000020, Postscript length is
> >0x00045ac7. The byte order of these numbers is always little-endian.
> 
> How do you come to this figure? When I read the byte sequence
> ^G^K^E^@ backwards I get 05B7...

The hex viewer of Midnight Commander shows

  C5 D0 D3 C6 | 20 00 00 00 | C7 5A 04 00 | 00 ...

> >>And 5002.EPSF_Spec describes this header as "DOS EPS Binary File
> >>Header" – why is it produced on a Mac in a Mac-Roman encoding?
> >
> >Just try it. It works.
> 
> 
> Already tried the last days, few utilities, both AI images, no
> problems encountered! (Right now I let in the background GNU Emacs
> edit the file to leave just the TIFF portion to see whether it's OK
> – with the Mac line endings no UNIX command line tool works and the
> UNIX line endings converted file is not OK...)

The Perl script that I listed earlier:

#!/usr/bin/perl
undef $/;
$ALL = <>;

if (substr ($ALL, 0, 2) eq "%!") {
  print $ALL;
} else {
  @toc = unpack "VV", substr ($ALL, 4, 8); # offset, l. of PS part
  print substr ($ALL, $toc[0], $toc[1]);
}

does a byte-for-byte binary copy: `under $/;' means: undefine the
line ending character.

-- 
Siep Kroonenberg