I want to create a PDF report within a browser extension tab. I want to be able to add graphs, text, UTF-8 support, images, position text but nothing overly crazy in terms of styling and layout apart from that.
I've been reading about the limitations of jspdf (no UTF8 support) and pdfmake. It seems like they'll be plicated to work with lots of gotchas.
One idea I have is this:
Put directly on the page the HTML needed for my report.
Use CSS to hide everything but the report HTML and use "@media print" styles to style the report.
Trigger "window.print()" to print the page in JavaScript. Chrome shows a preview and lets you save to PDF in a click. Firefox's print preview shows a preview and the interface is a bit more messy but you can save to PDF in a few clicks.
Am I missing something? Are there any major downsides to my approach? Maybe OS specific issues? Why would you use jspdf or pdfmake over this?
I don't see this approach being suggested anywhere which I find strange. The only downside I see is the user may be confused about why they're being asked to print something when they weren't expecting a PDF but as the reports aren't generated often it's not a big deal here.
I want to create a PDF report within a browser extension tab. I want to be able to add graphs, text, UTF-8 support, images, position text but nothing overly crazy in terms of styling and layout apart from that.
I've been reading about the limitations of jspdf (no UTF8 support) and pdfmake. It seems like they'll be plicated to work with lots of gotchas.
One idea I have is this:
Put directly on the page the HTML needed for my report.
Use CSS to hide everything but the report HTML and use "@media print" styles to style the report.
Trigger "window.print()" to print the page in JavaScript. Chrome shows a preview and lets you save to PDF in a click. Firefox's print preview shows a preview and the interface is a bit more messy but you can save to PDF in a few clicks.
Am I missing something? Are there any major downsides to my approach? Maybe OS specific issues? Why would you use jspdf or pdfmake over this?
I don't see this approach being suggested anywhere which I find strange. The only downside I see is the user may be confused about why they're being asked to print something when they weren't expecting a PDF but as the reports aren't generated often it's not a big deal here.
Share Improve this question asked Mar 23, 2018 at 3:05 fstrfstr 9403 gold badges11 silver badges33 bronze badges4 Answers
Reset to default 10It is exactly the opposite of what Marko Tošić said. Actually, printing from the browser does NOT generate PDF as an image (you can test it quickly yourself). But a lot of times you need to use HTML->Canvas with jsPDF/pdfmake.
pdfmake does not support HTML->PDF very well: https://github./bpampuch/pdfmake/issues/205 jsPDF does not support external CSS when converting HTML to PDF.
In pdfmake and jsPDF, If you want to make your PDF to look the same as your HTML, you will need to do HTML->Canvas then paste canvas as a picture inside of PDF.
In terms of HTML->PDF, printing from the browser always has a better result than the javascript PDF libraries.
If you want to make the PDF file downloadable, you may want to look into phantomJS or headless chrome at the server side.
To answer your question:
Benefits of jspdf/pdfmake:
- As you mentioned, jspdf/pdfmake gives the user true "download" experience, instead of repurposing "print" as download.
- It does not require a server side implementation pare to phantomJS or headless chrome solution.
Benefits of print:
- Better HTML->PDF results (support all HTML tags and CSS).
Usual requirement for such generated PDF files is to have bookmarks, TOC and other links - which cannot be achieved with printing from browser.
As far as I know, printing from browser always generates PDF as image (you can't select text or elements). Because of that filesize is bigger. I think both of that approaches use ht2ml->canvas then paste canvas as picture inside of PDF.
jsPDF and pdfmake will let you generate PDF with "real" text and elements. It's harder to do, but quality and filesize are better. Depends on your use case.
Anything related to the window.print() API will stop/pause the JavaScript engine of the browser tab calling that API. So if your page or application requires JavaScript running continuously in the background, creating the PDF in a new tab might be the better solution.