I’m converting existing pdf documents to the format of pdfA-3U:
pdfDoc.convert(string outputlogfilename, 7, ConvertErrorAction.Delete)
Even when the conversion failed, the method returns true. How can this happen? did I miss somewhere something? The logfile metions errors but they are all ‘Convertable=“True”’.
Nevertheless when the saved resulting document is converted again in the same method it usually succeeds…
can anyone explain this?
Thanks!
The convert() method returns true when the conversion is successful. Also, when ConvertErrorAction.Delete is used, API deletes the errors which occur during the conversion or prevent creation of a valid PDF/A file. In this case, the log file contains description of those errors which were caused during conversion and API deleted them. In other words, the mentioned errors in the log file do not always mean that the converted file has errors. Please feel free to let us know in case you need further information.
Thanks Asad.Ali for the reply!
To be honest I don’t know much about pdf or pdf conversion. What our software needs to do is to send documents to a service. These documents need to be in PDF format A3U and version 1.7. The origin of the documents is in most cases a Word (doc/docx) document and sometimes a PDF of any kind.
So what we do is save PDF from Word (version 1.7) with Aspose.Word and secondly we use Aspose.pdf to check and alter the documents if necessary. First it checks the version and saves the right version (1.7) if needed and second it changes the document to PDF-A3U if necessary.
The problem is (we discovered) that the conversion to A3U gives ‘true’ while the document is not converted to PDF-A3U. This resulted in an error message from the receiving service because the format wasn’t right.
So now we do a second check after the conversion and do the conversion a second time if not successful. The second time it mostly is converted to PDF-A3U (probably because the ‘ConvertErrorAction.Delete’ is used?)
I wonder if there is a more efficient route to do these conversions? May be you have some suggestions on this? Thanks a lot!
Thanks for sharing more details.
Would you please also share a sample PDF document for our reference? This would help us in testing the scenario in our environment and address the issue accordingly.
Ok. This is a bit of a problem because of privacy reasons (we are dealing with notary contracts). I will generate some documents for you in a minute.
Btr02E versie 01-05-2005_1.7.pdf (Aspose.zip (97.9 KB)
51.0 KB)
Btr02E versie 01-05-2005_A3U.pdf (54.1 KB)
the 2 xml files are the output from the troubled pdf file. The first gives the errors but the file is still not an A3U and the second is the file about the actual conversion to A3U.
The pdf with 17 is an output form Aspose Word and the pdf with A3U is the same file after conversion with Aspose pdf. Those are converted form a fake deed without privacy issues.
I hope this can clarify things for you?
The attached PDF documents were converted at our end using Aspose.PDF for Java 21.2. Would you kindly check them and let us know if they are valid PDF/A_3U documents?
Converted3U2ndTime.pdf (54.5 KB)
Converted3UIstTime.pdf (54.5 KB)
Also, please share that which compliance validation tool are you using to check the document PDF/A compliance.
PS: We checked both files using Adobe Preflight and noticed that both files were valid PDF/A_3U.
Hi Asad.ali,
Thank you for your reply. I tested borh documents. When I check them (borh) like this:
_pdfDoc.getVersion() == ‘1.7’
_pdfDoc.getPdfFormat() == 7
they are ‘true’ (version 1,7 and format A3U
When I do:
_pdfDocument.validate(_xmlOutputLog,Packages.com.aspose.pdf.PdfFormat.PDF_A_3U)
they both give ‘false’ (not format A3U)
How can that be explained?
By the way: the PDF that I send you yesterday was not a troubled one: it does convert in one time into the right format. Unfortunately I cannot send you the troubled one because of privacy rules. When I cut out most of the text of the Word document, the conversion goes right, so that is also no use. I did send you the conversionlogs though form the first and second run.
Hi,
I finally succeeded in reproducing the problem. Attached pdf file is from the Aspose.Word.save(). It has PDF version 1,7 and has to be coverted to PDFA3-U. When I try this with:
_pdfDoc.convert(_tempLogResult, _nPdfAFormat, Packages.com.aspose.pdf.ConvertErrorAction.Delete)
this returns ‘true’ but thedocument is still not PDFA. It has to be converted a second time with the same function.
Leveringsakte Leyweg 352V3_copy.pdf (68.9 KB)
We were able to reproduce the similar issue at our end while using Aspose.PDF for Java 21.2. Also, the Document.Validate() method returned ‘false’ in case of first conversion and ‘true’ while validating the document after second time conversion. An issue as PDFJAVA-40269 has been logged in our issue tracking system for further investigation.
We will look into details of the ticket and let you know as soon as it is resolved. Please be patient and give us some time.
We are sorry for the inconvenience.
That is good to hear.
In the meantime I did some more experimenting. Our system has Aspose version 20.6 installed.
When I save the document (the same) in Aspose.words directly to ‘PDF_A_1_A’ (pdf version 1.5 and format A_1A) and then do the Aspose.pdf conversions to ‘v_1_7’ (to make it version 1.7) and then ‘PDF_A_3U’ (to format A-3U) it converts instantly without problems. When I ask then with the ‘validate’ function it returns both on ‘v_1_7’ and ‘PDF_A_3U’ ‘true’, wich is what I expect. May be this informations helps.
Hope to hear from you soon. Thanks so far!
Thanks for sharing more information.
We replicated the issue at our end using 21.2 version of the API. We have also logged recently provided information along with the ticket and will surely consider it during investigation. Will inform you as soon as the ticket is resolved. Please give us some time.
We are sorry for the inconvenience faced.
AsposeTests.zip (934 Bytes)
Hi asad.ali
sorry to bather you again. I’was just trying to find a temporary workaround for our software and I wanted to share this with you so the development team can include it in their proces. The zip file contains a description of the test and the 2 pdf files are examplefiles used…Btr02E versie 01-05-2005.pdf (460.6 KB)
Leveringsakte Leyweg 352V3.pdf (569.2 KB)
Thanks for sharing the workaround that you have implemented. We have recorded it along with the logged ticket and will definitely consider it during ticket investigation.
We are afraid that the earlier logged ticket is not resolved. We will surely investigate and resolve it on a first come first serve basis and let you know once we have additional updates regarding its resolution. Please spare us some time.
We apologize for your inconvenience.