4 users online. Create an account or sign in to join them.Users
This is an open discussion with 59 replies, filed under Extensions.
Have a look at Force Download. I'm using it when I need to output PDFs.
Can someone post the sample code of page? I don't know what I am doing wrong, but all my styles are ignored in output pfd file. Is it possible to change the page orientation?
I modified the extension to use the dompdf library, which worked ok for simple layouts. But like (I guess) most of the libraries that implement their own layout and rendering engine you quickly get problems with more complex layouts, e.g. with floats and absolutely positioned elements. This weekend I played with the wkhtmltopdf library, which uses the webkit rendering engine. The downside is that you need to be able to install it on the server (it can be installed on Linux, Mac and Windows machines), but it produces superior results. I'm happy to release my modifications to the public after the current project that'll use it.
Yes, Jonas. Please do!
Echoing bauhouse, please release once your done! I'm in two minds with extension as URL to PDF, or just PDF generation in general, is a powerful feature, but the library that's required to make it all happen is very verbose and as Jonas mentioned, often produces unreliable results as the CSS gets more complex.
Where Symphony is so lean, TCPDF is definitely not.
Does anyone have a version of this extension working adequately in 2.3? If not, can anyone recommend a direction for me to go in trying to convert a Symphony html page to a PDF?
Like David, I am looking for a glimmer of hope to getting this extension running in 2.3 at an adequate level of performance. Anybody? :)
What error do you get in 2.3 with this extension? I haven't tried it myself but perhaps it's something simple that can be fixed quickly.
Like Jonas, I've played with wkhtmltopdf, which delivers OK results (it is buggy, and development seems to be very slow).
The good news, though, is that I've managed to get this running in the cloud. I am currently working on an extension that will allow all symphony users to use wkhtmltopdf in their websites, much like JIT.
Currently I am thinking of doing this: request the url with the page you want pdf'ed in the parameters, along with a pair of amazon S3 keys, and the server will immediately respond with a piece of XML telling you what the pdf will be named when it is converted and uploaded to S3. You can then use this filename in your links and enjoy pretty pdf's without installing anything!
I am definitely interested!
Great! I am currently about 90% there, I'll let you take a peek when it's done!
@bauhause: I've been able to generate PDF's and put them in my S3 account, all in the blink of an eye:)
If you want to give it a try, this is the URL schema you can use: http://wkhtmltopdf.rs.af.cm/?key=KEY&secret=SECRET&name=this%20is%20awesome&url=http://getsymphony.com&bucket=BUCKET
And the output should be something like this
edit: currently all files are kept, so there is quite a big risk of flooding your S3 bucket with duplicates. I do like to have unique names, just to be able to use a CDN to distribute them - and to be sure it's always the latest file I am serving. How to move from here I do not know: maybe I should work in folders (name/identifier.pdf) where the folder is purged before a new version is uploaded. Or maybe it should be done with a redirect instead. Not sure...
edit2 oh, and before you ask: no, I am not actively storing your amazon account details. For now there is no safe way to access this service; because the details are in the GET request, they will be transmitted over the open internet, and stored in the access logs. Please make a new pair, and discard them after testing. Thank you.
@creativedutchmen: You should really use SSL. Transferring the SECRET over an unencrypted connection actually burns it.
[EDIT]: Of course the credentials would still be in your logs. But they wouldn't be transferred unencrypted on the interwebs. (To anybody who is interested: If you use SSL, the "request" part of the URL — i.e. everything after the domain part — will be transferred after the encrypted connection has been established.)
@michael-e: I know. The problem is that I am hosting this (for free) on appFog, and to be able to use SSL requires a paid plan.
I plan on making a datasource type for this (using the providers) which will use a public/private key pair to encrypt the data before it is sent - working around the SSL limitation. However, since that will be a bit of work, I'd like to know who would be interested before I do so:)
An update from my side: I think I got a pretty good solution in my head right now. Because the pdf generation is quite a time consuming task, and the S3 api isn't the fastest I've seen, I am pretty confident the pdf generation needs to happen in the background, and as infrequent as possible.
One idea I had was basically to cache the response for a long period of time, but that would render stale pdf's when your content changes frequently. So, I am pretty sure a "push" model is more appropriate than a "pull" model.
Because I want to keep this extension simple, I think the best way to go around this is by splitting the extension up into two parts: a background process which will send the requests to the wkhtmltopdf service, and a listener, which will add processing jobs to the background queue when their pdf need to be updated.
Right now, it makes most sense to me to let the listener add a job when an entry is created or edited (from either the frontend or backend). To let the service know what URL it should fetch, I am thinking of using the entry_url field, which is made for exactly this.
Now, because there will be use-cases for which this is not sufficient (editing an author, for example, should also regenerate all articles written by this author), I shall expose the functions to add jobs to the queue in a very simple API.
If you want php background processes, there's an app for that :)
Does that work with cheap shared hosting?
You already know the answer don't you? Well, you probably could implement different drivers.
Yep, I'd much prefer to use something rock solid but the whole point of this extension is that it can run on shared and small hosting packages, where you do not have access to the wkhtmltopdf application...
But, fortunately I have some experience with this with the ENM, which uses a background process that works even on the cheapest hosting provider here in the NL, so I can just borrow code from there.
Create an account or sign in to comment.
Contact the team
Symphony • Open Source XSLT CMS