[veraPDF-users] veraPDF 1.14 onwards accepts file as PDF/A-1b compliant despite violation of clause 6.1.12 (floating-point range of ±32767.0)?
Hello,
I have a PDF document that, depending on veraPDF version, either passes or fails conformance checks for PDF/A-1b. The file is publicly available being a doctoral dissertation: http://uu.diva-portal.org/smash/record.jsf?pid=diva2%3A280958&dswid=836 http://uu.diva-portal.org/smash/get/diva2:280958/FULLTEXT02.pdf
With veraPDF 1.14.8 and later, this file passes the conformance check for PDF/A-1b, but it fails with veraPDF 1.12.1 and earlier with the following error message:
<validationReport profileName="PDF/A-1B validation profile" statement="PDF file is not compliant with Validation Profile requirements." isCompliant="false"> <details passedRules="102" failedRules="1" passedChecks="65345" failedChecks="1"> <rule specification="ISO 19005-1:2005" clause="6.1.12" testNumber="2" status="failed" passedChecks="0" failedChecks="1"> <description>Absolute real value must be less than or equal to 32767.0</description> <object>CosReal</object> <test>(realValue >= -32767.0) && (realValue <= 32767.0)</test> <check status="failed"> <context>root/document[0]/OpenAction[0](156 0 obj PDGoToAction)/D[0]</context> </check> </rule> </details> </validationReport>
Release details for core, validation model and gui are all 1.12.1
In contrast, for example, veraPDF 1.18.6 prints:
<report> <buildInformation> <releaseDetails id="core" version="1.18.11" buildDate="2021-04-19T10:21:00+02:00"></releaseDetails> <releaseDetails id="validation-model" version="1.18.8" buildDate="2021-04-19T10:35:00+02:00"></releaseDetails> <releaseDetails id="gui" version="1.18.6" buildDate="2021-04-27T08:53:00+02:00"></releaseDetails> </buildInformation> <jobs> <job> <item size="4458678"> <name>/tmp/pdf/oaiDiVAorguu-111393.pdf</name> </item> <validationReport profileName="PDF/A-1B validation profile" statement="PDF file is compliant with Validation Profile requirements." isCompliant="true"> <details passedRules="101" failedRules="0" passedChecks="65346" failedChecks="0"></details> </validationReport> <duration start="1649428145077" finish="1649428146991">00:00:01.914</duration> </job> </jobs> <batchSummary totalJobs="1" failedToParse="0" encrypted="0"> <validationReports compliant="1" nonCompliant="0" failedJobs="0">1</validationReports> <featureReports failedJobs="0">0</featureReports> <repairReports failedJobs="0">0</repairReports> <duration start="1649428144942" finish="1649428147026">00:00:02.084</duration> </batchSummary> </report>
I checked veraPDF-validation-profiles/PDF_A/PDFA-1B.xml and its Git history, but I could not identify any changes to the rules checking floating-point numbers for its range of ±32767 from Table C.1 of Adobe's PDF 1.4 specification.
I used qpdf to extract more information on object 156 where I get the following output:
$ qpdf --json --json-key=objects FULLTEXT02.pdf | grep -A 5 '"156 0 R": {' "156 0 R": { "/D": [ "158 0 R", "/FitH", -32768 ],
So, to my understanding, the numeric value of -32768 is outside of the allowed range and thus veraPDF should reject this PDF file as *not* conforming to PDF/A-1b.
Is there a bug in veraPDF or do I miss something?
Thank you!
Bye, Thomas
Hi Thomas,
The validation question you describe was addressed in the PDF Association publication: https://www.pdfa.org/wp-content/uploads/2017/07/TechNote0010.pdf, Implementation limits for integers in PDF/A-1 (A001). At some point, veraPDF has adjusted its validation of implementation limits for integers (PDF/A-1) based on this publication.
In short, in your case the numeric value -32768 uses a syntax of an integer and thus is validated against the implementation limits of integers, which are from 2,147,483,647 to −2,147,483,648.
I note that this issue is specific for PDF/A-1 and does not occur for PDF/A-2 and higher, as the implementation limits were relaxed for PDF/A-2 and 3 and even removed completely from PDF/A-4.
Best regards, Boris
-----Original Message----- From: Users users-bounces@lists.verapdf.org On Behalf Of Thomas Fischer Sent: Monday, April 11, 2022 12:06 PM To: users@lists.verapdf.org Subject: [veraPDF-users] veraPDF 1.14 onwards accepts file as PDF/A-1b compliant despite violation of clause 6.1.12 (floating-point range of ±32767.0)?
Hello,
I have a PDF document that, depending on veraPDF version, either passes or fails conformance checks for PDF/A-1b. The file is publicly available being a doctoral dissertation: http://uu.diva-portal.org/smash/record.jsf?pid=diva2%3A280958&dswid=836 http://uu.diva-portal.org/smash/get/diva2:280958/FULLTEXT02.pdf
With veraPDF 1.14.8 and later, this file passes the conformance check for PDF/A-1b, but it fails with veraPDF 1.12.1 and earlier with the following error message:
<validationReport profileName="PDF/A-1B validation profile" statement="PDF file is not compliant with Validation Profile requirements." isCompliant="false"> <details passedRules="102" failedRules="1" passedChecks="65345" failedChecks="1"> <rule specification="ISO 19005-1:2005" clause="6.1.12" testNumber="2" status="failed" passedChecks="0" failedChecks="1"> <description>Absolute real value must be less than or equal to 32767.0</description> <object>CosReal</object> <test>(realValue >= -32767.0) && (realValue <= 32767.0)</test> <check status="failed"> <context>root/document[0]/OpenAction[0](156 0 obj PDGoToAction)/D[0]</context> </check> </rule> </details> </validationReport>
Release details for core, validation model and gui are all 1.12.1
In contrast, for example, veraPDF 1.18.6 prints:
<report> <buildInformation> <releaseDetails id="core" version="1.18.11" buildDate="2021-04-19T10:21:00+02:00"></releaseDetails> <releaseDetails id="validation-model" version="1.18.8" buildDate="2021-04-19T10:35:00+02:00"></releaseDetails> <releaseDetails id="gui" version="1.18.6" buildDate="2021-04-27T08:53:00+02:00"></releaseDetails> </buildInformation> <jobs> <job> <item size="4458678"> <name>/tmp/pdf/oaiDiVAorguu-111393.pdf</name> </item> <validationReport profileName="PDF/A-1B validation profile" statement="PDF file is compliant with Validation Profile requirements." isCompliant="true"> <details passedRules="101" failedRules="0" passedChecks="65346" failedChecks="0"></details> </validationReport> <duration start="1649428145077" finish="1649428146991">00:00:01.914</duration> </job> </jobs> <batchSummary totalJobs="1" failedToParse="0" encrypted="0"> <validationReports compliant="1" nonCompliant="0" failedJobs="0">1</validationReports> <featureReports failedJobs="0">0</featureReports> <repairReports failedJobs="0">0</repairReports> <duration start="1649428144942" finish="1649428147026">00:00:02.084</duration> </batchSummary> </report>
I checked veraPDF-validation-profiles/PDF_A/PDFA-1B.xml and its Git history, but I could not identify any changes to the rules checking floating-point numbers for its range of ±32767 from Table C.1 of Adobe's PDF 1.4 specification.
I used qpdf to extract more information on object 156 where I get the following output:
$ qpdf --json --json-key=objects FULLTEXT02.pdf | grep -A 5 '"156 0 R": {' "156 0 R": { "/D": [ "158 0 R", "/FitH", -32768 ],
So, to my understanding, the numeric value of -32768 is outside of the allowed range and thus veraPDF should reject this PDF file as *not* conforming to PDF/A-1b.
Is there a bug in veraPDF or do I miss something?
Thank you!
Bye, Thomas
Hello Boris,
The validation question you describe was addressed in the PDF Association publication: https://www.pdfa.org/wp-content/uploads/2017/07/TechNote0010.pdf, Implementation limits for integers in PDF/A-1 (A001). At some point, veraPDF has adjusted its validation of implementation limits for integers (PDF/A-1) based on this publication.
In short, in your case the numeric value -32768 uses a syntax of an integer and thus is validated against the implementation limits of integers, which are from 2,147,483,647 to −2,147,483,648.
I note that this issue is specific for PDF/A-1 and does not occur for PDF/A-2 and higher, as the implementation limits were relaxed for PDF/A-2 and 3 and even removed completely from PDF/A-4.
Thank you for the clarification. Very helpful!
Bye, Thomas
participants (2)
-
Boris Doubrov -
Thomas Fischer