Überarbeitungsverlauf[Zurück]
|
6 |
|
|
Wie @huibub bereits in seinen Kommentaren richtig bemerkt hat, darf bei TeX das Ergebnis einer arithmetischen Operation maximal `\maxdimen` groß sein. `\maxdimen` ist 16383.99999pt. Dieser Wert wird bei dir bereits auf Frame 45 (und nicht erst auf Frame 90, wie in der Fragestellung behauptet) überschritten. Eine einfache Lösung wäre nun, am Anfang nicht mit der Hälfe der Papierbreite zu rechnen und diese dann am Ende per `\progressbar@tempdim=2\progressbar@tempdim` wieder auf die ganze Papierbreite zu erhöhen, sondern mit einem wesentlich kleineren Anteil zu arbeiten.
Zusätzlich wäre theoretisch in der Tat zu empfehlen, erst durch die Gesamtzahl der Frames zu dividieren und dann mit der aktuellen Framenummer zu multiplizieren. Leider hat das am Ende dann keine Auswirkungen, weil, wie @huibub ebenfalls in seinen Kommentaren richtig bemerkt, `\inserttotalframenumber` im ersten LaTeX-Lauf natürlich noch nicht die Gesamtzahl der Frames liefert.
Das Problem mit dem zu kleinen `\inserttotalframenumber` kann man einfach lösen, indem man testet, ob `\inserttotalframenumber` größer oder gleich `\value{framenumber}` ist, was es ja immer sein sollte. Anderenfalls ist die Progressbar ohnehin ungültig und braucht überhaupt nicht mehr (oder alternativ nur mit voller Länge) gezeichnet zu werden. An dieser Stelle sei auch darauf hingewiesen, dass `\insertframenumber` nicht unbedingt der Weisheit letzter Schluss für die Verwendung in einer Berechnung ist. Ich werde daher stattdessen direkt den Zähler `frame` Frame-Zähler `framenumber` verwenden. Kombiniert man das nun mit dem Vertauschen der Operationen ist sichergestellt, dass kein zu großes Zwischenergebnis Zwischen- oder Endergebnis vorkommt und man kann sich die Halbierung aus dem Originalcode sogar ganz sparen.
\documentclass{beamer}
\usepackage{tikz}
\definecolor{pbbg}{RGB}{0,122,59}% filling color for the progress bar
\definecolor{pbfill}{RGB}{0,122,59}% background color for the progress bar
\makeatletter
\def\progressbar@progressbar{} % the progress bar
\newdimen\progressbar@pbht %progressbar height
\newdimen\progressbar@pbwd %progressbar width
\newdimen\progressbar@tmpdim % auxiliary dimension
\progressbar@pbwd=\paperwidth
\progressbar@pbht=0.5ex
% the progress bar
\def\progressbar@progressbar{%
% Die Progressbar ergibt nur Sinn, wenn \inserttotalframenumber > \value{framenumber} ist
\expandafter\ifnum \value{framenumber}>\number\inserttotalframenumber\relax\else
\progressbar@tmpdim=\progressbar@pbwd
\divide\progressbar@tmpdim by \number\inserttotalframenumber\relax
\multiply\progressbar@tmpdim by \value{framenumber}
\begin{tikzpicture}[rounded corners=1.5pt,very thin]
\shade[top color=pbbg!20,bottom color=pbbg!20,middle color=pbbg!50]
(0pt, 0pt) rectangle ++ (\progressbar@pbwd, \progressbar@pbht);
\shade[draw=pbfill,top color=pbfill!50,bottom color=pbfill!50,middle color=pbfill] %
(0pt, 0pt) rectangle ++ (\progressbar@tmpdim, \progressbar@pbht);
\draw[color=normal text.fg!50]
(0pt, 0pt) rectangle (\progressbar@pbwd, \progressbar@pbht)
node[pos=0.5,color=normal text.fg] {\textnormal{%
}%
};
\end{tikzpicture}%
\fi
}
\addtobeamertemplate{footline}
{%
\begin{beamercolorbox}[wd=\paperwidth,ht=2.0ex,center,dp=0ex]{white}%
\progressbar@progressbar%
\end{beamercolorbox}%
}
\makeatother
\begin{document}
\foreach \x in {1,2,...,90} {\begin{frame}[label=test\x]{My frame}
Test \x
\end{frame}}
\end{document}
Es sei darauf hingewiesen dass es auch einen Nachteil dieser Lösung gibt. Sobald sich die Anzahl der Frames der Breite der Frames in `sp` annähert, wird die Rechenungenauigkeit von TeX so groß, dass der Fortschrittbalken durch die Rundung zu kurz wird und letztlich auf 0 stehen bleibt. Das dürfte bei Präsentationen aber eine eher theoretische Beschränkung sein, da ich schon Frame-Zahlen über den im Bereich der in der Frage fälschlich angegebenen Grenze von 90 für eher unüblich hoch halte. Präsentationen mit mehreren tausend Frames dürften in freier Wildbahn kaum vorkommen.
Übrigens ist auch die @huibub's Frage berechtigt, warum man die Berechnung nicht gleich mit `pgf` selbst durchführt. Ich habe nur gerade keine Zeit, mich mit einer entsprechenden Lösung zu beschäftigen.
Mit dem ebenfalls von @huibub gemeldeten Problem der *`destination with the same identifier`* habe ich mich ebenfalls befasst. Man kann einfach nicht auf jedem Frame Option `label` mit demselben Wert verwenden. Das ist schlicht Unfug.sinnloser Unfug. Der Informationsgehalt ist dann nicht besser als bei Weglassen des Labels. Ich habe stattdessen ein eigentlich ebenfalls sinnloses, eindeutiges Label gesetzt – sinnlos deshalb, weil man eigentlich kein Label mit der Labelnummer im Namen braucht, um die Labelnummer zu bestimmen. :-O
|
|
5 |
|
|
Wie @huibub bereits in seinen Kommentaren richtig bemerkt hat, darf bei TeX das Ergebnis einer arithmetischen Operation maximal `\maxdimen` groß sein. `\maxdimen` ist 16383.99999pt. Dieser Wert wird bei dir bereits auf Frame 45 (und nicht erst auf Frame 90, wie in der Fragestellung behauptet) überschritten. Eine einfache Lösung wäre nun, am Anfang nicht mit der Hälfe der Papierbreite zu rechnen und diese dann am Ende per `\progressbar@tempdim=2\progressbar@tempdim` wieder auf die ganze Papierbreite zu erhöhen, sondern mit einem wesentlich kleineren Anteil zu arbeiten.
Zusätzlich wäre theoretisch in der Tat zu empfehlen, erst durch die Gesamtzahl der Frames zu dividieren und dann mit der aktuellen Framenummer zu multiplizieren. Leider hat das am Ende dann keine Auswirkungen, weil, wie @huibub ebenfalls in seinen Kommentaren richtig bemerkt, `\inserttotalframenumber` im ersten LaTeX-Lauf natürlich noch nicht die Gesamtzahl der Frames liefert.
Das Problem mit dem zu kleinen `\inserttotalframenumber` kann man einfach lösen, indem man testet, ob `\inserttotalframenumber` größer oder gleich `\value{framenumber}` ist, was es ja immer sein sollte. Anderenfalls ist die Progressbar ohnehin ungültig und braucht überhaupt nicht mehr (oder alternativ nur mit voller Länge) gezeichnet zu werden. An dieser Stelle sei auch darauf hingewiesen, dass `\insertframenumber` nicht unbedingt der Weisheit letzter Schluss für die Verwendung in einer Berechnung ist. Ich werde daher stattdessen direkt den Zähler `frame` verwenden. Kombiniert man das nun mit dem Vertauschen der Operationen ist sichergestellt, dass kein zu großes Zwischenergebnis vorkommt und man kann sich die Halbierung aus dem Originalcode sogar ganz sparen.
\documentclass{beamer}
\usepackage{tikz}
\definecolor{pbbg}{RGB}{0,122,59}% filling color for the progress bar
\definecolor{pbfill}{RGB}{0,122,59}% background color for the progress bar
\makeatletter
\def\progressbar@progressbar{} % the progress bar
\newdimen\progressbar@pbht %progressbar height
\newdimen\progressbar@pbwd %progressbar width
\newdimen\progressbar@tmpdim % auxiliary dimension
\progressbar@pbwd=\paperwidth
\progressbar@pbht=0.5ex
% the progress bar
\def\progressbar@progressbar{%
% Die Progressbar ergibt nur Sinn, wenn \inserttotalframenumber > \value{framenumber} ist
\expandafter\ifnum \value{framenumber}>\number\inserttotalframenumber\relax\else
\progressbar@tmpdim=\progressbar@pbwd
\divide\progressbar@tmpdim by \number\inserttotalframenumber\relax
\multiply\progressbar@tmpdim by \value{framenumber}
\begin{tikzpicture}[rounded corners=1.5pt,very thin]
\shade[top color=pbbg!20,bottom color=pbbg!20,middle color=pbbg!50]
(0pt, 0pt) rectangle ++ (\progressbar@pbwd, \progressbar@pbht);
\shade[draw=pbfill,top color=pbfill!50,bottom color=pbfill!50,middle color=pbfill] %
(0pt, 0pt) rectangle ++ (\progressbar@tmpdim, \progressbar@pbht);
\draw[color=normal text.fg!50]
(0pt, 0pt) rectangle (\progressbar@pbwd, \progressbar@pbht)
node[pos=0.5,color=normal text.fg] {\textnormal{%
}%
};
\end{tikzpicture}%
\fi
}
\addtobeamertemplate{footline}
{%
\begin{beamercolorbox}[wd=\paperwidth,ht=2.0ex,center,dp=0ex]{white}%
\progressbar@progressbar%
\end{beamercolorbox}%
}
\makeatother
\begin{document}
\foreach \x in {1,2,...,90} {\begin{frame}[label=test]{My {\begin{frame}[label=test\x]{My frame}
Test \x
\end{frame}}
\end{document}
Es sei darauf hingewiesen dass es auch einen Nachteil dieser Lösung gibt. Sobald sich die Anzahl der Frames der Breite der Frames in `sp` annähert, wird die Rechenungenauigkeit von TeX so groß, dass der Fortschrittbalken durch die Rundung zu kurz wird und letztlich auf 0 stehen bleibt. Das dürfte bei Präsentationen aber eine eher theoretische Beschränkung sein, da ich schon Frame-Zahlen über den in der Frage fälschlich angegebenen Grenze von 90 für eher unüblich hoch halte. Präsentationen mit mehreren tausend Frames dürften in freier Wildbahn kaum vorkommen.
Übrigens ist auch die Frage berechtigt, warum man die Berechnung nicht gleich mit `pgf` selbst durchführt. Ich habe nur gerade keine Zeit, mich mit einer entsprechenden Lösung zu beschäftigen.
Mit dem ebenfalls von @huibub gemeldeten Problem der *`destination with the same identifier`* habe ich mich ebenfalls befasst. Man kann einfach nicht weiter befasst, da es nicht Teil der Frage war und trotz des Hinweises von @huibub auch nicht bei der kürzlichen Änderung der Frage in diese aufgenommen wurde. Sollte das für dich trotzdem ein Problem sein, kannst du gerne eine neue Frage dazu stellen.auf jedem Frame Option `label` mit demselben Wert verwenden. Das ist schlicht Unfug.
|
|
4 |
|
|
Wie @huibub bereits in seinen Kommentaren richtig bemerkt hat, darf bei TeX das Ergebnis einer arithmetischen Operation maximal `\maxdimen` groß sein. `\maxdimen` ist 16383.99999pt. Dieser Wert wird bei dir bereits auf Frame 45 (und nicht erst auf Frame 90, wie in der Fragestellung behauptet) überschritten. Eine einfache Lösung wäre nun, am Anfang nicht mit der Hälfe der Papierbreite zu rechnen und diese dann am Ende per `\progressbar@tempdim=2\progressbar@tempdim` wieder auf die ganze Papierbreite zu erhöhen, sondern mit einem wesentlich kleineren Anteil zu arbeiten.
Zusätzlich wäre theoretisch in der Tat zu empfehlen, erst durch die Gesamtzahl der Frames zu dividieren und dann mit der aktuellen Framenummer zu multiplizieren. Leider hat das am Ende dann keine Auswirkungen, weil, wie @huibub ebenfalls in seinen Kommentaren richtig bemerkt, `\inserttotalframenumber` im ersten LaTeX-Lauf natürlich noch nicht die Gesamtzahl der Frames liefert.
Das Problem mit dem zu kleinen `\inserttotalframenumber` kann man einfach lösen, indem man testet, ob `\inserttotalframenumber` größer oder gleich `\value{framenumber}` ist, was es ja immer sein sollte. Anderenfalls ist die Progressbar ohnehin ungültig und braucht überhaupt nicht mehr (oder alternativ nur mit voller Länge) gezeichnet zu werden. An dieser Stelle sei auch darauf hingewiesen, dass `\insertframenumber` nicht unbedingt der Weisheit letzter Schluss für die Verwendung in einer Berechnung ist. Ich werde daher stattdessen direkt den Zähler `frame` verwenden. Kombiniert man das nun mit dem Vertauschen der Operationen ist sichergestellt, dass kein zu großes Zwischenergebnis vorkommt und man kann sich die Halbierung aus dem Originalcode sogar ganz sparen.
\documentclass{beamer}
\usepackage{tikz}
\definecolor{pbbg}{RGB}{0,122,59}% filling color for the progress bar
\definecolor{pbfill}{RGB}{0,122,59}% background color for the progress bar
\makeatletter
\def\progressbar@progressbar{} % the progress bar
\newdimen\progressbar@pbht %progressbar height
\newdimen\progressbar@pbwd %progressbar width
\newdimen\progressbar@tmpdim % auxiliary dimension
\progressbar@pbwd=\paperwidth
\progressbar@pbht=0.5ex
% the progress bar
\def\progressbar@progressbar{%
% Die Progressbar ergibt nur Sinn, wenn \inserttotalframenumber > \value{framenumber} ist
\expandafter\ifnum \value{framenumber}>\number\inserttotalframenumber\relax\else
\progressbar@tmpdim=\progressbar@pbwd
\divide\progressbar@tmpdim by \number\inserttotalframenumber\relax
\multiply\progressbar@tmpdim by \value{framenumber}
\begin{tikzpicture}[rounded corners=1.5pt,very thin]
\shade[top color=pbbg!20,bottom color=pbbg!20,middle color=pbbg!50]
(0pt, 0pt) rectangle ++ (\progressbar@pbwd, \progressbar@pbht);
\shade[draw=pbfill,top color=pbfill!50,bottom color=pbfill!50,middle color=pbfill] %
(0pt, 0pt) rectangle ++ (\progressbar@tmpdim, \progressbar@pbht);
\draw[color=normal text.fg!50]
(0pt, 0pt) rectangle (\progressbar@pbwd, \progressbar@pbht)
node[pos=0.5,color=normal text.fg] {\textnormal{%
}%
};
\end{tikzpicture}%
\fi
}
\addtobeamertemplate{footline}
{%
\begin{beamercolorbox}[wd=\paperwidth,ht=2.0ex,center,dp=0ex]{white}%
\progressbar@progressbar%
\end{beamercolorbox}%
}
\makeatother
\begin{document}
\foreach \x in {1,2,...,90} {\begin{frame}[label=test]{My frame}
Test \x
\end{frame}}
\end{document}
Es sei darauf hingewiesen dass es auch einen Nachteil dieser Lösung gibt. Sobald sich die Anzahl der Frames der Breite der Frames in `sp` annähert, wird die Rechenungenauigkeit von TeX so groß, dass der Fortschrittbalken durch die Rundung zu kurz wird und letztlich auf 0 stehen bleibt. Das dürfte bei Präsentationen aber eine eher theoretische Beschränkung sein, da ich schon Frame-Zahlen über den in der Frage fälschlich angegebenen Grenze von 90 für eher unüblich hoch halte. Präsentationen mit mehreren tausend Frames dürften in freier Wildbahn kaum vorkommen.
Übrigens ist auch die Frage berechtigt, warum man die Berechnung nicht gleich mit `pgf` selbst durchführt. Ich habe nur gerade keine Zeit, mich mit einer entsprechenden Lösung zu beschäftigen.
Mit dem ebenfalls von @huibub gemeldeten Problem der *`destination with the same identifier`* habe ich mich nicht weiter befasst, da es nicht Teil der Frage war und trotz des Hinweises von @huibub auch nicht bei der kürzlichen Änderung der Frage in diese aufgenommen wurde. Sollte das für dich trotzdem ein Problem sein, kannst du gerne eine neue Frage dazu stellen.
|
|
3 |
|
|
Wie @huibub bereits in seinen Kommentaren richtig bemerkt hat, darf bei TeX das Ergebnis einer arithmetischen Operation maximal `\maxdimen` groß sein. `\maxdimen` ist 16383.99999pt. Dieser Wert wird bei dir bereits auf Frame 45 (und nicht erst auf Frame 90, wie in der Fragestellung behauptet) überschritten. Eine einfache Lösung wäre nun, am Anfang nicht mit der Hälfe der Papierbreite zu rechnen und diese dann am Ende per `\progressbar@tempdim=2\progressbar@tempdim` wieder auf die ganze Papierbreite zu erhöhen, sondern mit einem wesentlich kleineren Anteil zu arbeiten.
Zusätzlich wäre theoretisch in der Tat zu empfehlen, erst durch die Gesamtzahl der Frames zu dividieren und dann mit der aktuellen Framenummer zu multiplizieren. Leider hat das am Ende dann keine Auswirkungen, weil, wie @huibub ebenfalls in seinen Kommentaren richtig bemerkt, `\inserttotalframenumber` im ersten LaTeX-Lauf natürlich noch nicht die Gesamtzahl der Frames liefert.
Das Problem mit dem zu kleinen `\inserttotalframenumber` kann man einfach lösen, indem man testet, ob '\inserttotalframenumber' `\inserttotalframenumber` größer oder gleich `\value{framenumber}` ist. ist, was es ja immer sein sollte. Anderenfalls ist die Progressbar ohnehin ungültig und braucht überhaupt nicht mehr (oder alternativ nur mit voller Länge) gezeichnet zu werden. An dieser Stelle sei auch darauf hingewiesen, dass `\insertframenumber` nicht unbedingt der Weisheit letzter Schluss für die Verwendung in einer Berechnung ist. Ich werde daher stattdessen direkt den Zähler `frame` verwenden. Kombiniert man das nun mit dem Vertauschen der Operationen ist sichergestellt, dass kein zu großes Zwischenergebnis vorkommt und man kann sich die Halbierung aus dem Originalcode sogar ganz sparen.
\documentclass{beamer}
\usepackage{tikz}
\definecolor{pbbg}{RGB}{0,122,59}% filling color for the progress bar
\definecolor{pbfill}{RGB}{0,122,59}% background color for the progress bar
\makeatletter
\def\progressbar@progressbar{} % the progress bar
\newdimen\progressbar@pbht %progressbar height
\newdimen\progressbar@pbwd %progressbar width
\newdimen\progressbar@tmpdim % auxiliary dimension
\progressbar@pbwd=\paperwidth
\progressbar@pbht=0.5ex
% the progress bar
\def\progressbar@progressbar{%
% Die Progressbar ergibt nur Sinn, wenn \inserttotalframenumber > \value{framenumber} ist
\expandafter\ifnum \value{framenumber}>\number\inserttotalframenumber\relax\else
\progressbar@tmpdim=\progressbar@pbwd
\divide\progressbar@tmpdim by \number\inserttotalframenumber\relax
\multiply\progressbar@tmpdim by \value{framenumber}
\begin{tikzpicture}[rounded corners=1.5pt,very thin]
\shade[top color=pbbg!20,bottom color=pbbg!20,middle color=pbbg!50]
(0pt, 0pt) rectangle ++ (\progressbar@pbwd, \progressbar@pbht);
\shade[draw=pbfill,top color=pbfill!50,bottom color=pbfill!50,middle color=pbfill] %
(0pt, 0pt) rectangle ++ (\progressbar@tmpdim, \progressbar@pbht);
\draw[color=normal text.fg!50]
(0pt, 0pt) rectangle (\progressbar@pbwd, \progressbar@pbht)
node[pos=0.5,color=normal text.fg] {\textnormal{%
}%
};
\end{tikzpicture}%
\fi
}
\addtobeamertemplate{footline}
{%
\begin{beamercolorbox}[wd=\paperwidth,ht=2.0ex,center,dp=0ex]{white}%
\progressbar@progressbar%
\end{beamercolorbox}%
}
\makeatother
\begin{document}
\foreach \x in {1,2,...,90} {\begin{frame}[label=test]{My frame}
Test \x
\end{frame}}
\end{document}
Es sei darauf hingewiesen dass es auch einen Nachteil dieser Lösung gibt. Sobald sich die Anzahl der Frames der Breite der Frames in `sp` annähert, wird die Rechenungenauigkeit von TeX so groß, dass der Fortschrittbalken durch die Rundung zu kurz wird und letztlich auf 0 stehen bleibt. Das dürfte bei Präsentationen aber eine eher theoretische Beschränkung sein, da ich schon Frame-Zahlen über den in der Frage fälschlich angegebenen Grenze von 90 für eher unüblich hoch halte. Präsentationen mit mehreren tausend Frames dürften in freier Wildbahn kaum vorkommen.
Übrigens ist auch die Frage berechtigt, warum man die Berechnung nicht gleich mit `pgf` selbst durchführt. Ich habe nur gerade keine Zeit, mich mit einer entsprechenden Lösung zu beschäftigen.beschäftigen.
Mit dem ebenfalls von @huibub gemeldeten Problem der *`destination with same identifier`* habe ich mich nicht weiter befasst, da es nicht Teil der Frage war und trotz des Hinweises von @huibub auch nicht bei der kürzlichen Änderung der Frage in diese aufgenommen wurde. Sollte das für dich trotzdem ein Problem sein, kannst du gerne eine neue Frage dazu stellen.
|
|
2 |
|
|
Wie @huibub bereits in seinen Kommentaren richtig bemerkt hat, darf bei TeX das Ergebnis einer arithmetischen Operation maximal `\maxdimen` groß sein. `\maxdimen` ist 16383.99999pt. Dieser Wert wird bei dir bereits auf Frame 45 (und nicht erst auf Frame 90, wie in der Fragestellung behauptet) überschritten. Eine einfache Lösung wäre nun, am Anfang nicht mit der Hälfe der Papierbreite zu rechnen und diese dann am Ende per `\progressbar@tempdim=2\progressbar@tempdim` wieder auf die ganze Papierbreite zu erhöhen, sondern mit einem wesentlich kleineren Anteil zu arbeiten.
Zusätzlich wäre theoretisch in der Tat zu empfehlen, erst durch die Gesamtzahl der Frames zu dividieren und dann mit der aktuellen Framenummer zu multiplizieren. Leider hat das am Ende dann keine Auswirkungen, weil, wie @huibub ebenfalls in seinen Kommentaren richtig bemerkt, `\inserttotalframenumber` im ersten LaTeX-Lauf natürlich noch nicht die Gesamtzahl der Frames liefert.
Das Problem mit dem zu kleinen `\inserttotalframenumber` kann man einfach lösen, indem man testet, ob '\inserttotalframenumber' größer oder gleich `\value{framenumber}` ist. An dieser Stelle sei auch darauf hingewiesen, dass `\insertframenumber` nicht unbedingt der Weisheit letzter Schluss für die Verwendung in einer Berechnung ist. Ich werde daher stattdessen direkt den Zähler `frame` verwenden. Kombiniert man das nun mit dem Vertauschen der Operationen ist sichergestellt, dass kein zu großes Zwischenergebnis vorkommt und man kann sich die Halbierung aus dem Originalcode sogar ganz sparen.
\documentclass{beamer}
\usepackage{tikz}
\definecolor{pbbg}{RGB}{0,122,59}% filling color for the progress bar
\definecolor{pbfill}{RGB}{0,122,59}% background color for the progress bar
\makeatletter
\def\progressbar@progressbar{} % the progress bar
\newdimen\progressbar@pbht %progressbar height
\newdimen\progressbar@pbwd %progressbar width
\newdimen\progressbar@tmpdim % auxiliary dimension
\progressbar@pbwd=\paperwidth
\progressbar@pbht=0.5ex
% the progress bar
\def\progressbar@progressbar{%
% Die Progressbar ergibt nur Sinn, wenn \inserttotalframenumber > \value{framenumber} ist
\expandafter\ifnum \value{framenumber}>\number\inserttotalframenumber\relax\else
\progressbar@tmpdim=\progressbar@pbwd
\divide\progressbar@tmpdim by \number\inserttotalframenumber\relax
\multiply\progressbar@tmpdim by \value{framenumber}
\begin{tikzpicture}[rounded corners=1.5pt,very thin]
\shade[top color=pbbg!20,bottom color=pbbg!20,middle color=pbbg!50]
(0pt, 0pt) rectangle ++ (\progressbar@pbwd, \progressbar@pbht);
\shade[draw=pbfill,top color=pbfill!50,bottom color=pbfill!50,middle color=pbfill] %
(0pt, 0pt) rectangle ++ (\progressbar@tmpdim, \progressbar@pbht);
\draw[color=normal text.fg!50]
(0pt, 0pt) rectangle (\progressbar@pbwd, \progressbar@pbht)
node[pos=0.5,color=normal text.fg] {\textnormal{%
}%
};
\end{tikzpicture}%
\fi
}
\addtobeamertemplate{footline}
{%
\begin{beamercolorbox}[wd=\paperwidth,ht=2.0ex,center,dp=0ex]{white}%
\progressbar@progressbar%
\end{beamercolorbox}%
}
\makeatother
\begin{document}
\foreach \x in {1,2,...,90} {\begin{frame}[label=test]{My frame}
Test \x
\end{frame}}
\end{document}
Es sei darauf hingewiesen dass es auch einen Nachteil dieser Lösung gibt. Sobald sich die Anzahl der Frames der Breite der Frames in `sp` annähert, wird die Rechenungenauigkeit von TeX so groß, dass der Fortschrittbalken durch die Rundung zu kurz wird und letztlich auf 0 stehen bleibt.
bleibt. Das dürfte bei Präsentationen aber eine eher theoretische Beschränkung sein, da ich schon Frame-Zahlen über den in der Frage fälschlich angegebenen Grenze von 90 für eher unüblich hoch halte. Präsentationen mit mehreren tausend Frames dürften in freier Wildbahn kaum vorkommen.
Übrigens ist auch die Frage berechtigt, warum man die Berechnung nicht gleich mit `pgf` selbst durchführt. Ich habe nur gerade keine Zeit, mich mit einer entsprechenden Lösung zu beschäftigen.
|
|
1 |
|
|
Wie @huibub bereits in seinen Kommentaren richtig bemerkt hat, darf bei TeX das Ergebnis einer arithmetischen Operation maximal `\maxdimen` groß sein. `\maxdimen` ist 16383.99999pt. Dieser Wert wird bei dir bereits auf Frame 45 (und nicht erst auf Frame 90, wie in der Fragestellung behauptet) überschritten. Eine einfache Lösung wäre nun, am Anfang nicht mit der Hälfe der Papierbreite zu rechnen und diese dann am Ende per `\progressbar@tempdim=2\progressbar@tempdim` wieder auf die ganze Papierbreite zu erhöhen, sondern mit einem wesentlich kleineren Anteil zu arbeiten.
Zusätzlich wäre theoretisch in der Tat zu empfehlen, erst durch die Gesamtzahl der Frames zu dividieren und dann mit der aktuellen Framenummer zu multiplizieren. Leider hat das am Ende dann keine Auswirkungen, weil, wie @huibub ebenfalls in seinen Kommentaren richtig bemerkt, `\inserttotalframenumber` im ersten LaTeX-Lauf natürlich noch nicht die Gesamtzahl der Frames liefert.
Das Problem mit dem zu kleinen `\inserttotalframenumber` kann man einfach lösen, indem man testet, ob '\inserttotalframenumber' größer oder gleich `\value{framenumber}` ist. An dieser Stelle sei auch darauf hingewiesen, dass `\insertframenumber` nicht unbedingt der Weisheit letzter Schluss für die Verwendung in einer Berechnung ist. Ich werde daher stattdessen direkt den Zähler `frame` verwenden. Kombiniert man das nun mit dem Vertauschen der Operationen ist sichergestellt, dass kein zu großes Zwischenergebnis vorkommt und man kann sich die Halbierung aus dem Originalcode sogar ganz sparen.
\documentclass{beamer}
\usepackage{tikz}
\definecolor{pbbg}{RGB}{0,122,59}% filling color for the progress bar
\definecolor{pbfill}{RGB}{0,122,59}% background color for the progress bar
\makeatletter
\def\progressbar@progressbar{} % the progress bar
\newdimen\progressbar@pbht %progressbar height
\newdimen\progressbar@pbwd %progressbar width
\newdimen\progressbar@tmpdim % auxiliary dimension
\progressbar@pbwd=\paperwidth
\progressbar@pbht=0.5ex
% the progress bar
\def\progressbar@progressbar{%
% Die Progressbar ergibt nur Sinn, wenn \inserttotalframenumber > \value{framenumber} ist
\expandafter\ifnum \value{framenumber}>\number\inserttotalframenumber\relax\else
\progressbar@tmpdim=\progressbar@pbwd
\divide\progressbar@tmpdim by \number\inserttotalframenumber\relax
\multiply\progressbar@tmpdim by \value{framenumber}
\begin{tikzpicture}[rounded corners=1.5pt,very thin]
\shade[top color=pbbg!20,bottom color=pbbg!20,middle color=pbbg!50]
(0pt, 0pt) rectangle ++ (\progressbar@pbwd, \progressbar@pbht);
\shade[draw=pbfill,top color=pbfill!50,bottom color=pbfill!50,middle color=pbfill] %
(0pt, 0pt) rectangle ++ (\progressbar@tmpdim, \progressbar@pbht);
\draw[color=normal text.fg!50]
(0pt, 0pt) rectangle (\progressbar@pbwd, \progressbar@pbht)
node[pos=0.5,color=normal text.fg] {\textnormal{%
}%
};
\end{tikzpicture}%
\fi
}
\addtobeamertemplate{footline}
{%
\begin{beamercolorbox}[wd=\paperwidth,ht=2.0ex,center,dp=0ex]{white}%
\progressbar@progressbar%
\end{beamercolorbox}%
}
\makeatother
\begin{document}
\foreach \x in {1,2,...,90} {\begin{frame}[label=test]{My frame}
Test \x
\end{frame}}
\end{document}
Es sei darauf hingewiesen dass es auch einen Nachteil dieser Lösung gibt. Sobald sich die Anzahl der Frames der Breite der Frames in `sp` annähert, wird die Rechenungenauigkeit von TeX so groß, dass der Fortschrittbalken durch die Rundung zu kurz wird und letztlich auf 0 stehen bleibt.
Übrigens ist auch die Frage berechtigt, warum man die Berechnung nicht gleich mit `pgf` selbst durchführt. Ich habe nur gerade keine Zeit, mich mit einer entsprechenden Lösung zu beschäftigen.
