Instead of using the header/footer you could use CSS3 paged media and https://www.pagedjs.org/. So you get full control over the page.
Sebb
danferreira
Hey @maltoe
Thanks for the hard work and this nice lib
It works like a charm
Sometimes I need to print very (>>very<<) large pdf files and the memory consumption jumps too high
Would it be possible support transferMode as ReturnAsStream?
If you think is something achievable I could try to implement it. (I’m pretty newbie in Elixir though)
0
maltoe
Hey @danferreira
The streaming mode is something I’ve always wanted to support (and basically replace the default “give-me-the-full-blob” mode with it), and yes, of course it should be generally possible to do. However, it won’t be easy, both in terms of additional parts of the protocol needed to be implemented (i.e. how to read from the returned stream) and in terms of refactoring of the library architecture.
Could you open an issue in the repository? If you want to tackle it, feel free to take a look, and we can discuss ideas there. If you think it’s too hard, I’d also give it a try at some point, but can’t make any promises about the timeline, unfortunately.
cheers & thanks for your kind words!
malte
3
soup
Klohto
silverdr
Hello @maltoe. Just came across your lib and put it to work in the current project. Over the last number of years I always used https://wkhtmltopdf.org/ with very good results (Yes, I read your text saying that you might not be able to concur) so I’d normally do the same this time. Especially that there is a well established Elixir wrapper for it. But this project is a little different than previous ones. There I typically had a “web view” and “print view” separated, both with different markup. This way I was able to fine-tune the markup fed to wkhtmltopdf independently from the browser window view of the same document. This worked excellent for me. In this project though I want users to be able to press the key combination they usually press in order to print the webpage, and have the printed (or browser-pdf-exported) document looking the same as it looks on a generated PDF. This is where things start to be “less than optimal” for wkhtmltopdf if I don’t want to scale back the browser view to the HTML and CSS, which wkhtmltopdf can chew. Especially Flexbox stuff is problematic for it. This is an understandable result if the underlying WebKit hasn’t been updated for a long while. Therefore, all in all looks like a perfect moment to give a stab at something else then.
Theoretically I could still use the PdfGenerator as it currently supports generating PDFs through Chrome too but the first point on your features list is such a teaser that I couldn’t resist 
I mean the part about “Node.js” of course…
So, I’ve got the first document saved in PDF format relatively quickly, proving that your thing actually works Moreover the output looks the same in the PDF generated from ChromicPDF and the one “printed to PDF” from browser window. This is exactly what was needed and while it was to be expected it is still nice to see this be in fact the case. So far this is all great (and here comes the “but”) but…
- whether pooled or “on_demand” it is slow. About 2 to 2.5 times slower than processing the same HTML with `wkhtmltopdf. This means that while I was usually able to deliver generated PDFs synchronously in less than a second even under some load, over two seconds with no load begs for async processing (and a job queue!)
- the output is “bloated”. This type of documents comes out of
wkhtmltopdfas about 40KiB. Maybe 50 KiB on occasions. Chrome puts out not less than five times as many bytes…
Please don’t get me wrong - this is not a complaint about things I know you have little to no influence on. It is more for others about what to expect if someone finds himself in a position similar to mine: I really don’t feel like rewriting the whole, fine-tuned markup for wkhtmpltopdf and manually (well, “eyeually”) testing – how else? – that the two generation paths deliver visually the same result. All in all I haven’t yet 100% decided but I am very much tending towards ChromicPDF. Vision of writing two sets of markup for each type of document, and especially maintaining them later in visual sync is a highly un-promising one
0
silverdr
@maltoe Oh, and BTW - when trying to convert_to_pdfa/2 I am getting:
** (RuntimeError) /usr/local/bin/gs exited with status 1!
GPL Ghostscript 9.56.1: Unrecoverable error, exit code 1
(chromic_pdf 1.2.0) lib/chromic_pdf/utils.ex:53: ChromicPDF.Utils.system_cmd!/3
(chromic_pdf 1.2.0) lib/chromic_pdf/pdfa/ghostscript_worker.ex:77: ChromicPDF.GhostscriptWorker.pdfinfo/1
(chromic_pdf 1.2.0) lib/chromic_pdf/pdfa/ghostscript_worker.ex:44: ChromicPDF.GhostscriptWorker.create_pdfa_def_ps!/3
(chromic_pdf 1.2.0) lib/chromic_pdf/pdfa/ghostscript_worker.ex:29: ChromicPDF.GhostscriptWorker.convert/3
(chromic_pdf 1.2.0) lib/chromic_pdf/pdfa/ghostscript_pool.ex:35: anonymous fn/5 in ChromicPDF.GhostscriptPool.convert/4
(nimble_pool 0.2.6) lib/nimble_pool.ex:349: NimblePool.checkout!/4
(chromic_pdf 1.2.0) lib/chromic_pdf/api.ex:88: anonymous fn/4 in ChromicPDF.API.do_convert_to_pdfa/4
(chromic_pdf 1.2.0) lib/chromic_pdf/api/telemetry.ex:8: anonymous fn/2 in
[…]
Does that ring any bells?
0