Mustang validator always claims PDF is invalid if flavour is PDF/A-3A

[melo0187]

After several attempts with mustang 2.14.2 to validate ZUGFeRD examples that use PDF/A-3A I come to the conclusion, that there is a bug in mustang's PDFValidator.

Take as example from ZUGFeRD/corpus the zugferd_2p1_EXTENDED_Warenrechnung.pdf E-Invoice.

The PDF part is of the PDF/A-3A flavor.
veraPDF says so, too.

verPDF XML report looks like this:

<?xml version="1.0" encoding="utf-8"?>
<report>
  <buildInformation>
    <releaseDetails id="core" version="1.26.1" buildDate="2024-05-16T16:30:00+02:00"></releaseDetails>
    <releaseDetails id="validation-model" version="1.26.1" buildDate="2024-05-16T18:13:00+02:00"></releaseDetails>
    <releaseDetails id="gui" version="1.26.2" buildDate="2024-05-19T13:33:00+02:00"></releaseDetails>
  </buildInformation>
  <jobs>
    <job>
      <item size="699553">
        <name>/home/melo/Documents/Learnings/E-Invoice/training/Beispiele/corpus/ZUGFeRDv2/correct/symtrax/Beispiele/EXTENDED/zugferd_2p1_EXTENDED_Warenrechnung.pdf</name>
      </item>
      <validationReport jobEndStatus="normal" profileName="PDF/A-3A validation profile" statement="PDF file is compliant with Validation Profile requirements." isCompliant="true">
        <details passedRules="154" failedRules="0" passedChecks="63458" failedChecks="0"></details>
      </validationReport>
      <duration start="1730386737725" finish="1730386737969">00:00:00.244</duration>
    </job>
  </jobs>
  <batchSummary totalJobs="1" failedToParse="0" encrypted="0" outOfMemory="0" veraExceptions="0">
    <validationReports compliant="1" nonCompliant="0" failedJobs="0">1</validationReports>
    <featureReports failedJobs="0">0</featureReports>
    <repairReports failedJobs="0">0</repairReports>
    <duration start="1730386737722" finish="1730386737974">00:00:00.252</duration>
  </batchSummary>
</report>

However, ZUGFeRDValidator outputs this:

<validation filename="zugferd_2p1_EXTENDED_Warenrechnung.pdf" datetime="2024-10-31 16:05:32">
  <pdf>ValidationResult [flavour=3a, totalAssertions=63458, assertions=[], isCompliant=true]
    <info>
      <signature>Symtrax</signature>
      <duration unit="ms">950</duration>
    </info>
    <messages>
      <error type="23">Not a PDF/A-3</error> 
    </messages>
    <summary status="invalid"/>
  </pdf>  
// etc. xml part being valid

I believe I found the bug in PDFValidator.

In line 55 it defines an array of PDF_A_3_FLAVOURS, but that array contains exactly the same flavour 3 times, namely PDFAFlavour.PDFA_3_A.

In line 300 to 305 the validation is done exactly the other way round.
The error is added, because the detected PDFAFlavour is found in the array of PDF_A_3_FLAVOURS.

I believe the array should contain PDFAFlavour.PDFA_3_A, PDFAFlavour.PDFA_3_B and PDFAFlavour.PDFA_3_U.
And the validation should add the error only if the output from processorResult.getValidationResult().getPDFAFlavour() does not match any entry of PDF_A_3_FLAVOURS.

I want to try and open a pull request for this.

Thanks in advance for any feedback!

[jstaerk]

can reproduce it thanks for the pr