dompdf
Columns layout issue
I am trying to create a layout with columns by using dompdf. After some research I used display: inline-block; instead of float: left;
The problem is next:
If I have 2 columns (column1 and column2), column1 will generate on page1 and if column1 exceeds page1 and the content goes on page2, then the next column (column2) will be generated on page2, not on page1 as it should be.
Do you know how to fix this issue with columns in dompdf, or give me an advice how to successfully do this?
http://stackoverflow.com/questions/37100722/columns-layout-by-using-dompdf
There isn't really a way around this unless you know that one of the columns will always be shorter than the page height. Otherwise you're bumping up against a quirk in the way dompdf parses documents. If you want to continue using dompdf your best bet would be to generate the two columns in separate documents and merge them using something like fpdi.
@bsweeney I replaced columns with tables. So now I have a table with a row and 3 columns. The problem is this: if the content of one column exceeds the height of current page, then it goes in a very long processing time or it breaks/crush. So this is not working also. Should be a fix for this by using the css tags page-break-* ?
So what is the option if I want to have 3 columns on a page, and a column to have the possibility to break it`s content on the next page also.
I don't have a good work-around at this time. If you can post a sample of the type of content you're working with we can take a closer look and see if there's another way to achieve the desired results.
I'm sorry, but since my problem is related to the described above, I'll post here. Since we cannot use table layout due to the known problem with page-breaks inside table cells, we were researching for an alternative ways to accomplish our tasks. We decided to use layout with DIV-s positioned with float:left and precise margins, but it displayes a strange difference between the results of HTML and PDF rendering. See the files attached for the sources (I had to compress them - it's not allowed to attach HTMLs, sic!) and PDF results.
Is there any way to fix or workaround the problem?
resume_with_clear.pdf resume_without_clear.pdf sources.zip
P.S. We're using DomPDF 7.0 beta 3 for now, if the problem was fixed in the final release - please let me know, I had no chance to check that yet...
@marrch-caat you can use display:inline-block instead of float, that will do. But the problem is if the content of the column in the left side goes on the next page, than the content from the right side will start from the new page. I cannot see any differences between your files, all look the same...
@marrch-caat problem is not addressed in the final 0.7.0 release. It will require a significant change to how dompdf parses documents, but it is one we are considering using to help deal with other issues.
To our great pity, variant with display: inline-block is useless for us :( Depending on the issue description, I supposed the problem won't appear if we have content in the 2nd column always larger than the one in the 1st column. But it's not the case :( Screenshot of the result is here: http://take.ms/topU0g You may see that if the content in the 2nd column wraps to the next page, it's rendered there as if it were the only one column, without any left margin. @bsweeney Do you see any other way to implement 2-columns design or to anyway workaround the bug?..
In addition to the previous message: attached are HTML and PDF genereated from it using display: inline-block and left margin for the right block. You may see that when the right block is wrapped to the next page, it's rendered there without margin. It's a bug for sure. And even if I create a HTML page with ONLY ONE div with margin-left and the div will wrap to the 2nd page, in PDF the 1st page will be with margin and the 2nd without it. resume-29684110 (3).pdf source.html.zip @bsweeney Is there any way to get this problem fixed soon or to workaround it?
@bsweeney Couldn't you please provide some estimates when could we expect AT LEAST ANY of these bugs to be solved? I suppose that column design is quite a popular and an actual need for many users, so having at least one way to implement should be quite an important task... Is it probable that at least the last problem with a disappearing margin will be solved at 0.7.1?
@marrch-caat I'll try to get back to you this week on what's possible, not possible.
@marrch-caat typically what I would suggest for a multi-column layout would be to render the two columns separately in separate documents then use something like FPDI to merge them. The problem with your document in particular is that content in one column lines up with content in the other (i.e. the content in each column is not independent of each other).
The sample you gave has the left column significantly shorter than the right. In that case I would actually style the document more like the following (using 0.7.0):
<style>
.BlankResumePrint_row {
position: relative;
width: 100%;
}
.BlankResumePrint_row_left {
display: block;
width: 20%;
margin-right: -20%;
float: left;
page-break-inside: avoid;
}
.BlankResumePrint_row_right {
display: block;
font-size: 13px;
margin-left: 20%;
padding-left: 12px;
width: 80%;
}
</style>
The results with that styling are not ideal, but they are acceptable.
Really, if you can, I would suggest using a headless browser like PhantomJS. I hate to see you move away from dompdf but I'm not sure yet when we'll be able to resolve this issue. Probably not with 0.7.1.
@bsweeney Well, I'll try to use the CSS you provided and then get back to the issue with the results.
Wow! That works (at least for now) on all our two-column samples! Thanks a lot, @bsweeney !!!! @Al3xR0 Looks like the styling provided above could help you as well. I really can't understand the magic of margin-right: -20%, but that works great in DomPDF and affects nothing on web. Fantastic!
The margin-right styling is a quirk of dompdf. Most browsers will place floated elements inside the margin of an element without affecting the content unless the float width is larger than the margin. Dompdf adds the float element width to the margin, displacing content next to it. Adding negative space equal to the adjacent element's margin negates this displacement.
I haven't fully tested across browsers, but I believe they'll just ignore the negative margin on the floated element.
Well, I tested in the major five (only the last versions, though), and it worked fine. But there is another problem :( If the content in the left column is shorter, the left cells overlap: http://take.ms/JrmBG @bsweeney , do you have some more magic for it? Pleeeeeeeease... :)
I haven't had a chance to take a closer look yet. If you add clear: both; to the .BlankResumePrint_row styling does that help?
@bsweeney We checked that, it doesn't help :( We tried .BlankResumePrint_row:after { clear: both; } - that should (in theory) help, but it didn't :(
Our :before and :after support still needs a bit of work. For the most part the layout on these elements doesn't work quite as well as it needs to. Relating to your particular layout, adding the clear:both; declaration to the :after pseudo-element doesn't have any affect.
I found that just putting the clear declaration on the row itself works:
.BlankResumePrint_row:after {
display: block;
height: 1px;
clear: both;
background-color: green;
}
@bsweeney We're now using the new 8.0 release of domPDF, and many issues were resolved in it, great! But I'm not sure if this issue was anyhow addressed in it? Couldn't you please let me know if there are any new workarounds available for the issue?
If the author can provide any information known to be related to this problem people can create a PR to help out.
Any input on this? Please help us out.
This works!!! The trick is to make both columns to have the same height automatically. what you do is make both divs/columns very tall by adding a padding-bottom: 100% and then "trick the dompdf" into thinking they aren't that tall using margin-bottom: -100%.
.container {
display:block;
width:100%;
}
.column {
float: left;
padding-bottom: 100%;
margin-bottom: -100%;
}
<div class="container">
<div class="column">
Some content!<br>
Some content!<br>
Some content!<br>
Some content!<br>
Some content!<br>
</div>
<div class="column">
Something
</div>
</div>
This works!!! The trick is to make both columns to have the same height automatically. what you do is make both divs/columns very tall by adding a padding-bottom: 100% and then "trick the dompdf" into thinking they aren't that tall using margin-bottom: -100%.
.container { display:block; width:100%; } .column { float: left; padding-bottom: 100%; margin-bottom: -100%; } <div class="column"> Some content!<br> Some content!<br> Some content!<br> Some content!<br> Some content!<br> </div> <div class="column"> Something </div>
That seems like a way to circumvent the problem, but what will happen when dompdf updates and the behavior of this bug changes?
This should really just be solved by Dompdf adding support for the columns CSS property. https://www.w3schools.com/cssref/css3_pr_columns.asp
