-
-
Notifications
You must be signed in to change notification settings - Fork 710
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
Table background colour bleeds beyond table cell boundaries #151
Comments
This looks like a bug, thanks for reporting it! |
The bleeding is caused by incorrect clipping of the <style type="text/css">
table { background-color: blue; }
td { background-color: yellow; }
tr {
background-color: red;
padding: 1cm;
}
</style>
<table><tr><td>A</td></tr></table> |
The problem might be be due to padding_left / padding_right / padding_top / padding_bottom, in that editing formatting_structure/boxes.py as follows: def padding_width(self):
"""Width of the padding box."""
# return self.width + self.padding_left + self.padding_right
return self.width
def padding_height(self):
"""Height of the padding box."""
# return self.height + self.padding_top + self.padding_bottom
return self.height ... makes table background colours align with their tables (though it doesn't do a perfect job, e.g. it clips off the bottom of divs and font descenders can escape their containing table cells). Does that help track down the bug? Sorry, have been unable to find the root cause as yet. Any progress elsewhere? |
... or, rather, that table cell height/width are being calculated without taking account of padding properly (or some confusion between "cell" and "cell contents" height/width)? |
This bug is caused by the way background colors are drawn in tables. When a color is set to a line, we should only draw the background color on its cells, but not on the spaces between the cells. |
Version 0.26 ------------ Released on 2016-01-29. New features: * Support the `empty-cells` attribute. * Respect table, column and cell widths. Bug fixes: * `#172: <https://github.com/Kozea/WeasyPrint/issues/172>`_: Unable to set table column width on tables td's. * `#151: <https://github.com/Kozea/WeasyPrint/issues/151>`_: Table background colour bleeds beyond table cell boundaries. * `#260: <https://github.com/Kozea/WeasyPrint/issues/260>`_: TypeError: unsupported operand type(s) for +: 'float' and 'str'. * `#288: <https://github.com/Kozea/WeasyPrint/issues/288>`_: Unwanted line-breaks in bold text. * `#286: <https://github.com/Kozea/WeasyPrint/issues/286>`_: AttributeError: 'Namespace' object has no attribute 'attachments'.
I'm hoping to switch from xhtml2pdf to weasyprint and have been trying it out; generally it seems excellent, and many problems I've had have have come down to my own deficiencies in CSS understanding. However, I think this one's a bug:
I find that for table rows (tr) with background-colour applied, the colour bleeds beyond the edge of the cell. For comparison, neither Chrome nor xhtml2pdf do this, and I don't think there's any CSS option that instructs this to happen (though I'm happy to be corrected!).
I'm using a fresh install of weasyprint (from pip install weasyprint) as of 5 Jan 2014.
HTML and corresponding PDF are at:
http://egret.psychol.cam.ac.uk/publicworkspace/test_weasyprint_bleed.html
http://egret.psychol.cam.ac.uk/publicworkspace/test_weasyprint_bleed.pdf
... look particularly at the grey and black shadings bleeding to the right and below the table row to which it is applied.
The CSS is embedded in the HTML, and the PDF was generated using "weasyprint test_weasyprint_bleed.html test_weasyprint_bleed.pdf". There are a couple of errors relating to the image links being dead, but that's for a different part of the document so I presume that's not relevant (and the bleed still occurs when the image links work). There's also an "@frame" error (relating to fact that this source was originally for xhtml2pdf) but I presume that's irrelevant as well.
Many thanks for your attention, and congratulations again on a fine piece of software!
all the best,
Rudolf.
The text was updated successfully, but these errors were encountered: