Skip to content

Fix developer extension version reporting#1024

Open
prettybits wants to merge 3 commits intoopenpreserve:integrationfrom
prettybits:extensions-fixes
Open

Fix developer extension version reporting#1024
prettybits wants to merge 3 commits intoopenpreserve:integrationfrom
prettybits:extensions-fixes

Conversation

@prettybits
Copy link
Contributor

Fixes #890

This fixes an exception that's surfaced when using the JSON handler with PDFs that list extensions in the document catalog. In this case, the parsed Double value of the extension's BaseVersion key was wrongly used for a String property. I also noticed that the version strings were parsed outside the try-block here, so the exception handling to report PDF-HUL-88 for extension's base versions didn't work as intended, this is also fixed.

While here, I noticed that extension base versions are checked whether they are the same as the file's PDF version to report an info message for PDF-HUL-87, equivalently to the reporting for mismatching document info version compared to the file header. Since Extension's BaseVersion "reflect the version of the standard that has been extended and not the version of this particular file" (see chapter 7.12.4 of the PDF specification) they need to be handled a bit differently. I aligned the check to not report anything for base versions lower than the PDF version as this is expected and only look for the case where the version is higher. Reporting PDF-HUL-87 for this case doesn't really fit then and would need a new error ID, I wasn't sure how to best go about introducing one. What do you think, @carlwilson?

@carlwilson
Copy link
Member

Thanks for this @prettybits. My thoughts are:
PDF-HUL-87 = File header gives version as {0}, but catalog dictionary gives version as {1} could possibly be worded better. Perhaps the Wiki is the place to improve the explanation. The case you're talking about is definitely a different case. I agree that a new error would be the best way of handling this. The steps are pretty straightforward:

  • read the specs and decide the nature of the test
  • implement test for condition
  • decide on the wording of the message
  • add message to properties files in PDF modules
  • add message to MessageConstants loader in PDF module
  • add message details to JHOVE wiki

That sounds like quite a bit once it's all done. Do you want to move this forward or should I look at then next tasks?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Java Error on Jhove CLI by json formatter class java.lang.Double cannot be cast to class java.lang.String

2 participants