Aspose pdf/a rendition results in pdf rendition(ECDCTS-10534)

Aspose.PDF Product Family
1

Hi Team,

When attempting to convert a PDF to PDF/A , the rendition results a PDF instead of PDF/A.

I have used following code:
Document doc = new Document(“C:\Docs\10534\PETICION_CONCEJAL_21_input.pdf”);
doc.convert(“C:\Docs\10534\resultant.txt”, com.aspose.pdf.PdfFormat.PDF_A_1B, com.aspose.pdf.ConvertErrorAction.Delete);
doc.save(“C:\Docs\10534\PETICION_CONCEJAL_21_OutputPdfa.pdf”);

I have attached the input and output file.
PETICION_CONCEJAL_21.zip (2.4 MB)

Thanks,
Bhupali

3

@rnara
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.

Issue ID(s): PDFJAVA-43592

You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.

4

Is it considered as a bug? If so, when can we expect the fix to be addressed?
Also, could we please be informed of the root cause behind the unexpected rendering in this particular sample?
Thanks,
Bhupali

5

The attached archive PETICION_CONCEJAL_21_OutputPdfa.pdf has no PDF_A_1B standard problems. If we read the log from the resultant.txt file, we can see that all the problems found during the conversion process were fixed because it has the following mark: Convertable=“True”
Also, the attached output file has been found to be compatible with PDF_A_1B through Adobe Acrobat Preflight (see attached image). So there is no bug in here.

Notice also that the reason for the issue on other computers can be license permission on the GillSans-Bold font that blocks its embedding, and that will be notified in the log with Convertable=“False” or because we can’t find that font in the system because it is not standard one. If we add into the system GillSans-Bold font without license permission for embedding - the conversion will be done without a problem.
Otherwise, we should substitute the GillSans-Bold font with another font with no license restrictions.
For example:

//enable substitution by the font name
    FontRepository.getSubstitutions().add(new SimpleFontSubstitution("GillSans-Bold", "Arial"));
...customer's code...

preflight.png (60.2 KB)

6

We are not looking for any code change. Could you please suggest a better solution avoiding code change.
image.png (18.5 KB)
I have already added GillSans Regular font into the system (installed it from internet attached the image above).
Thanks!

7

Sorry for the misunderstanding, but we don’t demand any changes in your code.

The resultant file is PDF/A in the archive you provided. The code works fine, and the result is a PDF/A compliant file.

Our additional recommendations are:

  • if the font is not present in the system or has license restrictions, you need to install this font or make a substitution.
  • you can check the result of the operation as a boolean value. True means “Everything is Ok”.
  • log file contains info about conversion operation. We found some errors, but clause Convertable="True" means “Converted (solved).”
8

Could you please inform me of the reason why, while I can successfully render documents to PDF/A using the same input file, the customer is encountering difficulties rendering from DOCX to PDF/A? Instead, it seems to generate a regular PDF. Could this be due to differences in fonts that Aspose does not support, leading to rendering issues in the customer’s environment? I have attached the input file, the PDF/A file (from my dev environment), and the PDF file (from the customer’s environment) for your reference.

Thanks,
Bhupali
PETICION_CONCEJAL.zip (1.2 MB)

9

Additional information is needed to conduct the investigation:

  • PDF/A conversion log files from customer PC
  • info about customer platform (OS, JDK version, version of Aspose.PDF library etc)

@rnara, could you please provide us with this info?

10

There is no error in the log file.
OS → Windows 2019
JDK version → 11.0.15.10-hotspot
Version of Aspose.PDF library → 22.2

Thanks,
Bhupali

11

@andriy.andrukhovski I have provided the requested info. Please let us know the root-cause of rendition results in pdf instead pdf/a. Thanks!

12

We will try to reproduce the issue with these system requirements, and then I will inform you of the results.

13

@andriy.andrukhovski I’ve shared both the customer and our development output files (please refer the attachment in above comments) and have observed differences in fonts. Could you kindly confirm whether the root cause of this issue pertains to the fonts?

14

@rnara
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.

Issue ID(s): PDFJAVA-43788

You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.

15

Hi please let us know why it is not working in customer environment?

16

@rnara, I’m waiting for the Dev Team’s response. I will write to you when I have information.

17

Here is answer from Dev Team:

The problem is not in the Aspose code, but in the client’s environment, because required fonts that are needed for conversion are absent (“GillSans-Bold”).
According to the PDF/A standard, fonts used in the document must be embedded when converting to PDFA, but they cannot be embedded if they are absent in the system and Aspose cannot find them.
To find out if the document is converted correctly or not, you need to get the value returned by the convert(…) method - it must be TRUE.
In addition, the list of fonts that have problems that can’t be solved are described in the log file in the category < Fonts/> with attribute Convertable=“False”, that is created during conversion.
We recommend adding all necessary fonts to the target system if you can’t modify code and use features of Aspose to replace problematic fonts that were not found in the system.