[tex-k] Re: dvips premature end of file in binary section
Fri, 2 Feb 2001 14:50:54 -0800 (PST)
> 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: email@example.com 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)