Bug 8085 - mpage screws included figures. Bad since used by lpr...
Summary: mpage screws included figures. Bad since used by lpr...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: mpage
Version: 6.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-12-31 16:11 UTC by cardoso
Modified: 2008-05-01 15:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-10-20 20:02:44 UTC
Embargoed:


Attachments (Terms of Use)

Description cardoso 1999-12-31 16:11:25 UTC
mpage gives errors when applied to a TeX-generated ps file which
includes Postscript figures (using, e.g. epsf or psfig from within Tex).

This is bad since mpage is invoked by the printing system itself
to print multiple pages per sheet.

The problem shows in Ghostview and on the printer.  The error message from
Ghostview is appended below.  Even the simplest invocation

	  mpage -1 f.eps

will give trouble.  A one-page example can be provided
upon request.
I am using mpage 2.4 distributed with Red Hat Linux 6.1.


===================================================

Message from ghostview:

Error: /invalidrestore in --restore--
Operand stack:
   --nostringval--   --nostringval--

Execution stack:
   %interp_exit .runexec2 --nostringval-- --nostringval--
   %--nostringval-- 2 %stopped_push --nostringval-- --nostringval--
   %--nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3
   %%oparray_pop .runexec2 --nostringval-- --nostringval--
   %--nostringval-- 2 %stopped_push --nostringval-- 1 5 %oparray_pop
   %--nostringval-- 1 5 %oparray_pop --nostringval-- --nostringval--
   %--nostringval--

Dictionary stack:
   --dict:933/983(ro)(G)-- --dict:0/20(G)-- --dict:63/200(L)--
   --dict:122/300(L)-- --dict:16/200(L)--
Current allocation mode is local
Current file position is 44588
Aladdin Ghostscript BETA RELEASE 5.97: Unrecoverable error, exit code 1

Comment 1 Bill Nottingham 2000-02-16 21:23:59 UTC
Can you give us an example postscript file that does this?

Comment 2 starback 2000-05-08 15:32:59 UTC
I also have problems printing TeX files with included eps files.
Here is a test script:

---------------------------------
#! /bin/sh
# Argument is eps file to test.
BASE=`basename $1 .eps`
cat >$BASE.tex <<EOF
\documentclass{article}
\usepackage{epsfig}
\begin{document}
\epsfig{file=$1}
\end{document}
EOF

latex $BASE.tex
dvips $BASE.dvi -o $BASE.ps
mpage $BASE.ps >mpage-$BASE.ps
----------------------------------------

The argument to this script should be an eps file.  For many
(but not all) input files I get an invalidrestore error when
running gs on the genereated mpage-BASE.ps file
(but not on the BASE.ps file).

One example is:

$ sh test.sh /usr/share/texmf/doc/latex/rotating/cat.eps
$ gs mpage-cat.ps

I get the cat, but also

---------------------------------------------------
GNU Ghostscript 5.50 (2000-2-13)
Copyright (C) 1998 Aladdin Enterprises, Menlo Park, CA.  All rights reserved.
This software comes with NO WARRANTY: see the file COPYING for details.
Loading NimbusMonL-Regu font from /usr/share/fonts/default/Type1/n022003l.pfb...
1923476 602544 1329168 32286 0 done.
Loading NimbusRomNo9L-Medi font from
/usr/share/fonts/default/Type1/n021004l.pfb... 1983752 655712 1329168 37260 0
done.
Error: /invalidrestore in --restore--
Operand stack:
   --nostringval--   --nostringval--
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--
--nostringval--   2   %stopped_push   --nostringval--   2   3   %oparray_pop
--nostringval--   --nostringval--   false   1   %stopped_push   1   3
%oparray_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--
2   %stopped_push   --nostringval--   1   6   %oparray_pop   --nostringval--
1   6   %oparray_pop   --nostringval--   --nostringval--   --nostringval--
Dictionary stack:
   --dict:912/941(G)--   --dict:0/20(G)--   --dict:62/200(L)--
--dict:113/300(L)--   --dict:44/200(L)--   --dict:172/300(L)--
Current allocation mode is local
Current file position is 28624
GS<1>

------------------------------------------------------------

Note that "gs cat.ps" doesn't yield any errors.  Neither does
"gs /usr/share/texmf/doc/latex/rotating/cat.eps".

That eps file is from tetex-doc-1.0.6-11.  Incidentally the other eps file
in it (roadmap.eps) works fine.  Every test I've made by exporting to eps
from xfig has yielded invalidrestore error.

I use ghostscript-5.50-1, mpage-2.4-8, tetex-1.0.6-11,
tetex-dvips-1.0.6-11, tetex-latex-1.0.6-11.

Comment 3 Bill Nottingham 2000-06-10 19:41:41 UTC
This should be fixed in mpage-2.5.1-1, which will be
in the next rawhide release.

