Pdfmake – PDF printing in pure JavaScript
pdfmake.org
pdfmake.org
In my case, I have a Javascript app that stores critical information for offline use, and users want to be able to print that information nicely. So I generate PDFs in Javascript. This could make that much easier.
Indeed:
So: A a TeX compiler that can be called from JS can only be an intermediate solution.
I think http://txtjs.com/ goes in the right direction.
I don't really think calling TeX from js is a very good idea, nor do I really think canvas is a good idea either.
I do wish Adobe had gained more traction with css regions[cr] -- although I also understand some of the arguments against them[ch].
I still think the idea is good: css for style, semantic html for ... semantics -- and "layout html" for layout. I think pairing semantic markup with css columns is just a bad idea -- and it gives the kind of "half-power" that initially lead people to use tables for layout.
So Lie is right in that css regions aren't a great fit for html[ch] -- but I still think they're the best fit for html I've come across. I might be convinced that css regions are the kind of things that fit well with js/poly-fills[pf] -- although I'm sceptical. We know fonts are turing complete and have had security issues -- I don't see why we should need to implement core layout with js. At least I suppose "rogue" software vendors can choose to support css regions[cr] -- For eg an e-book reader based off of a subset of html+css, css regions might be a good fit, while avoiding the complexity of adding js support, and trying to make that secure (including proof against denial of service etc).
Thanks for the link to texjs, though -- I'll definitely have a closer look.
[ch] http://caniuse.com/css-hyphens
[ha] http://alistapart.com/blog/post/css-regions-considered-harmf...
what doesn't!
>What is the advantage over simply creating an appropriate LaTeX/ConTeXt document in the background and serving that?
the obvious advantage is that you wouldn't have to learn LaTeX/ConTeXt, no?
In Haskell this is possible with similar DSLs. Very useful to generate reports.
If you want to print a book or a perfectly aligned article do it in LaTeX
If you have a web-application however and it prints invoices or other documents pdfmake can be a good choice and an efficient solution
People don't want to wait 2-3 seconds these days to get a simple document on their printer. With pdfmake lots of standard documents will print in less than 300 ms and... it scales - as you do everything on the client side you don't have to care about server overhead, no matter how many concurrent users you have
Mozilla's PDF.js https://mozilla.github.io/pdf.js/
or
Parallax's jsPDF https://parall.ax/products/jspdf
jsPDF prints using:
var doc = new jsPDF();
doc.setFontSize(40);
doc.text(35, 25, "Paranyan loves jsPDF");
doc.addImage(imgData, 'JPEG', 15, 40, 180, 160);
Pdfmake on the other hand: var dd = {
content: [
'First paragraph',
'Another paragraph, this time a little bit longer to make sure, this line will be divided into at least two lines'
]
}First you would need a pure js web browser, the closest thing currently being zombie I think. If you didn't care about running on the server then you could take advantage of the browser the lib is running in to get the current computed layout from the active dom and transform into the PDF layout, still a big job but the heavy lift is done by the browser. Telerik does this in their Kendo lib, where they render a active dom element to thier abstracted vector graphics model, then have PDF, SVG and Canvas renders for that: http://docs.telerik.com/kendo-ui/framework/drawing/drawing-d...
A DSL designed for PDF creation is a much better way to approach this. It gives you way more control over what you're doing. Concerning pdfkit specifically, I think a JSON file is a gruesome way to design a PDF, but IMO it's still better than converting from HTML unless you're doing something very simple.
If someone (Apple or Google) would get wise and implement the full paged media spec then PhantomJS/wkhtmltopdf/your browser might be a viable option for full fidelity print output.
See: http://www.webkit.org/projects/printing/
Until then our apps will have to suffer with one layout language for viewing (HTML) and have another for print like this lib.
Simpler as in ease of use? Well that's subjective, some might find HTML easier than learning a new layout model, other might like something more focused on just PDF layout like this.
I use pdfkit because I have an offline-capable JS app with fairly rich document printing needs. A friendly layout engine on top can save a lot of effort making nice designs.
One issue we ran into in browser was the huge size overhead from vfs_fonts - is there a preferred workaround to this issue (we had to serve it separately from the rest of the app), or any solution in the pipeline?
On iOS, Apple disabled the API for local virtual printers. There are various "html-to-pdf" apps, but these often perform a non-interactive fetch of the source web page, which use different auth/cookies and can result in a PDF which is different from the one displayed by Safari.