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.
Only relying on the line length is awful in real-life test cases when the
font size is big and the line short (ex. titles), causing the last word
of some lines to disappear.
This new workaround gives an 0.2em extra space for latest characters
(instead of line-height/10000).
Implemented the property as described by the W3C draft. There is still a
bug with shaping characters which does not keep their shapes when wrapped
on new lines. Implemented as overflow-wrap CSS property, but maybe it
should be refactored to -weasy-overflow-wrap. Browser implementation is
inconsistent, so there was no clear answer.
