Dimension to large error about mtheme HOT 4 CLOSED

Thanks for the bug report. Awesome detective work!

I think I've tracked down the cause. The error occurs in the calculation of the width of the progress bar. When the presentation is compiled for the first time, \inserttotalframenumber defaults to 1 when it has no aux file to read from. Therefore, \ratio{\insertframenumber pt}{\inserttotalframenumber pt}, which we've assumed to be between 0 and 1, can actually become quite large. And if the width of the frame times this number ever exceeds 16384pt (about 18.9ft), then we get the error.

Fortunately, this problem is easily worked around by re-compiling. Once beamer has an aux file to read from, \inserttotalframenumber will be set to something reasonable and the error will no longer occur. Perhaps we should redefine \inserttotalframenumber to default to 100 to avoid this under reasonable usage?

from mtheme.

I fixed it by just setting the total frame number to 1 if it is ever less
than that.

b.g.

On Thu, Jun 11, 2015, 3:26 AM Ross Churchley [email protected]
wrote:

Thanks for the bug report. Awesome detective work!

I think I've tracked down the cause. The error occurs in the calculation
of the width of the progress bar. When the presentation is compiled for the
first time, \inserttotalframenumber defaults to 1 when it has no aux file
to read from. Therefore, \ratio{\insertframenumber
pt}{\inserttotalframenumber pt}, which we've assumed to be between 0 and
1, can actually become quite large. And if the width of the frame times
this number ever exceeds 16384pt (about 18.9ft)
http://tex.stackexchange.com/questions/139883/origin-and-formation-to-the-error-dimension-too-large,
then we get the error.

Fortunately, this problem is easily worked around by re-compiling. Once
beamer has an aux file to read from, \inserttotalframenumber will be set
to something reasonable and the error will no longer occur. Perhaps we
should redefine \inserttotalframenumber to default to 100 to avoid this
under reasonable usage?

Reply to this email directly or view it on GitHub
#70 (comment).

Bill Gatliff
[email protected]

from mtheme.

Seems like the default might actually be zero, in other words...

On Thu, Jun 11, 2015, 5:18 AM Bill Gatliff [email protected] wrote:

I fixed it by just setting the total frame number to 1 if it is ever less
than that.

b.g.

On Thu, Jun 11, 2015, 3:26 AM Ross Churchley [email protected]
wrote:

Thanks for the bug report. Awesome detective work!

I think I've tracked down the cause. The error occurs in the calculation of
the width of the progress bar. When the presentation is compiled for the
first time, \inserttotalframenumber defaults to 1 when it has no aux file
to read from. Therefore, \ratio{\insertframenumber
pt}{\inserttotalframenumber pt}, which we've assumed to be between 0 and 1,
can actually become quite large. And if the width of the frame times this
number ever exceeds 16384pt (about 18.9ft)
http://tex.stackexchange.com/questions/139883/origin-and-formation-to-the-error-dimension-too-large,
then we get the error.

Fortunately, this problem is easily worked around by re-compiling. Once
beamer has an aux file to read from, \inserttotalframenumber will be set to
something reasonable and the error will no longer occur. Perhaps we should
redefine \inserttotalframenumber to default to 100 to avoid this under
reasonable usage?

Reply to this email directly or view it on GitHub
#70 (comment).

Bill Gatliff
[email protected]

--

Bill Gatliff
[email protected]

from mtheme.

Thanks for fixing that.

from mtheme.