Bug#63797: dvips produces bad postcript
Brian,
I think I see what you're talking about now -- I'm afraid I got
all caught up in the \overlay stuff, and overlooked the fact that
the problem you reported was related to the notes between slides.
Sorry about that.
Here's another example file that I *think* illustrates the problem
-- please let me know if I'm off base!
%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--
\documentclass{seminar}
\input{seminar.bug}
\input{seminar.bg2}
% We don't seem to need this package....
% \usepackage[dvips]{pstcol} % To use the standard `color' package with Seminar
\usepackage{semcolor}
\usepackage{semlayer}
\title{Example Slides}
\begin{document}
\begin{slide}
\section*{Debating}
\begin{itemize}
\item Point
\overlay{1}\item Counterpoint
\overlay{2}\item Rebuttal
\overlay{3}\item Reply
\overlay{4}\item Summation
\overlay{5}\item Judgement
\end{itemize}
Here are some notes.
%% Here's our problem line:
\overlay{6} And some final thoughts.
\end{slide}
\begin{note}
These notes appear outside the slide environment.
\end{note}
As do these.
\end{document}
%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--
Okay. If I TeX this file as is and convert it to PostScript, I
get the error you reported. If I enclose
\overlay{6}Here we have some additional notes.
in braces, ala
{\overlay{6}Here we have some additional notes.}
or if I enclose everything within the slide environment (or even
enclose the itemize environment *and* the \overlay{6} line) in
braces, I don't see the error.
What seems to be happening is that the scope of each \overlay
command is closed by the start of a new \overlay command except
for \overlay{5}, whose scope is closed by the \end{itemize}. I
would expect that the \overlay{6} command would be closed by the
\end{slide}, but that doesn't seem to be the case. That, I think,
is your bug.
When I look at the PostScript output, I see only one occurrence of
the tx@Dict stuff in the broken version. In the working (TeX
scoped) version, there are two, one immediately after the end of
the \overlay{6} text, and one just before the start of the next
page.
That suggests to me that the PostScript special code in the broken
version isn't being closed properly, and breaks when it tries to
cross the page (or something like that; a PostScript guru I am
not).
BM> I would have thought that as soon as the compiler hit the
BM> \end{slide} item, everything including the overlay should
BM> be reset.
Yes, I would have thought so, too, but apparently not.
BM> So, you're saying that \end{itemize} closes the current
BM> scope, but \end{slide} doesn't? (sorry about messing up
BM> with the formatting).
Yes, that seems to be exactly what's happening. I think I agree
with you that this is a bug in seminar (really in the semlayer.sty
file) that you could report to Denis Girou (<Denis.Girou@idris.fr>),
who seems to be the current maintainer.
I suspect, though, that he will point out that the problem is
caused by sloppy scoping on your part, since it goes away if you
deliberately scope each \overlay command with braces (or special
braces, such as the quote environment commented out in my
example).
BM> so perhaps you made a mistake in your example? Did you mean
BM> to scope the first \overlay command?
My example without braces was just an experiment to see if
dropping them would work. It does, so long as you don't try to
have any notes following the slide environment. It's not really
good coding practice, though.
BM> Now, nothing in the slide renders properly (it seems worse
BM> then before). Or, is it illegal to use \overlay{0} without
BM> an \overlay{1}?
\overlay{0} refers to the master slide; you don't actually need to
use the command at all (see my example in this message), but if
you do, you apparently have to have at least one additional
\overlay command to get it to work (to prevent it from blowing
up).
C> If you insert an additional \item command after the last
C> \overlay command, the last slide will have two items. (If
C> you insert text between the \end{itemize} and \end{slide}
C> commands, it will be discarded because that text is outside
C> the scope of the last \overlay command (which was closed by
C> \end{itemize}).)
BM> Wouldn't this text still be covered by \overlay{0}, which
BM> is still in scope?
I'm completely confused about what example we're talking about
here. But if we're talking about
\begin{slide}
{\overlay{0} What is Crashing?
\begin{itemize}
\overlay{1}\item Crashing is a bad thing.
\overlay{2}\item Why is crashing important?
\overlay{3}\item Working around crashes.
\item hab ah ah
\end{itemize}
Bah ha ha.}
La-di-da.
\end{slide}
both ``Bah ha ha.'' and ``La-di-da.'' end up on the first page,
even with the braces placed as shown. It looks like \overlay{0}
is pretty much ignored (at least in this example), and anything
not contained within the scope of another \overlay command ends up
on the first page.
BM> I am concerned that in saying this problem "is a problem
BM> with the tex input", you may be covering up a serious
BM> problem with tetex.
I agree that there may be a problem with the seminar package,
specifically with some part of the mechanism dealing with the
\overlay command and scoping. However, I don't think that there's
anything wrong with *teTeX*, per se -- the teTeX people aren't
responsible for bugs in LaTeX packages, the authors or maintainers
of those packages are.
BM> Besides, it is the PS file which has the error, so that
BM> would mean the error must propagate:
BM> tex ---> dvi ---> ps
BM> with no conversion step picking up on the error. Is this
BM> normal?
Yes, I think it's completely normal. What's happening is that the
TeX code in the seminar package files is creating PostScript
specials -- raw PostScript code that can only be handled by a
PostScript interpreter -- that have some problems. The PostScript
code is embedded in the DVI file and passed through intact (DVI
viewers can't handle PostScript specials, so they ignore them).
BM> Remember that the postscript error was that \BOL is
BM> undefined. Looking at the postscript code, \BOL is defined
BM> (I think) by pstricks. I suspect if you found the actual
BM> problem, it has nothing to do with scoping inside the LaTeX
BM> document, but incorrect scoping (or something) by the dvips
BM> driver (or maybe LaTeX specials) in the PS file.
Yes, I think that's exactly what's happening. PostScript code
that is repeated twice in a working file only appears once in a
broken file.
BM> Will investigate in more detail when I next get a chance.
Do, and report what you find to Denis Girou, and see what he says
(remember to include the word ``Seminar'' in the Subject line!).
Meanwhile, I guess the bug should stay open, although it should
probably be reassigned to tetex-nonfree, which is the source of
the semlayer.sty file. (Aside to Christoph: Maybe all the texmf
stuff should be in separate (non-teTeX) packages?)
Out of curiosity, which PostScript interpreter are you using? I
switched to Aladdin GhostScript recently (gs-aladdin, in non-free)
because the newer versions have better support for creating PDF
files (pstopdf doesn't turn fonts into bitmaps). (Not the version
included in potato, sadly, but at least I'm ready.)
CMC
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Behind the counter a boy with a shaven head stared vacantly into space,
a dozen spikes of microsoft protruding from the socket behind his ear.
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
C.M. Connelly c@eskimo.com SHC, DS
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Reply to: