[
https://issues.apache.org/jira/browse/FOP-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18069779#comment-18069779
]
Michael Schubert commented on FOP-3304:
---------------------------------------
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 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
> Priority: Minor
> Attachments: FOP_Test.zip, 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)
