Fix #8780: long words in narrow columns may not be hyphenated #8781
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1161,7 +1161,9 @@ def visit_paragraph(self, node: Element) -> None: | |
| # (first one is label node) | ||
| pass | ||
| else: | ||
| # the \sphinxAtStartPar is to allow hyphenation of first word of | ||
| # a paragraph in narrow contexts such as in a table cell | ||
| self.body.append('\n\\sphinxAtStartPar\n') | ||
|
Member
There was a problem hiding this comment. The children of paragraph node are regularly text nodes or inline nodes. It is defined at the doctree specification. Almost of the inline nodes are decorated text. But, some of them are not; for example, math, image, problematic and raw. Additionally, some extensions might generate broken doctree under the paragraph node.
Contributor
Author
There was a problem hiding this comment. A math node is fine (via the
Member
There was a problem hiding this comment. Agreed. From my perspective, docutils' paragraph model and LaTeX's horizontal mode are similar. (But I did not mention that yesterday because I'm not familiar with LaTeX's mode :-p) |
||
|
|
||
| def depart_paragraph(self, node: Element) -> None: | ||
| self.body.append('\n') | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,13 +1,18 @@ | ||
|
|
||
| \sphinxAtStartPar | ||
| Equation without a label. | ||
| \begin{equation*} | ||
| \begin{split}E = mc^2\end{split} | ||
| \end{equation*} | ||
| \sphinxAtStartPar | ||
| Equation with label. | ||
| \begin{equation}\label{equation:equations:test} | ||
| \begin{split}E = hv\end{split} | ||
| \end{equation} | ||
| \sphinxAtStartPar | ||
| Second equation without label. | ||
| \begin{equation*} | ||
| \begin{split}c^2 = a^2 + b^2\end{split} | ||
| \end{equation*} | ||
| \sphinxAtStartPar | ||
| Equation with label \eqref{equation:equations:test} is important. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know this change will break PDF generation. But it would be better to add big change into the next major release. It's planned for this April.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To the best of my knowledge the change can not break PDF generation. As far as I can tell, at worst it could add an extra blank line if the first child is implemented via a "vertical" environment: typically a list, but this seems excluded: in my understanding a list can not be first child of a paragraph node. An image is not a problem if it is not embedded into "figure" (for example I image inserted from a substitution). I tested that math like
equationoraligndo not seem to be affected. At any rate there is no way I can see this can break PDF build whatever nodes follow. The only thing it can cause is this extra blank line. But I can not construct an example from rst source creating this.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay. I understand and agreed this does not break PDF generation. Let us see what will be reported.
Fortunately, reST's substitution only allows inline elements. Nobody can't insert non "inline" elements under the paragraph node without hacks (by raw node or extensions).