Hi there ... seems like that combination doesnt work, first of all I've realized the linux paths, that wont work with win, and secondly that the exec function returns no arrays, even if I correct manually the path.
Any ideas?
Hi there ... seems like that combination doesnt work, first of all I've realized the linux paths, that wont work with win, and secondly that the exec function returns no arrays, even if I correct manually the path.
Any ideas?
Comments
Comment #1
zewa commentedDunno why, but now, after restarting my machine it returns values :)
now the next problem is the "fill_form output flatten" is throwing an exception
Any ideas ...?
Comment #2
wizonesolutionsHi zewa,
Bumping the version on this since pdftk wasn't in Fill PDF until 6.x-1.12.
I haven't tried the module on Windows because although I run Windows, I develop on Linux. I would say to double-check your pdftk installation. If I have some time, though over the next couple days, I'll try digging up the old WampServer and looking into this. But what I recommend doing is figuring out what command it's running (currently, it leaves the XFDF file it generates right in the files directory) and then trying to run it manually. Do you still get the same error? If not, then perhaps PHP can't access either pdftk or libiconv.dll.
In that case, you could try opening the Services console (start -> run -> services.msc) and checking which user is running Apache. If it is System or NetworkService, try going into the service properties and changing the user to the user you log in as, since we will know at that point that pdftk works for that user.
Hope this gives you some ideas. Ultimately, this issues appears to be environmental because the code is not mis-performing; it's simply not working.
Patches to improve cross-platform compatibility are welcome of course as well, if you want to contribute back.
Comment #3
zewa commentedHi there ... thx for the reply.
Well the problem is still around, and after 2 hours of googling for the solution i gave up and came up with my own solution for it.
the first command "dump_data_fields" worked as said after restarting the machine ... must be some caching error. But the generation wasnt able because of that pdftk Exception. So the error is on the tk side, not Fill PDF.
What i did is, I wrote my own little c# console app using iTextSharp, which has truly glorious xfdf support.
this file takes the template, xfdf and outputfile names as parameters and creates the flattend pdf. That way I have even more control, like lets say signing the PDF etc.
If anybody has interest on that solution here a short tutorial.
1. Create a new visual studio console app
2. include itextsharp dll
3. write down following code
and compile it.
4. fillpdf.module line 306 or something like that instead of $data = shell_exec ......
write down
5. few lines later after the watchdog lines, replace the rest with
that should do it ... sry I've no idea how to create patches for drupal etc., thats the reason why i do it the ugly way here :)
Hope that helps ... if any further info needed just write, or if you need the already compiled exe itself.
Comment #4
wizonesolutionsThanks zewa. I'll look into the issue some more to determine the next steps. I probably won't go with the C# solution if I can get things going with pdftk, perhaps getting in touch with them if there is a clear and reproducible issue.
But I'm sure your post will be useful for people who are experiencing this issue and don't want to wait. Let's see what the community thinks in addition to whatever I find out.
Comment #5
zewa commentedFor any c# haters out there, that little app up there can be easily written with Java and using iText. I personally will be going with that custom app solution, because as already said I can automaticly sign the PDF on flattening, do some ACLs or anything else.
Anyway thx for your engagement wiz, the pure pdftk solution would help to make Fill PDF work nice out of the box.
Comment #6
wizonesolutionsChanging to -dev version. This should still be addressed...but honestly, it's low priority until more people running Drupal on Windows Server/IIS actually step up and say they need this. Most seem to use Linux servers (which is largely the landscape in the hosting sphere).
Comment #7
wizonesolutionsPostponed. Next person who is interested in this, change back to active.
Comment #8
isotherm commentedWe are using a Windows server. One possible resolution is to use an old version of pdftk, v1.41 before the problematic UTF-8 was added.
http://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/pdftk-1.41.exe.zip
The error itself is a result of this bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12908
The fix would be to add the following line to the Java and recompile pdftk:
private static Class c1 = gnu.gcj.convert.Input_UTF8.class;Unfortunately, mingw hasn't supported gcj since 4.4 and it seems hard to recompile. pdftk also doesn't have recent updates. It would be nice if someone has the tools available to get pdftk recompiled with that line added, and perhaps update iText to a more recent version while we're at it. Otherwise, perhaps a notice could be added to the fillpdf documentation that it is necessary to use pdftk v1.41 when on Windows.
Comment #9
nside commentedThanks isotherm, using pdftk 1.41 worked for me!
Comment #10
wizonesolutionsA recent commit changed using
passthru, which improves Windows compatibility. There unfortunately isn't much more I can do on the Fill PDF end. It's working well on Windows Server as per recent tests.