The hack had been added to remove extra line breaks caused by floating point
errors when the shrink-to-fit width was coming from Pango and had a slightly
higher value when re-calculated in split_first_line.
The same problem appears when we split a line contaning inline-blocks (instead
of letters in the previous case), as the shrink-to-fit width may also inderctly
come from Pango and hit the same re-calculation floating point errors.
This commit moves the hack at a higher level, increasing the max width before
calling split_first_line when the line contains letters (same result as
before), but also before splitting lines containing inline-blocks.
Fix#467.
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.
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.
Fix#266 without adding extra chacarcters. The specification is not
clear about how letter-spacing must be implemented, but the browsers
seem to add an extra space after each character. Pango does this too,
but it doesn't do it at the end of the last character. This commit adds
this extra space after the last character.
Fix#325 and shouldn't reopen#288. Now that fac5ee9 fixes line-cutting
bug when drawing, we can use a much lower relative tolerance inspired
from PEP 485 (1e-9 instead of 1e-3).
Tests have been added with random values, as results highly depend on
the version of Pango used and on hinting properties depending on the
system used to launch the tests. They are probably longer than required,
but they try hard to prevent #288 and #325 from coming back.
- Fix some unicode/utf-8 TODOs
- Change hyphenation tests to use non-ASCII characters
- Use better variable names
- Use a simpler code for overflow-wrap: break-word
To draw a text line, the previous behaviour didn't rely only on the text
actually set on the layout, but also relied on the fact that the line
was cut again when drawn. This change removes the line cutting when
drawing, and thus only relies on the line splitting done during the
layout. This fixes a bug causing some words not being displayed at the
end of a text line drawn with hinting, and the actual drawing size with
hinting was bigger than the size calculated during the layout.
The text included in the drawn layout object was sometimes not cut at
the right position, it was longer but cut when actually drawn. This
commit also fixes this, by always setting the right text in the layout
object.
Fixing this bug enables us to remove a hack introduced to fight against
an "accumulation of floating point errors". I now think that "it wasn't
our war"™. I think that the real reasons of this hack were probably:
- a problem with trailing spaces in the shrink-to-fit functions fixed in
commit 3a620db, and
- this line-cutting bug while drawing, fixed now.
I've tried hard to reproduce the shink-to-fit problem without this hack,
with no success. I don't see anymore how it can theorically happen with
the current code of the "preferred" module. The only bug fixed by this
hack that I've been able to reproduce is the hinting problem explained
in the first paragraph, and this bug is now really fixed.
Moreover, this hack used to cause another problem: as the maximum size
allowed to an inline block was actually bigger than the real size
available in the line, an inline block whose size was between the real
and the allowed sizes was put on a new line by the split_inline_box
function. This commit fixes#288, the bug reported about this problem.
