Traceback (most recent call last):
[...]
File "/app/env/lib/python3.5/site-packages/weasyprint/layout/inlines.py", line 718, in split_text_box
'Expected nothing or a preserved line break' % (between,))
AssertionError: Got '1,' between two lines. Expected nothing or a preserved line break
The Assertion Error can be triggered with following minimal test case
(Adobe's Source Sans Pro font must be installed):
<style type="text/css">
p {
font-family: 'Source Sans Pro';
font-size: 24pt;
width: 275pt;
overflow-wrap: break-word;
}
</style>
<p>W1D1,W1D7,W2D14,W3D21,W4D28</p>
With the Adobe Source Sans Font the pango line wrapping algorithm
sometimes produces sporadic results. The wrapping seems to be dependent
on the following text, so that a short text doesn't "fit" on a line, but
does if it is followed by more text. This can be worked around in the
split_first_line() function by computing the resume offset at a later
point, so it is in sync with the actual wrapping behaviour.
See https://bugzilla.gnome.org/show_bug.cgi?id=777093.
Python's tempfile.mkstemp already opens files, we don't have to open
them twice. The documentation is not really clear about that but
there's a good post on Logilab's blog: https://www.logilab.org/17873Fix#396.
It's funny but:
```
pip install --upgrade 'CairoSVG<2'
```
would pull CairoSVG-2.0.0rc6, while
```
pip install --upgrade 'CairoSVG<2.0.0'
```
would pull the 1.x branch (1.0.22 at time of writing).
As Pango keeps the extra trailing spaces when it splits lines, we try to
add the next word of the second line to the first line without its
trailing spaces and see if it fits. If it doesn't, we have to update
resume_at as we have split the first line at a position that may be
different from what Pango did earlier.
Fix#389.
