Hi, could you raise a ticket for this? https://issues.apache.org/jira/projects/FOP/
It easier to share zips we can use to replicate the issue, as well as adding any images showing the issue. From: Michael Schubert <[email protected]> Sent: 30 March 2026 00:38 To: [email protected] Subject: RE: Custom XMP Extension Schema dropped when generating PDF/A-2a and PDF/UA-1 compatible PDF You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Hello everybody, I'm trying to use FOP to generate a PDF file which passes both the PDF/A-2a and the PDF/UA-1 verifications and also contains a custom XMP extension schema. I described the problem in one of my previous e-mails and also attached a zip archive with the template and configuration files for reproducing it. I also described two possible solutions, but I can't implement them myself. I have since tried FOP 2.11 and it seems to have the same issue. Can someone please take a look at this issue and hopefully solve it for the next version of xmlgraphics? Thank you very much! Michael Schubert From: Michael Schubert <[email protected]<mailto:[email protected]>> Sent: Friday, November 21, 2025 16:14 To: [email protected]<mailto:[email protected]> Subject: RE: Custom XMP Extension Schema dropped when generating PDF/A-2a and PDF/UA-1 compatible PDF NTT DATA Security Awareness - This is an incoming mail from an EXTERNAL SENDER (fop-dev-return-55718-michael.schubert=nttdata....@xmlgraphics.apache.org<mailto:fop-dev-return-55718-michael.schubert=nttdata....@xmlgraphics.apache.org>). Please verify sender before you open attachments or access links. ________________________________ I have two possible solutions, both of them need some changes to be made in xmlgraphics-commons: First solution - doesn't add the pdfuaid extension schema automatically any more, so that the other extension schemas from the .fo get added properly; the pdfuaid extension schema then needs to be defined in the .fo file: Changed PDFAExtensionAdapter so that the only thing done in the constructor is the call to super. The "pdfuaid" schema then needs to be defined manually in the report.fo. (I also hat to modify a test class in order to be able to build the project; I simply disabled the test with @Ignore.) Second solution - the pdfuaid extension schema gets added automatically, but the other schemas also get added because of the ArrayAddPropertyMerger rule; some minor changes were needed in order to make sure that the xmlLanguage and the parseType also get merged from one array to the other: Changed PDFAExtensionAdapter so that the last few lines in the constructor look like this: QName qname = new QName(namespace, SCHEMAS); XMPProperty prop = new XMPProperty(qname, array); XMPSchemaRegistry.getInstance().getSchema(namespace).getDefaultMergeRuleSet().addRule(qname, new ArrayAddPropertyMerger()); meta.setProperty(prop); Which mean that any extension schemas in the .fo get added to the definitions and are not simply discarded. I hat to define two new methods in XMPArray: public String getXMLLang(int idx) { return (String)this.xmllang.get(idx); } public String getParseType(int idx) { return this.parseTypes.get(idx); } And I also changed the ArrayAddPropertyMerger, so that the language and parseType too get merged from one array to another. The last line now looks like this: array.add(otherArray.getValue(i), otherArray.getXMLLang(i), otherArray.getParseType(i)); (There was also a TODO comment right at this place, which I think meant exactly something like this modification.) Both solutions work if I exchange the xmlgraphics-commons-2.10.jar from the fop/lib folder with the one I generated by building the modified project with "ant". The generated PDF passes both validations, the one for PDF/A-2a and the one for PDF/UA-1. ________________________________ Joao Andre Goncalves Customer Developer t | m 07733161880 [email protected] smartcommunications.com<https://www.smartcommunications.com/> [https://www.smartcommunications.com/wp-content/uploads/025_Trends2026-450x160_v1.jpg]<https://scale.smartcommunications.com/2026-Trends-White-Paper.html?utm_source=outlook&utm_medium=email&utm_campaign=wc-global-2026-white-paper-2026-trends> Explore the new era of AI-powered customer engagement. Get your copy of the 2026 Trends Report now.<https://scale.smartcommunications.com/2026-Trends-White-Paper.html?utm_source=outlook&utm_medium=email&utm_campaign=wc-global-2026-white-paper-2026-trends> Smart Communications is a trading name of SmartComms SC Limited which is registered in England under No. 4303041 whose registered office is at Suite 23, LCLB, 95 Mortimer Street, London, W1W 7GB. Please consider the environment before printing. The contents of this e-mail are intended for the named addressee only. It contains confidential information. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Smart Communications will process your data as described in the Smart Communications' External Privacy Policy.<https://www.smartcommunications.com/external-privacy-policy/> Follow us on LinkedIn,<https://www.linkedin.com/company/15166060/admin/> YouTube,<https://www.youtube.com/@Smart_Communications/> and X.<https://x.com/ccminnovators?lang=en>
