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?
Related
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
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?
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've encountered a weird issue with Phantomjs when converting an html file to pdf. My html, resulting pdf, and rasterize.js files are below:
http://401web.com/_pub/2TRTI8E.html
http://401web.com/_pub/2TRTI8E.pdf
http://401web.com/_pub/rasterize.js
You will notice that in the PDF file, at page 6, the content gets cut off and then on page 7, the content is repeated and is then correct all the way to the end of the document.
The html file contains a series of tags with their src attributes set as data:image/png;base64...
The application call to the phantom library is as follows:
phantomJS.Run("C:\path\to\directory\rasterize.js"),
new[] { webpath, outFilePdf, "A4", "1", "portrait"}, null, null);
Note that sometimes the rendered pdf file will exhibit the break/repeat behavior in different locations within the document eg: page 7 instead of 6) but the same issue always occurs.
Also, I am using phantomjs throughout my application (with the same rasterize.js script) with no other issues. This only happens on this export and only if there are a number of images.
My theory is that there is something going on with the image.onload event, specifically with base64 data but I have no idea how to troubleshoot this.
This is all within a .Net MVC application. I am using the PhantomJS nuget package found here: https://www.nuget.org/packages/PhantomJS/
Help is greatly appreciated.
Update: when running phantomjs locally via command line I was receiving the error below:
[CRITICAL] QNetworkReplyImpl: backend error: caching was enabled after some bytes had been written
libpng error: Read Error
I solved this (though I have no idea how/why) by replacing the cdn references in the html file to font-awesome.css and weather-icons.css files with locally hosted versions. After that, no more error and no more duplicate content.
When I use my custom build of dojo, dojo.currency.format doesn't use the correct currency symbol.
This is the statement I use:
dojo.currency.format(1234.567, {currency: "USD"});
This is the result when I use the standard dojo release:
"$1,234.57"
This is the result when I use my custom build of dojo:
"ยค1,234.57"
How can I get my custom dojo build to produce the correct results?
I encountered this issue when first trying to use the dojo build. It has to do with the character encoding of the files. Check out the character encoding of an unzipped release (non source). Compare that to the character encoding of files in unbuilt source, and the encoding of files are a custom build. To see if this is an issue, (in chrome) you can force the browser to render the contents in a given encoding. You can try this to see if it is actually the issue you are having.
The easy solution to this (for me at least) was to set the charset on the dojo script tags
<script type="text/javascript" src="/path/to/dojo" charset="UTF-8"></script>
Dojo has a couple of pages on encoding that are worth taking a look at.
If you are using shrinksafe in the build, you may also need to specify the encoding there:
java -jar -Dfile.encoding=UTF8 shrinksafe.jar
Does your build have access to dojo/cldr/nls directory for the localization files of your locale? Check in Firebug whether it attempts, but fails to load currency.js from mentioned directory.