[jira] [Comment Edited] (FOP-3304) Custom XMP Extension Schema dropped when generating PDF/A-2a and PDF/UA-1 compatible PDF

    [ https://issues.apache.org/jira/browse/FOP-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18069779#comment-18069779 ] 

Michael Schubert edited comment on FOP-3304 at 5/12/26 9:19 AM:
----------------------------------------------------------------

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:*

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 had 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:
{code:java}
QName qname = new QName(namespace, SCHEMAS);
XMPProperty prop = new XMPProperty(qname, array);
XMPSchemaRegistry.getInstance().getSchema(namespace).getDefaultMergeRuleSet().addRule(qname, new ArrayAddPropertyMerger());
meta.setProperty(prop); {code}
Which means that any extension schemas in the .fo get added to the definitions and are not simply discarded.

I had to define two new methods in {{{}XMPArray{}}}:
{code:java}
public String getXMLLang(int idx) {
    return (String)this.xmllang.get(idx);
}
public String getParseType(int idx) {
    return this.parseTypes.get(idx);
} {code}
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:
{code:java}
array.add(otherArray.getValue(i), otherArray.getXMLLang(i), otherArray.getParseType(i)); {code}
(There was also a TODO comment right at this place in the source, 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.


was (Author: JIRAUSER312904):
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:*

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 had 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:
{code:java}
QName qname = new QName(namespace, SCHEMAS);
XMPProperty prop = new XMPProperty(qname, array);
XMPSchemaRegistry.getInstance().getSchema(namespace).getDefaultMergeRuleSet().addRule(qname, new ArrayAddPropertyMerger());
meta.setProperty(prop); {code}
Which means 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{}}}:
{code:java}
public String getXMLLang(int idx) {
    return (String)this.xmllang.get(idx);
}
public String getParseType(int idx) {
    return this.parseTypes.get(idx);
} {code}
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:
{code:java}
array.add(otherArray.getValue(i), otherArray.getXMLLang(i), otherArray.getParseType(i)); {code}
(There was also a TODO comment right at this place in the source, 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.

> Custom XMP Extension Schema dropped when generating PDF/A-2a and PDF/UA-1 compatible PDF
> ----------------------------------------------------------------------------------------
>
>                 Key: FOP-3304
>                 URL: https://issues.apache.org/jira/browse/FOP-3304
>             Project: FOP
>          Issue Type: Bug
>    Affects Versions: 2.10, 2.11
>            Reporter: Michael Schubert
>            Assignee: Joao Goncalves
>            Priority: Minor
>         Attachments: FOP_Test.zip, report_test.fo, report_test_2.fo, veraPDFValidationReport.xml
>
>
> I am using fop 2.10 to generate a PDF-File which needs to be compatible with both PDF/A-2a and PDF/UA-1.
> The resulting file passes the PDF/UA-1 check, but fails the PDF/A-2a verification because of rule 6.6.2.3.1:
>  * Test number1: "XMP property is either not predefined, or is not defined in any XMP extension schema";
>  * Test number 2: "XMP property does not correspond to type null".
> The offending property is {{{}myschema:CustomProp{}}}, which is correctly defined in the fo-file, but somehow seems to be dropped when the document is created with both PDF/A-2a and PDF/UA-1 profiles activated. Actually, my custom XMP extension schema definition for schema "{{{}myschema{}}}" seems to be replaced by the definition of the schema "{{{}pdfuaid{}}}", which is automatically generated into the PDF.
> I reproduced the problem using the files in the attached zip-archive.
> Using the same {{report_test.fo}} as input, I started {{fop}} three times:
>  # with {{-c cfg_a_2a.xml}} (configuration file which only activates the PDF/A-2a mode)
> *Result:* {{test_1_a_2a.pdf}} - {color:#00875a}passes the PDF/A-2a validation{color}
>  # with {{-c cfg_ua_1.xml}} (configuration file which only activates the PDF/UA-1 mode)
> *Result:* {{test_1_ua_1.pdf}} - {color:#00875a}passes the PDF/UA-1 validation{color}
>  # with {{-c cfg.xml}} (configuration file which activates both the PDF/A-2a and the PDF/UA-1 modes)
> *Result:* {{test_1.pdf}} - {color:#FF0000}passes the PDF/UA-1 validation, but not the PDF/A-2a validation{color}
> see the attached veraPDFValidationReport.xml



--
This message was sent by Atlassian Jira
(v8.20.10#820010)