Peter Riocreux wrote on 01 Mar 2001 15:49:45 +0000:
>
> When animating a picture using \stepwise
>
> 1. If a step contains elements that are of the form:
>
> {\color[rgb]{0,0,0}\put(whatever.......
>
> rather than
>
> \put(0,0){\color whatever
>
> Then each step moves *very* slightly to the right, so overlaying
> things of different colours fails. If you change all the statements to
> the second form, they do not move. I found this because xfig writes
> them in an order dependent on what you did with an object (i.e. if you
> changed its colour last, that will be the outermost term)
Could you post a simple example showing this effect?
The following:
------------------------------------------------------------
\documentclass{seminar}
\slideframe{none}
\usepackage{color}
\usepackage{fixseminar}
\usepackage[display]{texpower}
\begin{document}
\begin{slide}
\stepwise
{%
\begin{picture}(10,10)
\step{\color[rgb]{1,0,0}\put(5,5){\circle*{5}}}%
\step{\color[rgb]{1,0,0.1}\put(5,5){\circle*{5}}}%
\step{\color[rgb]{1,0,0.2}\put(5,5){\circle*{5}}}%
\step{\color[rgb]{1,0,0.3}\put(5,5){\circle*{5}}}%
\step{\color[rgb]{1,0,0.4}\put(5,5){\circle*{5}}}%
\step{\color[rgb]{1,0,0.5}\put(5,5){\circle*{5}}}%
\step{\color[rgb]{1,0,0.6}\put(5,5){\circle*{5}}}%
\step{\color[rgb]{1,0,0.7}\put(5,5){\circle*{5}}}%
\step{\color[rgb]{1,0,0.8}\put(5,5){\circle*{5}}}%
\step{\color[rgb]{1,0,0.9}\put(5,5){\circle*{5}}}%
\step{\color[rgb]{1,0,1}\put(5,5){\circle*{5}}}%
\end{picture}%
}
\end{slide}
\end{document}
------------------------------------------------------------
looks ok. But mind the % at the end of the lines, they
are indispensable. That's not a TeXPower problem,
however. The effect is the same when you delete the
\step's.
> 2. The last frame in an animation always moves a mm or two to the left
> for me.
Again, I'd like to see a small example.
> Also there is the
>
> Warning (ext1): destination with the same identifier (name{page.19}) already
exists!
> \new@pdflink ...Hy@SaveLastskip \pdfdest name {#1}
> \@pdfview
\[EMAIL PROTECTED]
>
> problem when animating - again this may not be texpower's fault, but
> it might be able to make the label based on the frame in an animation
> as well as the page number.
This is fixed in the current development version, which
will put an anchor page.xx on the _last_ page of a
sequence (like all anchors stemming from `normal'
labels), and an anchor firstpage.xx on the _first_
page of a sequence.
Would it make sense to put anchors page.xx.step.yy on
_every_ page?
> Lastly, when using powersem I get:
>
> (/home/teTeX-1.0/share/texmf/tex/latex/seminar/seminar.cls
> Document Class: seminar 1997/10/13, 1.4
> Document Style: `seminar' v1.4 <1997/10/13> (tvz)
> (/home/teTeX-1.0/share/texmf/tex/latex/koma-script/scrartcl.cls
> Document Class: scrartcl 1998/07/17 v2.5e LaTeX2e KOMA document class
> (/home/teTeX-1.0/share/texmf/tex/latex/base/size11.clo)
> (/home/teTeX-1.0/share/texmf/tex/latex/koma-script/typearea.sty
> Package: typearea, Copyright (C) Frank Neukam, 1992-1994
> Copyright (C) Markus Kohm, 1994-1997
>
> Package typearea Warning: Bad DIV-value!
> (typearea) You should decrease DIV, increase fontsize or
> (typearea) change papersize.
>
> ))
>
> Now from the nesting of the parens here I guess this is a seminar
> problem which manifests itself when use of the KOMA option means that
> scrartcl is used instaead of article.
>
> This is another where I am not sure whose problem it is (thinking
> further it may be a powersem bug actually, and therefore not in line
> for a fix.
I think the reason lies in the fact that seminar uses magnification
for enlarging type, which \typearea (the macro from KOMA-script which
calculates the margins) isn't informed about.
Actually, margin calculation would best be turned off because
seminar does it on its own anyway. That's something I won't
get around to doing for some time, but in the meantime, the
warning can safely be ignored, as it's inconsequential.
> I think also
> that it should perhaps be a style instead of a class, minimising what
> has to be written, and maximising portability.
I don't agree. All derivatives of seminar will have to
retain a custom output routine, and this is something which
has to go in a class IMO.
There are some packages already which might do exactly what
you have in mind, like pdfscreen and ifmslide; I don't see
a sense in adding another one.
Furthermore, you can `plug in' an arbitrary `base class'
into powersem by selecting the KOMA option and defining
the macro \baseclass accordingly (I use
\newcommand{\baseclass}{scrreprt} to get chapters), but
powersem assumes it can redefine everything at will, and
if anything breaks, you're on your own.
> The \centerslides was a red herring here, as that *can* be done as you
> suggest, but AFAICT, you cannot replace:
>
> \documentclass[display]{powersem}
>
> with
>
> \documentclass{powersem}
> \display
I'm not sure this is a good idea. At least, it's not
trivial. A lot of code is defined differently at loading
of powersem and texpower, depending on whether or not
the display option is given.
Putting this into a command may break things big time.
> I want to wrap the \display inside \ifpdf.
You can say
\ifpdf\PassOptionsToClass{display}{powersem}\fi
regards
Stephan
--
Stephan Lehmke [EMAIL PROTECTED]
Fachbereich Informatik, LS I Tel. +49 231 755 6434
Universitaet Dortmund FAX 6555
D-44221 Dortmund, Germany
