Closed rmcdouga closed 4 years ago
I've looked at this issue and it is caused by the Adobe APIs. The Adobe APIs are very inconsistent in setting contentType on the Documents they generate (which is itself a problem, albeit a minor one). As a result, when we call an Adobe API that generates a Document object, we generally check to see if the contentType has been set and if not, then we set it if we know what type of Document we are generating.
Here's the thing: Some nitwit in Adobe R&D decided that throwing an exception was an appropriate response to calling getContentType(). This is annoying on so many levels... First of all, they know it's a PDF (the exception message even says so). Couldn't they just return "application/pdf"
? Even if they didn't know for certain that the result is a PDF, couldn't they have just returned null
like so many other Document object implementations within the AEM Forms API? Did they really have throw an exception? Aaarrgghhh!
Ok, so now that I've got that rant out of my system, I will make a change to the AdobeOutputServiceAdapter.generatePDFOutput()
method to always set the contentType to "application/pdf" without checking to see if the contentType is already set. This should be safe, after all the name of the method says that it's going to generate a PDF.
It seems that Document.getContentLength()
is also not supported. It produces a java.lang.UnsupportedOperationException: length() not supported on PDF-based documents!
error too. This is more of a problem as I can't reasonably be expected to guess at the length.
When calling the OutputService's generatePdfOutput() method, some PDFs produce a "java.lang.UnsupportedOperationException: getContentType() not supported on PDF-based documents" error in the log.