[Spire.PDF for Android] 9.7.1 breaks backwards compatability

[RicoScheller]

Hello

I was very pleased to see that version 9.5.1 of Spire.PDF for Android implemented SPIREPDF-5639 so that adding new custom properties will no longer cause loss of existing custom properties.

However, version 9.7.1 adds the new feature which "Adds a new method pdf.getDocumentInformation() to get the Metadata data, and deprecated XmpMetadata."

This makes our current project no longer usable (again).
Basically, our project uses PDF/A that already contain XMP metadata (written by another application which uses Spire.PDF for Java).
It reads this metadata and also adds new custom properties.

I created a test setup to figure out what is wrong.
This tests the following:
1. Read metadata from a PDF with XMP metadata. Then write a new custom property.
2. Read metadata from a PDF/A with XMP metadata. Then write a new custom property.
3. Read metadata from a PDF with a custom property. Then write a new custom property.
4. Read metadata from a PDF/A with a custom property. Then write a new custom property.

Test output:

Code: Select all

------------------------------metadataTest_copy.pdf ------------------------------
Read: Metadata1=true; Metadata2:=null
Setting metadata2=Some text
Read: Metadata1=true; Metadata2:=Some text
------------------------------metadataTestAndroid_copy.pdf ------------------------------
Read: Metadata1=true; Metadata2:=null
Setting metadata2=Some text
Read: Metadata1=true; Metadata2:=Some text
------------------------------metadataTestPdfA_copy.pdf ------------------------------
Read: Metadata1=true; Metadata2:=null
Setting metadata2=Some text
Read: Metadata1=true; Metadata2:=null
------------------------------metadataTestAndroidPdfA_copy.pdf ------------------------------
Read: Metadata1=true; Metadata2:=null
Setting metadata2=Some text
Read: Metadata1=true; Metadata2:=Some text

Case number 2 (metadataTestPdfA_copy.pdf) does not work, the new custom property is either not written to the PDF/A or can not be read afterwards.
This is not good for us because we supply these PDF/A with XMP metadata to our customers so that they can use our application to digitally edit them. They have already been distributed, so need to be usable by our app. Thus, if we are no longer able to use PDF/A with already filled out XMP metadata, we can no longer update Spire.PDF for Android and thus we will no longer purchase licenses and potentially migrate to another PDF library for Android.

To reproduce this, you have to do the following:
1. Load the project from the attachment.
2. Copy the two PDFs from the ZIP onto your Android device (or emulator) into the directory "\Android\data\com.example.spiretest\files".
3. Run the application.
4. Look at the console output.

I would really like to have "Spire.PDF for Android via Java" be reliable. Unfortunately, there have been quite a few issues, especially regarding XMP metadata / custom properties.
I am at a point where I would recommend "Spire.PDF for .Net" to anyone, but I would currently advice against using "Spire.PDF for Android". I hope you can do something to change that. Because having one reliable library for .Net, Java and Android is quite a convincing feature of your product suite. But if some of those platforms aren't given enough love...

[Triste.Dai]

Hi,

Thank you for your feedback regarding our product.

Upon analysis, our developers found that the PDF/A document named "metadataTestPdfA.pdf" in your project is incorrect, as its custom property is empty. However, the metadata content stream contains a key-value pair of "IsIBN" with the value "true." This discrepancy is causing the retrieval of the custom property when using the "getCustomProperty" function.

test.png

It is possible that your source document was generated using our product's old interface or another tool, which resulted in this problem. If you utilize PdfStandardConverter to generate PDF/A documents, the metadata will not contain any custom property key-value pairs, thus avoiding the retrieval of such properties.

Please note that converting a PDF document to PDF/A does not eliminate metadata but does prevent the setting of custom properties(You can test it in Adobe Acrobat reader). We recommend using the new interface "PdfStandardConverter", when converting PDF/A documents.

If you have any further questions or require assistance, please don't hesitate to reach out to us. We are here to help.

Best regards,
Triste
E-iceblue support team

[RicoScheller]

It is possible that your source document was generated using our product's old interface or another tool, which resulted in this problem.

Yes, the PDF was created with Spire.PDF for Java V3.8.2 by using

Code: Select all

pdfDocument.getXmpMetaData().setCustomProperty("IsIBN", Boolean.toString(isIBNProtocol));

.

That is exactly the problem. These PDFs are already generated and need to be working.
You cannot just break backwards compatability and tell us that "old" PDFs can no longer be correctly read.

If one of your versions used to produce a "discrepancy" and we delivered PDFs with this discrepancy to our customers, you need to give us a way of reading the "old" metadata so that it doesn't cripple our ability to use these already existing PDFs.

We need to be able to still read this "IsIbn" flag, no matter with which Spire.PDF version it was generated.

Please note that converting a PDF document to PDF/A does not eliminate metadata but does prevent the setting of custom properties

I already had this discussion with Nina Tang. PDF/A allows custom metadata, you just have to apply them differently, via extension schemas. See the attachment wich is an excerpt from our mail communication which started with a mail titled "Bug in Spire.PDF for Android: Metadata gets deleted" which I sent on 23th December 2022.
Basically, she kept saying it's not possible. Then I told her how it would be possible. She showed me how I can achive this with Spire.PDF for .Net but we then saw that even this method does not work for PDF/A and she created a ticket for this bug.

So, since custom metadata for a PDF/A is not even available for Spire.PDF for .Net, I would assume that it will take years until this is usable in Android.
Can you please give me a rough timeline when you plan to add this "feature" to Spire.PDF for .Net and Android?
Because if I don't have a clear idea how long it will take until I can reliably store custom metadata in a PDF/A then I really need to reevaluate if Spire.PDF is still the correct product for me.
You seem to struggle quite a bit to get metadata working correctly...

[Nina.Tang]

Dear Rico,

I apologize for the inconvenience caused. I took an extended leave, and my colleague Triste wasn't familiar with your previous question, which led to your misunderstanding.

Our previous communication resulted in using doc.Metadata to add extension schemas, but unfortunately, the added extension schemas were lost after converting to PDFA using PdfStandardsConvert. This issue is being tracked under the number SPIREPDF-5742 in our internal system. I just got feedback from our dev team that they have made some adjustments on it, but it has not been resolved completely. I have given your issue a high priority and urged our dev team again. Please spare us a little more time. You will be notified as soon as it is resolved.

Sincerely,
Nina
E-iceblue support team

[RicoScheller]

Hello again,

We are now really stuck in a bad place:

- We would like to use the "new" feature of not encrypting metadata when protecting a PDF as introduced with V9.10.1 here: post52925.html
- We currently encounter a bug with some fonts when writing into an existing form field (will provide sample project once we have it)

But since we can't use new versions of Spire.PDF for Android because it breaks our existing metadata, we can't profit from new features and not even make use of (future) bugfix releases. This is really frustrating.

Could I maybe know, when this problem is supposed to be resolved?

[Nina.Tang]

Hi,

Due to the ongoing Chinese New Year holiday period, our company is currently on vacation from 2024/02/09 to 2024/02/17. Once our dev team returns to work, I will promptly inform them about the urgency of your question. If I get any feedback regarding the time for fixing your issue, I will notify you immediately. Apologize for the inconvenience caused.

Sincerely,
Nina
E-iceblue support team