[tex-k] Re: dvips premature end of file in binary section

[Pierre MacKay]

> I think that you are right on, Tom.  The problem is that the EPS files usually
> see more action than just inclusion into a "master" PS file via dvips.
> 
> The problem is that the EPS file is usally included via, say, \includegraphics,
> and then latex (TeX) has to parse the EPS file for the BBox (not everyone uses
> the .bb file option).  So, if a Mac EPS file gets transferred in binary mode to
> a UNIX/wintel box, TeX will think the EPS file is one LONG line because 
> the EOLs are not UNIX/DOS EOLs.  Oops!
 

This is a problem that can only get worse, because binary passages
in PS files are bound to become ever more bloated.  
The Macintosh -> UNIX/Windows problem can be solved in all sorts
of messy but simple ways, (I use tr) but the long binary
problem is going to be a lot worse.  No matter how large the TeX
input line buffer is made, some application is going to produce
a binary even longer.  Moreover, any binary is likely to include
an \012 or \015 character somewhere in it, and TeX is, not surprisingly,
going to breathe a sigh of relief and regard that buffer as
terminated.  I suspect that TR is looking at the only
workable solution, which is to recode the Binary passage into
Hex, or something similar which permits lines of a reasonable
length.  I presume---I certainly hope---that a passage translated
from binary to ASCIIHex or ASCII85 will be successfully be
retranslated by any competent PostScript interpreter. 
Since %%BeginBinary and %%EndBinary are not likely to
have anything else nested between them, a Perl translation ought
to be not too complicated.   (No, I am afraid I am not volunteering.
I do Perl, but not nearly well enough to expose my programming
style to public scrutiny.)


Email:  mackay@cs.washington.edu		Pierre A. MacKay
Smail:  Department of Classics			Emeritus Druid for
	218 Denny Hall, Box 353110		Unix-flavored TeX
	University of Washington
	Seattle, WA 98195
	(206) 543-2268 (Message recorder)