Active
Project:
Certify
Version:
7.x-2.0-beta3
Component:
PDF generation
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
22 May 2012 at 05:25 UTC
Updated:
21 May 2013 at 07:15 UTC
It looks pdftk is for vps or dedicated servers. I am a shared hosting account user on godaddy. They have horrible support, i m very much regret now :-(
I think there should be much flexibility when choosing PDF generation options. Like fillpdf has fillpdf service. I have not used fillpdf, but this idea seems to be best fit in certify module.
Just opening this for future consideration.
Thanks
Ashish
Comments
Comment #1
fuzzy76 commentedActually, I would very much like to make the PDF generation part of certify by pluggable, so you could use other backends like online services and some of the HTML-to-PDF libraries out there. Unfortunately, I don't have time to work on that in the immediate future (but patches are welcome) and I can't agree with myself on how generic/abstract such and API should be. But this is definitely on my own wishlist as well, especially when pdftk is such a PITA as it is (only seems to fill PDF's on Linux and isn't maintained anymore).
Comment #2
afriend commentedThanks for reply.
This module is really a nice one. I really appreciate your and your team's effort for developing and maintaining this module.
Thanks
Ashish
Comment #3
wizonesolutionsAs the maintainer of Fill PDF (and the service), I'm pretty interested in the direction this takes as well. I wrote the pdftk integration for Fill PDF, but I don't run it on the service side anymore (I originally did). It can be a pain to work with indeed.
Comment #4
ontwerphuis commentedSubscribe
I'm in a similar situation - shared hosting. This module is really neat and does everything I need it to do. Would be great to use it more.
Thanks for a great module
Comment #5
icc commentedAgreed. It would also be cool if we could make it possible to generate the certificate from the node body field of the certification node, e.g. using wkpdf.
Comment #6
jack.r.abbit commentedWhen we first started looking at Certify, we found that we were unable to support PDFTK. So we've been running a hacked up version of Certify 6.x-1.0-alpha6 for a while now that we modified to use TCPDF (http://www.tcpdf.org/). The beauty of this one is that it is just a PHP script so you can just drop it into the site and point to it. There should not be any issues with server installs and what not. TCPDF uses an image as the background of the PDF, positions the user specific data to print on it and stores the PDF. But our version has a lot of hard code values for all the text positions and colors. This works for us but is not easy to maintain for everybody. Anyway, we are in the process of trying to take our modifications and apply them to the latest 6.x release of Certify. If I can manage to turn that into something that can be pluggable, I'll gladly share my work, though I will not be able to support it. We're also not using D7 so I won't be able help in that regard.
Comment #7
wizonesolutionsjack.r.abbit: The tough part about that is that everyone's PDFs will have different coordinates, no? Do you guys have a way to find the coordinates and endpoints of the fields, such that text can be positioned logically? If so...that'd interest me as an option for Fill PDF too.
To note on that, I've talked about Fuzzy76 about abstracting out the PDF-filling parts of Fill PDF and Certify into a shared API module...eventually. I think this issue makes sense to house conversation about that for Certify.
For Fill PDF, I've opened #1861926: Use PDF Forms API for PDF handling.
Comment #8
jack.r.abbit commented@wizonesolutions: Currently the coordinates of the text are just hard coded into our version of the module. Our use case is fairly limited so we don't have a need for multiple templates with different coords and what not on any given site (although the coords vary from site to site). When ever we have a new site with a new template, we just use a little trial and error in positioning during dev. My first step to abstracting that out would just have some fields in the Certify settings page and/or the Certificate creation form to enter those coords for each text field. At least that would mean we didn't need a different version of Certify for every site. If time allowed I would think that some sort of drag/drop type UI could be built that lets you upload your template image and position the text fields on it. But, if the whole PDF generation part was pluggable, others could build on that idea anyway they wanted. My thought was that Certify remains as the core of it with all the logic and hooks with Quiz, etc. But when it comes time to actually generate the Cert, it just hands off the printable data* to what ever PDF generator has been set up. We're a bit away from this yet.
But it is nice to hear that interest is there. I would think the focus should be on just getting the pluggable part going so we can move forward with letting anyone make kick-ass PDF generator integrations.
* side note: we also have an initiative to abstract out the source of the printable data. We currently have two versions of Certify that use either Profile or Content Profile to obtain additional printable data. So we have lots of work ahead of us to bring all our hacks into a single, reusable module that others may be interested in. Right now we've nothing to share.
Comment #9
wizonesolutions@jack.r.abbit - figured as much regarding the coordinates.
I'm consistently amazed at how little love the PDF format gets. I mean, it's used in so many places. I do think it's outdated, but is certainly nowhere near on the way out. Especially since it's a neat little package that can be signed and stuff, and it can be held to a strict format as dictated by regulatory agencies. But I digress.
I have started "the pluggable part" (in name only so far, but working on more tonight): PDF Forms API.
Comments on the spec/idea are highly welcome. Open issues or comment on an existing relevant one. The initial version should develop pretty fast because it can be based on code that already works.
I am upgrading this issue to normal. It's seen some interest. Right now, if I get around to refactoring Certify to use the API module, I'll submit a patch.
@fuzzy76: I'd think it'd make most sense to start a new branch for Certify (7.x-3.x) before swapping out how the PDF stuff works and since it'd add a new dependency. That might make the transition easier, and the upgrade path would be fairly simple (for Fill PDF, as of now I'll just have to migrate the PDF-filling options from Fill PDF to PDF Forms API).
Comment #10
phrankle commentedSome shared hosts actually already have pdftk installed on their servers. I use Bluehost and haven't had any issues.
Comment #11
oliver huynh commentedHi jack.r.abbit,
Can you attach your modified version of certify? I would like to look at how you implemented tcpdf!
Comment #12
fuzzy76 commentedMy current plan is actually doing a total rewrite of Certify as an integration towards the course module. Wether or not it will be a certify 3.x/4.x or a new course_certify module, I do not know yet.
Comment #12.0
fuzzy76 commentedediting for update message