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

<pre> tag rendiring issue #813

Closed
JGiard opened this Issue Feb 26, 2019 · 2 comments

Comments

3 participants
@JGiard
Copy link

commented Feb 26, 2019

Hello,
I have a issue when rendering the <pre> under certain conditions.
It looks like that having <br> tags inside them breaks the rendering and the content is cut half-way through. I suppose it might also be a max-line-length issue in the renderer.

I have attached an example showing this, the text is identical but the first is formatted with <br> tags and the other with regular line breaks.

test-pre.zip

I am using weasyprint 45 with cairo 1.15.10

@Tontyna

This comment has been minimized.

Copy link
Contributor

commented Feb 26, 2019

Ah! That's a nice one!
Not reasoning about a one-line-white-space-pre element with <br> instead of newlines ... fact is: the bad text is rendered, but all the invisible TextBoxes have the same position_y like the last visible one, their position_x increases and increases and increases....
Looks like <br>-outside-the-margin gets lost in (white?) space.

nr813

Snippet to reproduce:

<html>
<head>
<style>
p{
  white-space:pre;
  font-size:2em;
}
@page{
  size: A5;
  border: 1px solid black;
  margin-right:5cm; 
}
</style>    
</head>
<body>
<p>
beyond the margin <br>there is no <br> anymore
</p>
</body>
</html>

@liZe liZe added the bug label Feb 28, 2019

@liZe

This comment has been minimized.

Copy link
Member

commented Mar 1, 2019

OK. The bug happens when preformatted text overfows its parent and when a tag's text ends with a \n character.

The bug has been introduced in #557's fix (995a9a3). In split_first_line, we always set the resume_at value to None when the whole text fits in the first line, but that's an error: when the text ends with \n for example, we want to remember the forced end of line and thus keep resume_at.

(By the way, original example in #557 now fails because of flex 😢.)

The bug was hidden until the optimization in 22d14ee (done after playing with #483) had been added. As there's no automatic line break with preformatted text, there's no need to check that lines can be broken as forced end of lines are supposed to be handled by split_first_line.

I've added extra tests to avoid another regression.

@liZe liZe closed this in a5ce96e Mar 1, 2019

@liZe liZe added this to the 46 milestone Mar 1, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.