The official GitHub repository does release official packages and binaries for the newest stable version – but the prerelease (0.13 at the moment), which may or may not fix issues further on in the list, is nowhere to be found – and back to the build issues we go. This makes getting at the newest version hard. One Docker Hub repo author stated problems with compiling it under two hours – which is Docker’s timeout for automated builds. Difficult to buildĬompilation requires Qt (currently an obsolete version) and WebKit, both hefty codebases. There are eight reasons why wkhtmltopdf shouldn’t be used for anything serious: 8. You can't make it look pretty and I'm fairly certain it's text only, but it'll print out exactly as it appears no matter what browser you are using.TL DR: replace it with weasyprint. If your reports don't need anything too fancy and they already pop out in HTML, you can use html2ps | ps2pdf to get something kinda resembling the original webpage. It worked for me and my version of reader, but I didn't dare put it into production since I had to change the spec version fpdf inserts into the header (1.3) to one that supported overriding the printer options).
#Pdfkit vs princexml pdf#
(I hacked it into fpdf once, but it was essentially a copy-and-paste of a command from another pdf that was able to force me to print with auto-fuckup-and-center turned off. Nowadays I use PDF, though several PDF generation libraries I've tried had serious deficiencies like being unable to tell me how much space a block of text will take before it places it on the page, or being unable to override Acrobat Reader's default printing settings, which fuck up anything you're trying to print onto an existing form. There's a table printing bug from 2005 that is still open, though fortunately my specific flavor of printing problems (entire rows of data going missing at page breaks) eventually went away several versions after firefox 2.
I bent and bent, then cried and gave up and I had to tell my users to use IE. I have been forced to bend crap environments to my will and I suspect that most developers around slashdot have bent bad systems until they cried but made them work in the end. Don't tie your application down to a specific environment understandably web design is like trying to make a shoe that fits everybody, but making everybody else lop off toes to fi No matter how 'great' it looks in X build of Y browser. Browsers make decent end user solutions for light web apps, but finding an enterprise class solution that will only work for one build on one browser is like telling golfers they all have to use the same set of clubs to complete a course. Sorry if this seems harsh but that's my opinion. There's no way I'd be happy having to use not just a particular browser, but a particular version of that browser - who are you trying to kid? The client and the user, it seems. It seems you want to have something you can show your client 'There! it works on THAT browser!' instead of thinking about the common denominator. Stop complaining and trying to find some panacea for your architecture problems.
#Pdfkit vs princexml mod#
Wish I had mod points, parent is absolutely correct. Here's a blog on linking Ruby on Rails with Silverlight as well:
#Pdfkit vs princexml how to#
Here's a blog on how to implement it: Īnd here's Microsoft's page hyping it:
That, in combination with the ability to pretty much lay things out exactly as you want, export to an image or text format, export the app to an out of browser desktop app, and print in whatever format you see fit, makes it ideal for the kind of ticketing system you're talking about. I will be flayed alive, but Silverlight 4 is a "Rich Internet Application" framework and with the most recent version, they built in some very tight and effective printing functionality.
0 kommentar(er)
