Fix AssertionError in layout.inlines.split_text_box(). #410

Merged
merged 1 commit into from Jan 11, 2017

Conversation

Projects
None yet
2 participants
@natano
Contributor

natano commented Jan 11, 2017

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.

Fix AssertionError in layout.inlines.split_text_box().
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.
@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe Jan 11, 2017

Member

Thanks a lot for reporting this issue!

Your fix is OK. We have to take the final second line index for resume_at because the temporary second line is only split on words (the second one splits on chars, that's how WRAP_WORD_CHAR works).

I think that we can safely use WRAP_CHAR instead of WRAP_WORD_CHAR as we tried to split the line on words boundaries earlier, and avoid a second split. I'll do this in another commit.

Member

liZe commented Jan 11, 2017

Thanks a lot for reporting this issue!

Your fix is OK. We have to take the final second line index for resume_at because the temporary second line is only split on words (the second one splits on chars, that's how WRAP_WORD_CHAR works).

I think that we can safely use WRAP_CHAR instead of WRAP_WORD_CHAR as we tried to split the line on words boundaries earlier, and avoid a second split. I'll do this in another commit.

@liZe liZe merged commit 5aa34d7 into Kozea:master Jan 11, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

liZe added a commit that referenced this pull request Jan 11, 2017

Try to use WRAP_CHAR instead of WRAP_WORD_CHAR
And add some comments to explain why it doesn't work. Related to #410.
@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe Jan 11, 2017

Member

I think that we can safely use WRAP_CHAR instead of WRAP_WORD_CHAR as we tried to split the line on words boundaries earlier, and avoid a second split. I'll do this in another commit.

It doesn't work. I've added some comments about this.

Thanks again!

Member

liZe commented Jan 11, 2017

I think that we can safely use WRAP_CHAR instead of WRAP_WORD_CHAR as we tried to split the line on words boundaries earlier, and avoid a second split. I'll do this in another commit.

It doesn't work. I've added some comments about this.

Thanks again!

jsonn pushed a commit to jsonn/pkgsrc that referenced this pull request Mar 3, 2017

kleink
Update py-weasyprint to 0.36.
Version 0.36
------------

Released on 2017-02-25.

New features:

* `#407 <Kozea/WeasyPrint#407>`_:
  Handle ::first-letter.
* `#423 <Kozea/WeasyPrint#423>`_:
  Warn user about broken cairo versions.

Bug fixes:

* `#411 <Kozea/WeasyPrint#411>`_:
  Typos fixed in command-line help.


Version 0.35
------------

Released on 2017-02-25.

Bug fixes:

* `#410 <Kozea/WeasyPrint#410>`_:
  Fix AssertionError in split_text_box.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment