Arithmetic overflow error on building PDF
291 views
Skip to first unread message
atsuo ishimoto
Feb 6, 2023, 12:29:10 AM2/6/23
to sphinx-users
Hello list,
Currently, docs.python.org has stopped generating PDF documents in Japanese due to a failure. I am trying to restart it by changing the latex engine from platex to LuaTeX, but I need help with the following error.
Building following document causes Arithmetic overflow error with lualatex:
$ cat source/index.rst
1111111111111
#############
2222222222222
*************
3333333333333
=============
4444444444444
-------------
:class:`555555555555555`
^^^^^^^^^^^^^^^^^^^^^^^^
+-------------+------+
| 0000000 | AAAA |
| +------+
| | BBBB |
+-------------+------+
$ cat source/conf.py
project = 'test1'
copyright = '2023, a'
author = 'a'
extensions = []
templates_path = ['_templates']
exclude_patterns = []
language = 'ja'
html_theme = 'alabaster'
html_static_path = ['_static']
latex_engine="lualatex"
latex_docclass = {
'manual': 'ltjsbook',
'howto': 'ltjsarticle'
}
$ make latexpdf
...
...
! Arithmetic overflow.
\sphinx@@multirow ... \divide \count@ \count \tw@
\advance \dimen@ -\count@ ...
l.64 \end{tabulary}
The error doesn't happen if I replace the row
:class:`555555555555555`
^^^^^^^^^^^^^^^^^^^^^^^^
with
the :class:`555555555555555`
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I reproduced the error on Ubuntu and macOS.
Ubuntu:
$ sphinx-build --version
sphinx-build 6.1.3
$ lualatex --version
This is LuaHBTeX, Version 1.14.0 (TeX Live 2022/dev/Debian)
$ uname -a
Linux u2204 5.15.0-58-generic #64-Ubuntu SMP Thu Jan 5 11:43:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
macOS:
$ sphinx-build --version
sphinx-build 6.1.3
$ lualatex --version
This is LuaHBTeX, Version 1.15.0 (TeX Live 2022)
$ uname -a
Darwin mbp16.local 21.4.0 Darwin Kernel Version 21.4.0: Mon Feb 21 20:34:37 PST 2022; root:xnu-8020.101.4~2/RELEASE_X86_64 x86_64
To reproduce, I created a github repository of the sphinx project at:
https://github.com/atsuoishimoto/lualatex-arithmetic-overflow
With the repo, you can reproduce with:
$ git clone g...@github.com:atsuoishimoto/lualatex-arithmetic-overflow.git
$ cd lualatex-arithmetic-overflow/sphinx-error
$ make latexpdf
As I am new to TeX, I cannot determine if this problem is due to Sphinx's TeX styles or a bug in LuaTeX. Any advice would be appreciated.
Regards,
Currently, docs.python.org has stopped generating PDF documents in Japanese due to a failure. I am trying to restart it by changing the latex engine from platex to LuaTeX, but I need help with the following error.
Building following document causes Arithmetic overflow error with lualatex:
$ cat source/index.rst
1111111111111
#############
2222222222222
*************
3333333333333
=============
4444444444444
-------------
:class:`555555555555555`
^^^^^^^^^^^^^^^^^^^^^^^^
+-------------+------+
| 0000000 | AAAA |
| +------+
| | BBBB |
+-------------+------+
$ cat source/conf.py
project = 'test1'
copyright = '2023, a'
author = 'a'
extensions = []
templates_path = ['_templates']
exclude_patterns = []
language = 'ja'
html_theme = 'alabaster'
html_static_path = ['_static']
latex_engine="lualatex"
latex_docclass = {
'manual': 'ltjsbook',
'howto': 'ltjsarticle'
}
$ make latexpdf
...
...
! Arithmetic overflow.
\sphinx@@multirow ... \divide \count@ \count \tw@
\advance \dimen@ -\count@ ...
l.64 \end{tabulary}
The error doesn't happen if I replace the row
:class:`555555555555555`
^^^^^^^^^^^^^^^^^^^^^^^^
with
the :class:`555555555555555`
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I reproduced the error on Ubuntu and macOS.
Ubuntu:
$ sphinx-build --version
sphinx-build 6.1.3
$ lualatex --version
This is LuaHBTeX, Version 1.14.0 (TeX Live 2022/dev/Debian)
$ uname -a
Linux u2204 5.15.0-58-generic #64-Ubuntu SMP Thu Jan 5 11:43:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
macOS:
$ sphinx-build --version
sphinx-build 6.1.3
$ lualatex --version
This is LuaHBTeX, Version 1.15.0 (TeX Live 2022)
$ uname -a
Darwin mbp16.local 21.4.0 Darwin Kernel Version 21.4.0: Mon Feb 21 20:34:37 PST 2022; root:xnu-8020.101.4~2/RELEASE_X86_64 x86_64
To reproduce, I created a github repository of the sphinx project at:
https://github.com/atsuoishimoto/lualatex-arithmetic-overflow
With the repo, you can reproduce with:
$ git clone g...@github.com:atsuoishimoto/lualatex-arithmetic-overflow.git
$ cd lualatex-arithmetic-overflow/sphinx-error
$ make latexpdf
As I am new to TeX, I cannot determine if this problem is due to Sphinx's TeX styles or a bug in LuaTeX. Any advice would be appreciated.
Regards,
jfbu
Feb 6, 2023, 5:41:54 AM2/6/23
to sphinx...@googlegroups.com
> $ cd lualatex-arithmetic-overflow/sphinx-error
> $ make latexpdf
>
> As I am new to TeX, I cannot determine if this problem is due to Sphinx's
> TeX styles or a bug in LuaTeX. Any advice would be appreciated.
>
> Regards,
>
Thanks for your test projects.
This looks like a tough one, provisory conclusion is that this is not caused by Sphinx's LaTeX styles.
I am in the midst of pressing deadlines and can't examine it more thoroughly until next week, in particular I have not tried to produce a non-Sphinx example but expect for reasons I explain below that this will be easily feasible.
here is what I can say so far (thanks to your projects).
The error is a division by zero error.
This is caused by the box \@arstrutbox having zero height. This height is queried by Sphinx in its multirow implementation.
The \@arstrutbox height is configured by the tabulary environment using \strutbox height.
The \strutbox height is unexpectedly having zero height at this location of start of tabulary.
But does not have zero height when `the` (or for that matter any Latin letter) is present at start of the preceding sectioning title.
Thus \strutbox is unexpectedly modifed by how this sectioning title looks, which is definitely not a Sphinx matter.
The \strutbox seems to have some specific Lualatex behavior which may involve the current direction of typesetting. Here is what happens if I add \showthe\ht\strutbox after this sectioning title
good case
```
> 11.19995pt.
\strutbox ...etparameter {direction}=4 \ystrutbox
\else \tstrutbox \fi \fi
l.125 \showthe\ht\strutbox
```
bad case
```
> 0.0pt.
\strutbox ...etparameter {direction}=4 \ystrutbox
\else \tstrutbox \fi \fi
l.125 \showthe\ht\strutbox
```
(line numbering is meaningless due to added debugging stuff in produced LaTeX file)
A priori and after quick check nothing in Sphinx LaTeX files will deliberately modify \strutbox.
If I have time later I will try to produce a non-Sphinx minimal example. It would go via trying to make a division by the height of the \strutbox.
I suspect a connection with direction of typesetting. Maybe in vertical typesetting the \strutbox is interpreted to provide width, not height. Unfortunately I am both very ignorant in Lualatex specifics and in non-Latin scripts especially regarding not Left to Right usage of TeX.
As per
> Currently, docs.python.org has stopped generating PDF documents in Japanese
> due to a failure. I am trying to restart it by changing the latex engine
> from platex to LuaTeX, but I need help with the following error.
By the way Sphinx now uses uplatex which is Unicode aware.
------------
Running 'uplatex -kanji=utf8 -recorder "foo.tex"'
------------
This is e-upTeX, Version 3.141592653-p4.0.0-u1.28-220214-2.6 (utf8.uptex) (TeX Live 2023/dev) (preloaded format=uplatex)
however I suspect the "failure" was already tested with recent Sphinx and that the uplatex does not fix it as you report using Sphinx 6.1.3 in your test of Lualatex.
Could you please open a ticket at Sphinx, something with title "LaTeX: build failure if language is Japanese when using LuaLaTex (not pLaTeX)". As I mentioned it will probably not be addressed before some time. This is for documentation, as I expect that the issue is not directly imputable to Sphinx, in view of circumstances above.
Thanks
Jean-François
jfbu
Feb 6, 2023, 6:00:54 AM2/6/23
to sphinx...@googlegroups.com
Le 06/02/2023 à 11:41, jfbu a écrit :
>
> good case
>
> ```
>> 11.19995pt.
> \strutbox ...etparameter {direction}=4 \ystrutbox
> \else \tstrutbox \fi \fi
> l.125 \showthe\ht\strutbox
> ```
>
> bad case
>
> ```
>> 0.0pt.
> \strutbox ...etparameter {direction}=4 \ystrutbox
> \else \tstrutbox \fi \fi
> l.125 \showthe\ht\strutbox
> ```
>
> (line numbering is meaningless due to added debugging stuff in produced LaTeX file)
>
> A priori and after quick check nothing in Sphinx LaTeX files will deliberately modify \strutbox.
LaTeX sets \strutbox inside its \set@fontsize.
>
> good case
>
> ```
>> 11.19995pt.
> \strutbox ...etparameter {direction}=4 \ystrutbox
> \else \tstrutbox \fi \fi
> l.125 \showthe\ht\strutbox
> ```
>
> bad case
>
> ```
>> 0.0pt.
> \strutbox ...etparameter {direction}=4 \ystrutbox
> \else \tstrutbox \fi \fi
> l.125 \showthe\ht\strutbox
> ```
>
> (line numbering is meaningless due to added debugging stuff in produced LaTeX file)
>
> A priori and after quick check nothing in Sphinx LaTeX files will deliberately modify \strutbox.
\setbox\strutbox\hbox{%
\vrule\@height.7\baselineskip
\@depth.3\baselineskip
\@width\z@}%
further debugging would compare TeX traces of the \subsubsection in the good and bad cases , where is \set@fontsize called, what is the value of \baselineskip there
>
> If I have time later I will try to produce a non-Sphinx minimal example. It would go via trying to make a division by the height of the \strutbox.
>
> I suspect a connection with direction of typesetting. Maybe in vertical typesetting the \strutbox is interpreted to provide width, not height.
jfbu
Feb 6, 2023, 9:10:04 AM2/6/23
to sphinx...@googlegroups.com
Hi
Le 06/02/2023 à 11:41, jfbu a écrit :
>> $ git clone git-9UaJU3cA/F/QT0dZ...@public.gmane.org:atsuoishimoto/lualatex-arithmetic-overflow.git
As workaround please try with this merged into your conf.py
latex_elements = {
'preamble': r"""
\makeatletter
% we add a \normalsize to fix a ltjsbook + titlesec "\strutbox" problem
\titleformat{\subsubsection}{\normalsize\py@HeaderFamily}%
{\py@TitleColor\thesubsubsection}{0.5em}{\py@TitleColor}
% also extra \normalsize here
\titleformat{\paragraph}{\normalsize\py@HeaderFamily}%
{\py@TitleColor\theparagraph}{0.5em}{\py@TitleColor}
\titleformat{\subparagraph}{\normalsize\py@HeaderFamily}%
{\py@TitleColor\thesubparagraph}{0.5em}{\py@TitleColor}
""",
}
and report here if it worked. Perhaps there will be further unrelated issues.
Please open a ticket at https://github.com/sphinx-doc/sphinx/issues
linking to <d39abd23-6713-44b3...@googlegroups.com>
Indeed, the addition of \normalsize can be perhaps done upstream at Sphinx as it looks non-breaking to existing projects. I could not use the \py@HeaderFamily hook (which defaults to \sffamily\bfseries) because for section and chapter it comes after, not before, a font size change.
However the above is only a workaround.
It was obtained after reducing to the non-Sphinx situation as shown next.
The problem arises in Sphinx because Sphinx uses titlesec.
For some reason which only experts of Lualatex + ltjsbook can debug, the usage of titlesec will let a \leavevmode (which originates in your Sphinx example from a \texttt ultimately originating in the class role) at start of the subsubsection title cause the \strutbox to acquire a zero height.
But adding a \normalsize to the titlesec configuration for subsubsection fixes this.
---- pure ltjsbook + titlesec example demonstrating issue
\documentclass{ltjsbook}
% OK: not loading titlesec
% BAD: loading titlesec AND using for subsubsection the format as shown below
\usepackage{titlesec}
\titleformat{\subsubsection}{}{\thesubsubsection}{1em}{}
% BUT this format with \normalsize added would be OK
%%%% \titleformat{\subsubsection}{\normalsize}{\thesubsubsection}{1em}{}
\begin{document}
% for debugging attempts
% \tracingmacros1
% \tracingstacklevels1
% BAD with \leavevmode
% memo: \texttt{A} will cause \leavevmode hence be BAD
% In absence of \leavevmode the issue is not triggered.
\subsubsection{{\leavevmode A}}
% \tracingmacros0
\showthe\ht\strutbox % BAD IF 0pt, OK IF REASONABLE > 0pt
\end{document}
----
It would be too complex for me to pinpoint more precisely the root cause of the issue.
Strangely if one replaces *all* "subsubsection" everywhere in the above LaTeX code by "section" there is no problem even without the \normalsize.
Please report the above demonstrating file and my comments to the ltjsbook.cls maintainers
LuaTeX-ja is developed on
<https://osdn.jp/projects/luatex-ja/wiki/FrontPage(en)>.
and perhaps to the titlesec maintainer
https://github.com/jbezos/titlesec
Jean-François
Le 06/02/2023 à 11:41, jfbu a écrit :
latex_elements = {
'preamble': r"""
\makeatletter
% we add a \normalsize to fix a ltjsbook + titlesec "\strutbox" problem
\titleformat{\subsubsection}{\normalsize\py@HeaderFamily}%
{\py@TitleColor\thesubsubsection}{0.5em}{\py@TitleColor}
% also extra \normalsize here
\titleformat{\paragraph}{\normalsize\py@HeaderFamily}%
{\py@TitleColor\theparagraph}{0.5em}{\py@TitleColor}
\titleformat{\subparagraph}{\normalsize\py@HeaderFamily}%
{\py@TitleColor\thesubparagraph}{0.5em}{\py@TitleColor}
""",
}
and report here if it worked. Perhaps there will be further unrelated issues.
Please open a ticket at https://github.com/sphinx-doc/sphinx/issues
linking to <d39abd23-6713-44b3...@googlegroups.com>
Indeed, the addition of \normalsize can be perhaps done upstream at Sphinx as it looks non-breaking to existing projects. I could not use the \py@HeaderFamily hook (which defaults to \sffamily\bfseries) because for section and chapter it comes after, not before, a font size change.
However the above is only a workaround.
It was obtained after reducing to the non-Sphinx situation as shown next.
The problem arises in Sphinx because Sphinx uses titlesec.
For some reason which only experts of Lualatex + ltjsbook can debug, the usage of titlesec will let a \leavevmode (which originates in your Sphinx example from a \texttt ultimately originating in the class role) at start of the subsubsection title cause the \strutbox to acquire a zero height.
But adding a \normalsize to the titlesec configuration for subsubsection fixes this.
---- pure ltjsbook + titlesec example demonstrating issue
\documentclass{ltjsbook}
% OK: not loading titlesec
% BAD: loading titlesec AND using for subsubsection the format as shown below
\usepackage{titlesec}
\titleformat{\subsubsection}{}{\thesubsubsection}{1em}{}
% BUT this format with \normalsize added would be OK
%%%% \titleformat{\subsubsection}{\normalsize}{\thesubsubsection}{1em}{}
\begin{document}
% for debugging attempts
% \tracingmacros1
% \tracingstacklevels1
% BAD with \leavevmode
% memo: \texttt{A} will cause \leavevmode hence be BAD
% In absence of \leavevmode the issue is not triggered.
\subsubsection{{\leavevmode A}}
% \tracingmacros0
\showthe\ht\strutbox % BAD IF 0pt, OK IF REASONABLE > 0pt
\end{document}
----
It would be too complex for me to pinpoint more precisely the root cause of the issue.
Strangely if one replaces *all* "subsubsection" everywhere in the above LaTeX code by "section" there is no problem even without the \normalsize.
Please report the above demonstrating file and my comments to the ltjsbook.cls maintainers
LuaTeX-ja is developed on
<https://osdn.jp/projects/luatex-ja/wiki/FrontPage(en)>.
and perhaps to the titlesec maintainer
https://github.com/jbezos/titlesec
Jean-François
jfbu
Feb 6, 2023, 9:15:06 AM2/6/23
to sphinx...@googlegroups.com
> s workaround please try with this merged into your conf.py
>
> latex_elements = {
> 'preamble': r"""
> \makeatletter
> % we add a \normalsize to fix a ltjsbook + titlesec "\strutbox" problem
> \titleformat{\subsubsection}{\normalsize\py@HeaderFamily}%
> {\py@TitleColor\thesubsubsection}{0.5em}{\py@TitleColor}
> % also extra \normalsize here
> \titleformat{\paragraph}{\normalsize\py@HeaderFamily}%
> {\py@TitleColor\theparagraph}{0.5em}{\py@TitleColor}
> \titleformat{\subparagraph}{\normalsize\py@HeaderFamily}%
> {\py@TitleColor\thesubparagraph}{0.5em}{\py@TitleColor}\makeatother
>
> latex_elements = {
> 'preamble': r"""
> \makeatletter
> % we add a \normalsize to fix a ltjsbook + titlesec "\strutbox" problem
> \titleformat{\subsubsection}{\normalsize\py@HeaderFamily}%
> {\py@TitleColor\thesubsubsection}{0.5em}{\py@TitleColor}
> % also extra \normalsize here
> \titleformat{\paragraph}{\normalsize\py@HeaderFamily}%
> {\py@TitleColor\theparagraph}{0.5em}{\py@TitleColor}
> \titleformat{\subparagraph}{\normalsize\py@HeaderFamily}%
> """,
> }
I forgot in my message the \makeatother, but its absence should not harm in fact.
jfbu
Feb 6, 2023, 9:20:45 AM2/6/23
to sphinx...@googlegroups.com
Le 06/02/2023 à 15:09, jfbu a écrit :
> latex_elements = {
> 'preamble': r"""
> \makeatletter
> % we add a \normalsize to fix a ltjsbook + titlesec "\strutbox" problem
> \titleformat{\subsubsection}{\normalsize\py@HeaderFamily}%
> {\py@TitleColor\thesubsubsection}{0.5em}{\py@TitleColor}
> % also extra \normalsize here
> \titleformat{\paragraph}{\normalsize\py@HeaderFamily}%
> {\py@TitleColor\theparagraph}{0.5em}{\py@TitleColor}
> \titleformat{\subparagraph}{\normalsize\py@HeaderFamily}%
> {\py@TitleColor\thesubparagraph}{0.5em}{\py@TitleColor}
> """,
> }
>
> and report here if it worked. Perhaps there will be further unrelated issues.
>
>
> Please open a ticket at https://github.com/sphinx-doc/sphinx/issues
> linking to <d39abd23-6713-44b3-be93-4ba42844e371n-/JYPxA39Uh5...@public.gmane.org>
> latex_elements = {
> 'preamble': r"""
> \makeatletter
> % we add a \normalsize to fix a ltjsbook + titlesec "\strutbox" problem
> \titleformat{\subsubsection}{\normalsize\py@HeaderFamily}%
> {\py@TitleColor\thesubsubsection}{0.5em}{\py@TitleColor}
> % also extra \normalsize here
> \titleformat{\paragraph}{\normalsize\py@HeaderFamily}%
> {\py@TitleColor\theparagraph}{0.5em}{\py@TitleColor}
> \titleformat{\subparagraph}{\normalsize\py@HeaderFamily}%
> {\py@TitleColor\thesubparagraph}{0.5em}{\py@TitleColor}
> """,
> }
>
> and report here if it worked. Perhaps there will be further unrelated issues.
>
>
> Please open a ticket at https://github.com/sphinx-doc/sphinx/issues
latex_elements = {
'preamble': r"""
\makeatletter
% we add a \normalsize to fix a ltjsbook + titlesec "\strutbox" problem
\titleformat{\subsubsection}{\normalsize\py@HeaderFamily}%
{\py@TitleColor\thesubsubsection}{0.5em}{\py@TitleColor}
% also extra \normalsize here
\titleformat{\paragraph}{\normalsize\py@HeaderFamily}%
{\py@TitleColor\theparagraph}{0.5em}{\py@TitleColor}
\titleformat{\subparagraph}{\normalsize\py@HeaderFamily}%
{\py@TitleColor\thesubparagraph}{0.5em}{\py@TitleColor}
""",
}
and report here if it worked. Perhaps there will be further unrelated issues.
Trying now to paste an URL to access this discussion without a groups.google account (I myself use the Gmane interface)
}
and report here if it worked. Perhaps there will be further unrelated issues.
linking to <https://groups.google.com/g/sphinx-users/c/9sKyElODU5I>
jfbu
Feb 6, 2023, 4:20:13 PM2/6/23
to sphinx...@googlegroups.com
Le 06/02/2023 à 15:09, jfbu a écrit :
> Please report the above demonstrating file and my comments to the ltjsbook.cls maintainers
> LuaTeX-ja is developed on
>
> <https://osdn.jp/projects/luatex-ja/wiki/FrontPage(en)>.
>
Hi everyone,
> LuaTeX-ja is developed on
>
> <https://osdn.jp/projects/luatex-ja/wiki/FrontPage(en)>.
>
This was a challenging one but it turns out to be a bug of Luatexja.
I reported it at
https://osdn.net/projects/luatex-ja/ticket/47321
Jean-François
atsuo ishimoto
Feb 7, 2023, 9:11:14 AM2/7/23
to sphinx-users
Hello Jean-François,
Thank you for your amazing work! I'm sorry for my late response. Surprisingly, all the emails from Google Groups were filtered as SPAM by Gmail.
I filed this issue at https://github.com/sphinx-doc/sphinx/issues/11179.
> Where can one see this failure? Maybe it will be easier to fix it than trying to use lualatex without a lualatex + Japanese + Sphinx expert available.
The issue is filed at https://github.com/python/python-docs-ja/issues/35.
A summary of errors that happen with uplatex is https://github.com/python/python-docs-ja/issues/35#issuecomment-1397833224.
> As workaround please try with this merged into your conf.py
> ...
The workaround works without a problem. Thank you so much!
Great! I sincerely appreciate your efforts.
2023年2月7日火曜日 6:20:13 UTC+9 jfbu:
Reply all
Reply to author
Forward
0 new messages