Only inform about unknown PDF Name prefixes #807
Conversation
prettybits
changed the title
There was a problem hiding this comment.
This is the same as #778 (I mean commit "correct message for PDF header version parsing error")
|
Hi @prettybits I used error because in the PDF specification it is stated in section 7.12 Extensions Dictionary: "The keys in the extensions But thanks for updating the registry! Sam |
|
Hi @samalloing, thanks for reviewing! I didn't see the preexisting PR for the PDF-HUL155 issue, I will rebase the branch without the commit. I did in the meantime also find the specification document, so I can follow the official text as well. The rules about developer extensions key names do seem somewhat unclear to me I have to say. Chapter E.1 "General" says
and Chapter I.3 "Feature Compatibility" mentions
which makes it seem like this is more about "public" extensions, although it also sounds like per E.2 private extensions should then still use a Shall I rebase the PR with just the registry update commit intact? |
|
I just noticed as well that 7.12.4 uses "GLGR" as an extension key in its examples, which is not even in the registered name list, don't know what to make of that. I also wonder if @tballison may have thoughts about this? |
|
OK, I've been working my way through the earlier PDF module PRs but these are on my radar now. I'm going to raise one or two of these questions with our resident PDF expert and will add any answers here. I'd like to get this merged and working for the upcoming 1.28 release. |
prettybits
force-pushed
the
pdf-name-prefix-updates
branch
from
96b35c2
to
3c00d95
Compare
|
Thanks, @carlwilson! In the meantime I have rebased my branch, removed the now redundant fix and re-added the "ADBE" prefix which I noticed I mistakenly left out previously. |
I defer to digipres on use cases for digipres and actual pdf experts on the spec. Personal opinion only: I'd want to be alerted to public extensions, private extensions and non-standard extensions. For some use cases, I imagine that you'd not want to allow any extensions because of the risk of data leakage and or vendor-specific behavior that can't be replicated. |
|
I've read the specification document and I'm in agreement with your reading @prettybits in that unregistered prefixes should begin
I suspect this is one of those, which raises the possibility of registered names that aren't on the list. I'm starting to favour a warning for unknown prefixes and I've asked someone who knows more about PDF than me to give some advice. I also noticed we're one registration light for "DLLB" added on Dec 12 2022. By coincidence, it's the person I've asked to help. |
Codecov ReportBase: 29.18% // Head: 46.22% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## integration #807 +/- ##
==================================================
+ Coverage 29.18% 46.22% +17.04%
- Complexity 597 1056 +459
==================================================
Files 57 57
Lines 9057 9057
Branches 1607 1607
==================================================
+ Hits 2643 4187 +1544
+ Misses 6033 4330 -1703
- Partials 381 540 +159
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
|
Good hunting, @carlwilson, Global Graphics also looks like the right candidate to me for the GLGR prefix. In the names list there is one entry that has a listed creation date before 2008: Plib for PDFlib GmbH, and I'm also not quite sure how to parse that note by Adobe. It sounds like (almost all) those names are known to Adobe only and cannot be publically listed in the repository? It's quite certain to not be a complete list in any case it would seem. I also added the DLLB prefix now, that was commited a few hours after I opened this PR. ;) As to validity, I think that even if the prefix names list were complete, unless we knew how to validate what the extension actually means to extend we wouldn't really win anything by being strict. I agree with @tballison that being notified about any extension no matter how official can be very valuable, but that's not a question of validity but more of policy. But that is personal opinion territory, let's see what Peter says. :) |
|
I've now had confirmation that not all of the names on the pre-2008 list are public, so there are legitimate prefixes that aren't on the list. A better explanation of the implications of the message on the Wiki and an informational message is the way to go here. I will merge this and add some better background to the Wiki. Thanks for the PR @prettybits |
Also related to #668, unknown prefixes are currently treated as validation errors, but I'm not sure why. The example files in the linked issue report the following error:
ErrorMessage: Unknown Developer Prefix:: ESIC, but I haven't been able to find anything specific about the prefix. It is not currently listed in the official prefix name registry (which I have also updated and sorted alphabetically on this occasion).I don't currently have access to the formal specification (the link in the comments is being redirected by now), so I'm not sure what specifically it says about prefixes and how to treat them re validity. Can you help me out with some quotes, @carlwilson?
While searching around the codebase for the validation message I also found that it is currently wrongly used for version parsing errors in the PDF header, which I changed to the intended one. If you prefer I can split these commits up to separate PRs, I just combined them for now since they seemed thematically related enough.