In existing Java code using Itext 2.1.5, I replaced the jar with 5.5.8 and updated the import packages to itextpdf from lowagie. The PDF so generated is now blank, whereas before it had the expected text.
The application's approach is similar to the demo at http://developers.itextpdf.com/question/how-fill-out-pdf-file-programmatically-acroform-technology. One addition I have made, which I have seen in other examples, is to call stamper.partialFormFlattening(name) after setting each field.
I have confirmed during step-through debugging that after invoking form.setField(name, value) on the AcroForms object, I can evaluate the expression form.getField(name) in the debugger and get back the value I set.
The base PDF was created using Scribus 1.4.6, and saved from that as a version 1.4 PDF file.
Is there some step I am missing either in initialization or after setting the values that wasn't necessary in the earlier version?
Related
I try to create a multipage pdf with navigation from one page to the other using Inkscape 1.2.
Therefore I created an object A on Page 1 and an object B on Page 2. Object B has the id myId.
It is possible to add a link to object A with the Id myId in Inkscape by defining href="#myId" in the link-properties. The link in the resulting svg-file work at least if object B sits on page 1 (as normal browsers do not display two pages from the inkscape-svg).
However it does not work in the PDF-File, saved from Inkscape. The Link seems to point to a path {directory}file:\#myId where {directory} is the directory-path of the PDF-file, that also changes when the pdf-file is moved to another path. Maybe this is a bug in Inkscape and file:\ would have to be replaced by the actual current filename. Then the link would make sense again.
I found the project svgLinkify on github. But they say it is depreciated as inkscape enabled this functionality in version 1.2.
Am I missing something?
I am having an issue with PDF's in the latest Typo3 release. If I add PDF to the Image content element, I get this:
The file info looks like this:
Checking the Image Processing Test of Typo3, no errors are returned. PDF/AI also seems to be fine.
I tested several PDF's and AI files as well, they won't show dimensions either.
I have the suspicion that the command 'identify' does not work within Typo3, it still returns perfect results from shell.
Any idea where to look?
multiple reasons possible:
you just need to reimport metadata (scheduler task)
your PDF is coded in an unsual format (there is more then one option in PDF to include the title image)
missing/wrong rights:
maybe another program is executed from commandline than from PHP.
maybe the file can't be accessed correctly from ghostscript started from web
We are currently still using fop v0.2 and want to upgrade to fop v2.1. We are currently testing it with the command line interface and getting a lot errors due to empty cells in our .xls file:
While FOP 0.20.5 allowed you to have empty fo:table-cell elements, the
new code will complain about that (unless relaxed validation is
enabled) because the specification demands at least one block-level
element ((%block;)+, see XSL-FO 1.1, 6.7.10) inside an fo:table-cell
element.
Is there a way to "fix" all of those errors without manually editing file after file?
We found the -r param for "relaxed" mode, but the errors are still not solved / disappearing. Is there a quick workaround?
I'm trying to get the example for creating a PDF/A document with Apache PDFBox up an running (CreatePDFA.java).
For this I copied the example class as is into a project module that includes a maven-dependency on PDFBox in version 2.0.0-RC3. I only changed the method signature and used a fixed font, filename and message instead of args[].
When trying to run the code I get an NPE in Line 107 because it cant't load the color profile (InputStream is null) When I check the included library in the project details I can see the resources folder, but it does not contain the expected file, namely "pdfa/sRGB Color Space Profile.icm".
Unfortunately, google-ing the problem only turned up more references to always the same example implementation, but after a while I acutally found what seems to be the needed file on apache.googlesource.com
I copied the file to our own resource directory and then used this line of code instead:
InputStream colorProfile = CreatePdfA.class.getResourceAsStream("/pdfa/sRGB Color Space Profile.icm");
This finally stopped the NPE - the file is apparently found - but now I get another exception which says:
java.lang.IllegalArgumentException: Invalid ICC Profile Data
Here, I'm stuck. I had hoped that this would work just out of the box, but it seems like I am missing something. Any ideas?
You already answered one part of the problem yourself: put the file into your resource directory.
The second problem may be a bad repository mirror or a transfer problem (binary to ascii). Here's the official repository URL with the ICC profile from the example:
https://svn.apache.org/viewvc/pdfbox/trunk/examples/src/main/resources/org/apache/pdfbox/resources/pdfa/
I am using JSF 2.0, and I have a form with a primefaces autoComplete (multiple) field, and a couple of file inputs. Since I'm using a file input, my h:form tag uses enctype="multipart/form-data" .
However, when I set my form to be multipart, my autocomplete field only returns the last item to my bean (the list is always of size 1). This issue also occurs when just using a regular multiple select element instead of the primefaces autocomplete (the autocomplete makes use of a hidden multiple select element). When I remove enctype="multipart/form-data", this issue goes away, but of course, my bean cannot detect the files I wish to upload.
Has anyone faced this issue and found a solution?
I am using: Liferay 6.1 GA2, Primefaces 3.5, Mojarra 2.1.21
Anghel Leonard describes in article Uploading multiple files using pass through namespace (http://xmlns.jcp.org/jsf/passthrough) to add multiple attribute and overriding FileRenderer#decode method to extract uploaded files.
I had the same problem with JBoss EAP 6.1. Turns out it's a bug in the implementation of the Request.java object which isn't fixed until Wildfly 8.x. Reference here: https://community.jboss.org/thread/223085
To get around this, I used a filter from BalusC's blog: http://balusc.blogspot.com/2007/11/multipartfilter.html
Note that even though JBoss is a 3.0 servlet spec, I couldn't use BalusC's related blog entry for 3.0 because of the bug.
To anyone who is facing this issue, I would just like to share that I eventually turned to using jquery's autocomplete widget instead.