I'm converting a HTML page with wkhtmltopdf from HTML to PDF. My page consists of a left column with full bleed background color. How can I force a bottom/top padding so that my content is not pushed against the edge of the page (as demonstrated below), while keeping the full bleed background color for the left column?
I've tried p {page-break-inside: avoid;} without success. Setting padding on the page level goes against the full bleed.
Related
Assuming I print a small amount of text into a PDF document, I like to know how much of the page is actually used by the text.
For example, if I render a short text paragraph into a PDF document, I like to learn the content height of only that text, not of the entire A4 (letter) page.
Background
I need to render a long HTML page into a PDF document that uses a smaller page size. The result is that the content gets rendered into several PDF pages. I currently use NSPrintOperation for this.
The challenge is that I also need to render a footer page into each page. For this, I need to dynamically determine the height of that footer so that I can set the page's bottom margin accordingly, resulting in the footer area be kept free when rendering the main (body) HTML content. Once that's finished, I can then add the footer to each page in a separate step (using CGPDFDocument).
I wish there was a simpler way, but it seems that the macOS HTML renderer cannot handle html footers when printing multiple pages.
I found a solution, though that's a bit ugly:
Generate the PDF with the footer content, so that it renders at the top of the page (margins set to 0).
Read the PDF into NSPDFImageRepMBS
Create a NSImageMBS and add the imageRep to it with addRepresentation:
Now the image has a size of the original PDF page, but contains only the drawable region of the footer content - the rest of the image is clear.
By scanning the image's lines from bottom towards the top, looking for a non-clear line, the height of the footer content can be determined.
With the footer height known, I can now render the main content to a PDF with the bottom margin set to keep free the footer area
Finally, I create a new CGPDFDocument, going over each page of the main PDF, drawing thes main pages along with the footer (offset into the page's footer area) into each page.
Background
I have a standard three column layout where the first column is floated left, and the third column is floated right. The first column needs a full-height background.
This layout is for a template, so any of the three columns could have the longest content.
I can't change markup source order, so display:table solutions are not possible.
I can't add any DOM nodes.
The layout is centered with a minimum and maximum width, so I can't attach a vertically-repeating background image to the page with the built-in background color.
It needs to look OK in IE7, but IE8+ needs support.
Solution
To achieve the full-height left column, I created a pseudo-element on colLeft. That pseudo-element has fixed-positioning set to the viewport bottom, 100% height, and placed behind the left column. This solution is awesome because:
IE8+ supports pseudo-elements.
The pseudo-element is attached to the left column, so if the template doesn't have a left column, the background naturally isn't there.
By not setting a left or right attribute, the fixed-positioned pseudo-element stays with the left column (good for the centered layout).
Here's an example on CodePen.
(Make sure that the Document Mode is following the Browser Mode when viewing CodePens in IE).
Problem
In IE8 the full-height left column background only extends down to the initial viewport bottom (the fold).
I created another test with a new leftColBg node instead of the pseudo-element. This works as expected in IE8, meaning that the fixed positioning should work.
Here is the best explanation that I can find on IE8 and generated content: Why does a filter gradient on a pseudo element not work in IE8?
I think IE8 is incorrectly positioning the generated content, because it's not an "object" that contains content. Can anybody better explain this IE8 bug? Is there a fix?
Suppose you have iframe elements in your page and you try to inspect its content. When you select a particular element within iframe content document, IE developer tools draws blue border around it, but with every nested iframe it adds additional 2 pixels offset.
You can see an example of this in this image below where I've manually added background to html and body elements making them visible in JSFiddle. I then selected body element within the iframe and as you can see indicator is offset by 2 pixels right and down.
If there was an additional iframe within this one, additional 2 pixels would be added getting to 4 pixels etc.
Is it possible to avoid this selected element indicator offset in Internet Explorer Developer Tools?
Note: Every time I have to use Internet Explorer a bit of me dies inside. If I have to use it along with developer tools a larger chunk of my life goes bananas.
For some reason a basic unstyled DIV element has extra height tacked onto the bottom when it contains a VIDEO element (and possibly other elements - I haven't tested with many types).
<div><video src="my_movie.ogv"></video></div>
I have the above line of code in a barebones base HTML file. With Firefox or Safari/Chrome's (if I use an .mp4 file instead of course) DOM inspectors on I see that the computed height of the DIV element is anywhere from 2-5 pixels more than the height of the VIDEO element.
This doesn't seem like expected and intentional behavior. If I put a P element in there instead of a VIDEO element, for example, the DIV doesn't have any of the extra height.
Does anyone know why the browsers are rendering this configuration of DOM elements in this way?
If your markup is as above and there are no special styles applied to it, then the behavior you see is required by the CSS box model; the space is the size of the font's descent, because the bottom of the video is placed by default on the baseline, not at the bottom of the text. In particular, see https://bugzilla.mozilla.org/show_bug.cgi?id=22274#c55 for an explanation in spec terms and https://bugzilla.mozilla.org/show_bug.cgi?id=22274#c37 for how to get rid of the space if you want to. You could also set line-height on the block to 0 to get rid of the space; which approach you take should depend on your other design constraints.
I wonder how to define the line spacing in a multi-line lable or text item for pdf output. While increasing the line height within a style works fine, decreasing the height to reduce line spacing doesn't seem to work.
Any suggestions on how to reduce the line pitch?
Thanks
Try removing top and bottom padding. I don't know about labels and text items, and maybe it's not the same, but I had a similar problem in a table with 8pt font in the details. It would look fine in HTML, but in PDF the space between the lines would be huge.
A good trick is to set background colors on the item and the surrounding cell and whatever other elements you have and you'll be able to see which element steals the space.
Then tweak the paddings, line height and font size to reduce the extra space as much as possible. Use the 'Advanced' properties panel (or preferably stylesheets), as line height is not available in 'General' for some elements.
I managed to get my table looking great doing this if I removed ALL top and bottom padding (from row, cell and data element), used a row line height of 10pt and a font size of 8pt.
There seems to be a bug that causes the actual text inside the data element to be somehow padded at the top no matter what in PDF. If you color the data element background and then select the text in the report, you'll see that the text is set too low on the element, overflowing a little at the bottom. Thats the reason 8pt font and 8pt line height wouldn't work for me, it would cut off the bottom of the text.