Open jathayde opened 6 years ago
@unixmonkey is this likely solved by your solution here? https://stackoverflow.com/questions/44434529/wicked-pdf-how-to-remove-top-margin-from-cover-page
Have you checked that the HTML is valid? I had a similar issue, but after weeks of banging my head against the wall discovered that I had a <b>
tag that wasn't properly closed.
@kimchanyoung Thanks! HTML was valid. I did add closing /
for standalone tags (e.g. <hr>
). It seems that the line that was the culprit, however, was the Google Font loader on the cover. It's already loading on the main layout, but I had to include it on the cover to get it to work there. Going without it for now. Hopefully this might help someone else if they run into the issue.
I'll leave it to @mileszs to determine if this is actually a bug or not.
It sounds to me like the burden of rendering the cover (pulling in fonts and images) in your case is causing the rendering through wkhtmltopdf
to timeout and you are getting an incomplete document.
Increasing the timeout or using window_status
may help.
Any luck?
Sorry, @unixmonkey I missed your last comment. Let me try that now.
So setting a window_status
at the end of the checklist main file creates a non-timing out wait. Am I setting this wrong?
format.pdf do
render pdf: "#{@issueable.slug}_checklist",
disposition: 'attachment',
# view_as_html: true,
template: 'issues/checklist.pdf.erb',
dpi: '144',
# background: true,
timeout: '1000',
window_status: 'readytorock',
header: {html: {template: 'layouts/_checklist_header'}, spacing: 5 },
footer: {html: {template: 'layouts/_checklist_footer'}, spacing: 0 },
margin: {top: 30, bottom: 20, left: 10, right: 10},
cover: render_to_string('issues/checklist_cover.pdf.erb'),
show_as_html: params.key?('debug')
end
and in the end of checklist.pdf.erb
:
<script>
window.onload = function () {
window.status = "readytorock";
}
</script>
FWIW, it does spawn the command to wkhtmlpdf but it doesn't ever resolve.
"***************[\"/Users/jathayde/.rbenv/versions/2.4.0/lib/ruby/gems/2.4.0/gems/wkhtmltopdf-binary-0.12.3.1/bin/wkhtmltopdf\", \"-q\", \"--window-status\", \"readytorock\", \"--dpi\", \"144\", \"--margin-top\", \"30\", \"--margin-bottom\", \"20\", \"--margin-left\", \"10\", \"--margin-right\", \"10\", \"--header-spacing\", \"5\", \"--header-html\", \"file:////var/folders/25/q7y1f5px3xz8bw7sdzcyrz_c0000gn/T/wicked_header_pdf20180604-7285-1vz2ia7.html\", \"--footer-spacing\", \"0\", \"--footer-html\", \"file:////var/folders/25/q7y1f5px3xz8bw7sdzcyrz_c0000gn/T/wicked_footer_pdf20180604-7285-fp2qj3.html\", \"cover\", \"/var/folders/25/q7y1f5px3xz8bw7sdzcyrz_c0000gn/T/wicked_cover_pdf20180604-7285-1hu3lic.html\", \"file:////var/folders/25/q7y1f5px3xz8bw7sdzcyrz_c0000gn/T/wicked_pdf20180604-7285-hs4k7j.html\", \"/var/folders/25/q7y1f5px3xz8bw7sdzcyrz_c0000gn/T/wicked_pdf_generated_file20180604-7285-12908es.pdf\"]***************"
This may very well be a configuration issue vs a bug but I've not been able to get it to work over two weeks of trying.
The expected behavior is that adding a cover page would not affect the following page and would simply be the first page in the final PDF.
Actual behavior: PDF renders normally without cover (expected). Once cover is added, PDF intermittently renders without additional pages (cover only), or additional pages do not have images.
This occurs in both development and production, and the following links are to production.
https://www.patchvault.org/lodges/456a-powhatan/issues/checklist.pdf
Debug shows the rest of the content, without the cover page, as expected:
https://www.patchvault.org/lodges/456a-powhatan/issues/checklist.pdf?debug=true
This intermittently will render fine, or show subsequent pages without images (typical of when it does render), but mostly it just renders the cover. Disabling the cover in the controller action gets the other pages to render as expected. Here's the controller action (I have attachment disabled for development purposes):
and here's is the output in development to wkhtmltopdf:
The cover is a full HTML page as it wouldn't render styles without being one and calling the CSS file similar to the master layout file.
Software/version notes:
Ruby 2.4.0p0 Rails 5.1.5 Patch images are served from S3 via carrierwave & fog, other assets from asset pipeline Gems, etc are cached to vendor/cache