Bug#184856: dvips can't include some eps files in postscript output file
On 22.03.03 Slaven Peles (peles@cns.physics.gatech.edu) wrote:
> On March 21, 2003 15:18, Hilmar Preusse wrote:
> > On 15.03.03 Slaven Peles (peles@cns.physics.gatech.edu) wrote:
Hi Slaven,
> Thank you for your reply...
>
> > > In short dvips, chokes on some eps files and gives error message
> > > which looks like this:
> > > user@localhost:~$ dvips -o tst.ps tst.dvi
> > > This is dvips(k) 5.86e Copyright 2001 Radical Eye Software
> > > (www.radicaleye.com)
> > > ' TeX output 2003.03.14:2210' -> tst.ps
> > > <texc.pro><special.pro>. [1<orbit0.ps>
> > > dvips: ! expected to see %%EndBinary at end of data
> > > peles@cvrle:~$
> >
> > Your EPS-File does not look very good. The lines are very long and
> > the ^M DOS-Enter signs are put in the middle of the lines. I guess,
> > the driver, who creates these files is not very good. Even gs dies,
> > when I try to display the file.
>
> I am sorry I sent you the wrong file. The right one is attached
> below and it is displayed by gs without any problems, but dvips
> rejects it.
>
Looks the same mad, but I'm not sure, if this could cause problems.
> The file is generated by Adobe Illustrator. I did some more
> 'research' after I submitted the bug report, and I found that
> Illustrator creates an incorrect byte counts someplace in the
> header of an eps figure (whatever that means). Newer versions of
> dvips apparently reject such figures. Here is the link where dvips
> author explains the problem:
> http://www.tug.org/pipermail/tex-k/2002-January/000405.html
> Similar stuff can also be found at:
> http://www.cds.caltech.edu/~ross/Adobe/AdobeBugs/node5.html
> Do you think it is possible that the same happens here?
>
Looks like this could be the case. The given patch fiddles around
with searching through the EPS-file and looking for strings like
"EndBinary" and "EndData".
My proposed temporary solution for you could be to process all
eps-Files from Adobe Illustrator after creation by gs, using someting
like
gs -dNOPAUSE -sDEVICE=epswrite -sOutputFile=orbit0-1.eps orbit0.eps -c quit
The resulting file is approx. 2.5 times smaller and without the
reported problem.
There are some perl scripts ate Thomas's site for fixing your EPS's.
Unfortunately I tried them and they doesn't help. Thomas reported in
the given URL, that the problem exists too for AI7.
> By the way, dvipdfm doesn't have a problem with this Illustrator
> generated file, and creates a nice pdf output.
>
Well, it's another program. Thomas explains, that AI doesn't behave
correctly, so I would rather file the bug againts AI, than dvips :-|.
> All I know is that any RH system we used so far (7.1-7.3) could
> process this file. Versions of tetex-dvips package on these systems
> range from 1.0.7-15 to 1.0.7-47.
>
Rather give me:
dvips --version .
Is there a README at Red Hat where the patch is mentioned or a
changelog in the RPM anywhere?
> I think there is a patch for dvips which fixes Illustrator problem.
> Maybe RH applies it to its dvips package?
>
Possible. I've applied the patch to the Debian dvips, compiled it
and....no success. Can you reproduce that? Unfortunately I didn't
apply the patch using patch, but rather applied it manually, cause I
was to dumb. Maybe I made then a mistake.
How about dvips from teTeX-2.0.2? Did anybody who runs unstable try
if dvips shows up the same problems?
> I guess I should have better said that this is the problem we have
> with Debian, but not with any of RH systems we have used so far. We
> have been working on a 1000+ pages book with a couple of hundred
> figures, and recently we decided to move from RH to Debian.
>
Never touch a running system :-).
Hilmar
BTW: Could you compress the files before sending them to the BTS?
--
sigmentation fault
Reply to: