WeasyPrint: Stray line break

In the attached PDF, weasyprint has inserted a stray line break. Page one, column two, first full paragraph, between “through” and “remittances”. I don’t think there’s anything in the source HTML that should cause this. Invocation was as simple as:

weasyprint -q review_54930.html review_54930.pdf

There are a few errors on each run of weasyprint for any of our inputs. They don’t seem to be critical.

/opt/local/lib/python3.7/site-packages/weasyprint/fonts.py:230: UserWarning: FontConfig: No fonts configured. Expect ugly output.
  'FontConfig: No fonts configured. '
/opt/local/lib/python3.7/site-packages/weasyprint/__init__.py:120: FutureWarning: The behavior of this method will change in future versions.  Use specific 'len(elem)' or 'elem is not None' test instead.
  assert result

I will attach the input HTML and CSS as well as the PDF. Github is reliably crashing my chromium today, so it may take several tries.

review_54930_html.txt

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 1
Comments: 21 (14 by maintainers)

Most upvoted comments

Not to mention the strange position where WeasyPrint breaks the layout line…

Other browsers break the line here too, I think Pango’s right. Pango knows the Unicode spec better than we do 😉.

Nevertheless I don’t expect differences when the closing </div> is on a new line.

The current algorithm takes care of this trailing space, but the wrong assumption fixed in bea6cef broke it. There shouldn’t be a difference now.

Nevertheless I don’t expect differences when the word-spacing and the letter-spacing isn’t inherited.

It’s for sure a bug in WP, and it’s not fixed. These properties are applied really naively, just to work in many common cases, but it shouldn’t be hard to find many bugs because of them.

liZe on May 24, 2020

As soon as we get rid of Cairo, next step is Pango.

@Tontyna Yes, it means that I’ll rewrite text.py. 😉

liZe on May 23, 2020