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.

Sign up for GitHub

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

Jump to bottom

Container with space padding around a word wider than it's containing block causes infinite recursion #2188

Closed
bsweeney opened this issue Jul 5, 2020 · 1 comment · Fixed by #2200
Closed

Container with space padding around a word wider than it's containing block causes infinite recursion #2188

bsweeney opened this issue Jul 5, 2020 · 1 comment · Fixed by #2200
Labels
bug layout Priority-Critical
Milestone
0.8.6

Comments

@bsweeney
Copy link
Member

bsweeney commented Jul 5, 2020

When an element contains a word that is wider then the element's width, Dompdf appears to enter an infinite recursion.

The following minimal case illustrates the issue with the 0.8.6 code base (current "develop" branch).

<div style="width: 5em;">
  mmmmmm
</div>
@bsweeney bsweeney added this to the 0.8.6 milestone Jul 5, 2020
@bsweeney
Copy link
Member Author

Looks like this is caused by 55868bf. I'm guessing the change made results in a discrepancy in the text being parsed in two separate pieces of code. I'll take a look but if correcting the issue is non-trivial we might just revert and move forward with the 0.8.6 release, pushing off the text alignment issue (#1174) for 0.8.7.

@bsweeney bsweeney changed the title A word wider than it's containing block causes infinite recursion Container with space padding around a word wider than it's containing block causes infinite recursion Jul 19, 2020
bsweeney added a commit that referenced this issue Jul 26, 2020
@bsweeney
Trim white space after line new line text split
adc6f13 
If we trim white space at a split before a line break has been applied then we may end up collapsing the space between words. And if we trim before determining the index at which to split we may end up with an infinite loop where the space character is put into a new frame in the same line over and over again. We only want to trim the white space from the current text frame if the split is going to result in a new line.

Also, we no longer need to add a space when calculating justified text line width. This was an artifact of the previous logic that did not always remove trailing spaces from a line.

Addresses #1174, #2188
@bsweeney bsweeney mentioned this issue Jul 26, 2020
Merged
@bsweeney bsweeney linked a pull request Jul 26, 2020 that will close this issue
Trim white space after new line text split #2200
Merged
@bsweeney bsweeney closed this as completed Aug 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug layout Priority-Critical
Projects
None yet
Milestone
0.8.6
Development

Successfully merging a pull request may close this issue.

Trim white space after new line text split dompdf/dompdf
1 participant
@bsweeney