Comment 4 starback 2000-06-21 16:01:08 UTC
I'd like to reopen this.  Here is an example that still doesn't work, and that
I think is the same bug:

---start test.tex ---8<-----------
\documentclass{article}
\usepackage{epsfig}
\begin{document}

\begin{tabular}{cc}
\epsfig{file=/usr/share/texmf/doc/latex/rotating/cat.eps}
&
\epsfig{file=/usr/share/texmf/doc/fontinst/base/roadmap.eps}
\end{tabular}
\end{document}
----end test.tex--8<----

Do
$ latex test.tex
$ dvips -o test.ps test.dvi
$ mpage test.ps >mpage-test.ps

Now,
$ gs test.ps
shows a cat looking at an impressive graph.
But
$ gs mpage-test.ps
shows a lonely cat without anything to look at. Poor cat.

No error messages this time though, but I assume this is the same bug
or at least related, since it seems like there's some property of the first
(left) eps that triggers the bug, and that property is the same or similar to
the property that triggered the earlier reported form of the bug.

(In this example I used tetex*-1.0.6-11, mpage-2.5.1-1, ghostscript-5.50-1.)



Comment 5 David Lawrence 2000-07-31 15:20:58 UTC
Reopened at the request of starback.uu.se.

Comment 6 starback 2000-12-01 21:35:52 UTC
(The previous comment is still true for mpage-2.5.1-2 and
ghostscript-5.50-8_6.x.)

Here is another example of mpage destroying included eps, using only one eps.  I
suppose it's
the same bug, but maybe this is easier to get something from.  I don't know.

bug.tex contains

  \documentclass{article} 
  \usepackage{epsfig}
  \begin{document}
  \begin{center}
  \epsfig{file=bug.eps}
  \end{center}
  \end{document}

and bug.eps contains
----8<------
#FIG 3.2
Landscape
Center
Inches
Letter  
100.00
Single
-2
1200 2
6 1275 2175 2775 2775
2 2 0 1 0 0 50 0 -1 4.000 0 0 -1 0 0 5
	 1275 2175 2775 2175 2775 2775 1275 2775 1275 2175
4 0 0 50 0 12 14 0.0000 4 135 1215 1425 2550 Documents\001
-6
6 1050 750 1425 3150
6 1050 750 1425 3150
2 1 0 1 0 0 50 0 -1 4.000 0 0 -1 0 0 2
	 1425 750 1050 750
2 1 0 1 0 0 50 0 -1 4.000 0 0 -1 0 0 2
	 1050 750 1050 3150
2 1 0 1 0 0 50 0 -1 4.000 0 0 -1 0 0 2
	 1425 3150 1050 3150
-6
-6
6 3825 1200 6000 2550
2 2 0 1 0 0 50 0 -1 4.000 0 0 -1 0 0 5
	 3825 1200 6000 1200 6000 2550 3825 2550 3825 1200
4 0 0 50 0 14 14 0.0000 4 135 1215 4275 1950 Processor\001
-6
2 1 0 1 0 0 50 0 -1 4.000 0 0 -1 1 0 2
	1 1 1.00 60.00 120.00
	 2775 2475 3825 1875
2 1 0 1 0 0 50 0 -1 4.000 0 0 -1 1 0 2
	1 1 1.00 60.00 120.00
	 2475 1275 3825 1875
2 1 0 1 0 0 50 0 -1 4.000 0 0 -1 1 0 2
	1 1 1.00 60.00 120.00
	 6000 1875 6975 1875
2 1 1 1 0 0 50 0 -1 4.000 0 0 -1 1 0 4
	1 1 1.00 60.00 120.00
	 6675 1875 6675 525 1950 525 1950 1125
4 0 0 50 0 12 14 0.0000 4 180 945 1500 1350 Queries\001
4 0 0 50 0 12 14 0.0000 4 150 1080 4050 450 Feedback\001
4 0 0 50 0 14 14 0.0000 4 195 675 225 1950 Input\001
4 0 0 50 0 14 14 0.0000 4 195 810 7050 1950 Output\001
-------8<-----------

Using tetex*-1.0.6-11 I do

  $ latex bug.tex
  $ dvips -o bug.ps bug.dvi
and with mpage-2.5.1-2 I do
   $ mpage -1 bug.ps >bug-mpage.ps

Now "gs bug.ps" and "gs bug-mpage.ps" gives very different results.

The first one gives a figure approximately at the top of the window.
When I press return to ">>showpage, press <return> to continue<<" I get
the "GS>" prompter.

"gs bug-mpage.ps" yields a blank page.  Typing return gives me a page where that
same figure is mirrored, and at the bottom of the page.

I expected the results to look very similar. (I don't know if there are problems
with that eps file.)



Comment 7 Tim Waugh 2002-10-20 20:02:37 UTC
I think this might actually be fixed in 2.5.3-1 in rawhide.


Note You need to log in before you can comment on or make changes to this bug.