Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spurious line breaks on tag borders at margin boundaries #163

Closed
TamsynUlthara opened this issue Jan 30, 2014 · 8 comments
Closed

Spurious line breaks on tag borders at margin boundaries #163

TamsynUlthara opened this issue Jan 30, 2014 · 8 comments
Labels
bug Existing features not working as expected
Milestone

Comments

@TamsynUlthara
Copy link

WeasyPrint generates spurious line breaks on tag borders at margin boundaries.

The following snippet illustrates the issue; there should be no breaks between the <em> tags and the XX text:

weasyprint.HTML(
    string="""
<html>
  <head>
    <style type="text/css">
      body { width: 20em; }
    </style>
  </head>
  <body>
    <p>XX<em>foobarbaz</em>XX XX<em>foobarbaz</em>XX XX<em>foobarbaz</em>XX XX<em>foobarbaz</em>XX XX<em>foobarbaz</em>XX XX<em>foobarbaz</em>XX XX<em>foobarbaz</em>XX</p>
  </body>
</html>"""
).write_pdf('foobar.pdf')
@SimonSapin
Copy link
Member

This is a known bug (although it wasn’t filed on GitHub yet). Fixing probably requires a non-trivial amount of refactoring in the inline layout code. :/

@TamsynUlthara
Copy link
Author

I'll keep my fingers crossed. :-) In the meantime, as a crude workaround, I've been setting display: inline-block on pieces of text prone to triggering the bug.

@liZe liZe added the bug Existing features not working as expected label Apr 25, 2015
@E-M-P-I-R-E
Copy link

Would it be feasible for someone to provide guidance on addressing this issue? I might be interested.

The workaround hasn't worked for me; I've had to set an explicit width, additionally.

Perhaps there's a way to merely detect this issue in Python?

@SimonSapin
Copy link
Member

Line breaking happens in weasyprint/layout/inlines.py. It works by trying to add things to the current line as long as it fits, and when nothing more can fit going to the next line. The problem is that inline elements like <em>foobarbaz</em> are considered separate "things" from the text next to them, even if there is no white space in between. I’m not sure how to fix this exactly, but it probably involves going "back" in the tree to find an earlier break opportunity.

Another approach could be to "flatten" the tree of inlines and find break opportunities independently of tag boundaries. It would make a lot of things easier, but it’s more work up front for a big refactor.

@E-M-P-I-R-E
Copy link

I'm not sure that it's realistic, for me to tackle the latter suggestion, considering how involved that appears to be. In that case, though - do you have an idea of how you would restore the inline elements after flattening the tree [to make line breaking more accurate]? Perhaps, two versions are kept in memory and the full version is altered, adding to and creating new lines, as the flattened one is (with a kind-of pointer following the progress of the pruned-tree analysis)?

@SimonSapin
Copy link
Member

This "other approach" was more more of a random thought than an actual suggestion. It might not even work, and such a sweeping change doesn’t sound like a good idea for a project that’s effectively inactive.

@liZe
Copy link
Member

liZe commented Mar 8, 2016

Grouped in #301.

@liZe liZe closed this as completed Mar 8, 2016
liZe added a commit that referenced this issue Jan 2, 2017
As ::first-letter depends on white space handling, we must create the
box after collapsing spaces, not during the build of the box tree.

This commit makes WeasyPrint pass most of the W3C tests related to
first-letter (and never crash). Known problems left include:

- list markers are considered as the first letter,
- lines may break between the first letter and the rest of the text
  (see #163 and #301),
- the CSS attributes are all kept, some should probably be removed (the
  spec doesn't give a whole list).

Even if W3C tests makes me quite confident (some of them are crazy),
tests must be added in WeasyPrint too.
@liZe liZe added this to the v0.42 milestone Dec 26, 2017
@liZe
Copy link
Member

liZe commented Dec 26, 2017

Fixed by closing #301.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Existing features not working as expected
Projects
None yet
Development

No branches or pull requests

4 participants