Extensive experimentation with the premise behind #327494: Image support has convinced me that when using the Tomcat + PHP/JavaBridge fill method, image support doesn't actually work. This is evident from the code, since there are only calls to FillpdfService::text. I can only assume that Fill PDF Service used to have this support baked-in somehow but now does not.
I've discovered a couple ways to get this going for the T+P/J fill method and will post a patch soon. Basically, I call a currently-unused method in the Java FillpdfService class called "image." It has a type parameter that can be passed "file" and which will cause it to look at the URL or absolute path it's given for the image file. In my lab setup, this actually worked, but only with LiveCycle Image Fields (which are really just glorified buttons), not Acrobat Buttons.
That said, I would rather have some documented support for this with limitations than none at all. The only choice I have to make is whether to go with URLs or absolute file paths. Absolute file paths imply permissions changes, potentially. URLs mean that the site has to be accessible. I'm highly inclined to start with absolute file paths and see what feedback I get. Permission models are sufficiently flexible that the Tomcat user can be allowed to see image files without incurring significant security risks...IMO.
If anyone wants to chime in on this and try to change my mind, now's the time.
Ultimately, I hope to make some changes to the underlying Java so that I can just pass the file contents as Base64, decode it on the Java side, and do things that way. Then I won't have to worry about file paths or URLs.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | fillpdf_1417398_image_support_7.patch | 3.08 KB | wizonesolutions |
| #1 | fillpdf_1417398_tomcat_image_support.patch | 1.11 KB | wizonesolutions |
Comments
Comment #1
wizonesolutionsHere's the first stab at this.
Comment #2
wizonesolutionsThis patch works! I've committed it to 6.x and need to port it to 7.x. The way to use it is the exact same as #327494: Image support.
Feedback and suggested enhancements welcome, but this should get most of you pretty far.
Remember, you need a LiveCycle PDF and you need to use an Image Field. This is the only field type that appears to work. Also, it will always fill in the image in portrait orientation, even if the PDF is landscape. Rotate your image (e.g. by populating a second file field with a rotated version in
hook_nodeapi, $op == 'presave'<code> or <code>hook_node_presavewhen D7 support comes. Then give Fill PDF the token for that field. How exactly this applies to your situation is beyond the scope of this module.Comment #3
wizonesolutionsA proper solution to this appears to be blocked by #691078: Field tokens and #1222592: Architecture RFC: Field token architecture. I could hack something together to pull apart the absolute path that the current token generates and try the relative version, but if file paths are aliased this would fall apart. I mean, the whole thing is already shaky, so I might do it as an interim fix, but I'd rather use proper file tokens. So I think I have to solve that issue in some way first, whether within Fill PDF or within another supporting module. Ideas welcome.
The goal is that I'd like to use [node:field_file_field:fid] as the token so that I could parse for that in the code, similar to how the D6 solution works.
Comment #4
wizonesolutionsTagging.
Comment #5
wizonesolutionsEntity Tokens from http://drupal.org/project/entity might help with this. Testing.
Comment #6
wizonesolutionsNope. I guess that only supports a subset.
Maybe something is wrong the with the Image field out of the box. I'll try adding another one to my demo site and see if still no tokens are available.
Comment #7
wizonesolutionsNope. Token module itself just has basic File/Image field support, it'd seem, due to the issues mentioned above. I don't understand the workings of Field API enough to know why it is difficult to provide deeper-level tokens for single-value fields, but there seems to be an element of unpredictability that I have yet to grasp. So this will likely get a temporary workaround until upstream (Token) support is baked-in.
Comment #8
wizonesolutionsOK, I've decided that some functionality is much better than none. I'm going to use a pseudo-token to accomplish this.
I'll call it
[stamp:field_name]for now and will document this. This token will have to be the only thing in the field, or it won't work (which is fine, since with an Image it wouldn't make sense to put anything else). Fill PDF knows which node or submission it's using for data, so I will use whatever is given as thefield_namepart of the token to figure out information about the Image's path and send that to the PDF.Is this a hack? Yeah, sorta. But at least it'll be documented.
Comment #9
wizonesolutionsThis approach worked, and I'm happy with it for now. Remember that you have to use the Tomcat + PHP/JavaBridge setup to do this. I will try to document that more clearly, as it's actually pretty easy to set up but gives the illusion of being difficult.
Here's this change in patch form, though it is already committed to 7.x-1.x-dev.
Comment #10
l00ph0le commentedIs it safe to assume that, Image support Only works on the Tomcat Based fill method...and the not PDFTK?
Comment #11
wizonesolutionsYes. It's a documented technical limitation (see the updated documentation).
Fill PDF Service will offer image-filling when I have the time to sit down and get it done. So, hopefully soon, although there will be a pricing scheme change when that comes (it will only affect existing subscribers if they want image-filling support). I'll leave it there for now.
Comment #13
wizonesolutionsl00ph0le: The service offers image-filling now. FYI