Add experimental PDF/A compliance mode #3269
Conversation
lib/res/sRGB2014.icc
Outdated
There was a problem hiding this comment.
Can you say where you got this file?
What licence it is?
Is this the same file as https://sources.debian.org/src/tcpdf/6.7.4%2Bdfsg-1/include/sRGB.icc/?
There was a problem hiding this comment.
There was a problem hiding this comment.
Thank you!
Let's let @bsweeney let us know if adding a licence file should be done like in https://github.com/dompdf/php-font-lib/tree/master/tests/resources/fonts/ahem
There was a problem hiding this comment.
I think this makes sense. Naming ... something like sRGB2014.icc.LICENSE (ugly)? Or should we put the ICC profile in a sub-directory with the standard-named LICENSE file?
The copyright owner and terms of use of an ICC profile are normally identified in the Creator field in the profile header and in the Copyright tag. Where ICC is the copyright owner, the following license terms apply:
"This profile is made available by the International Color Consortium, and may be copied, distributed, embedded, made, used, and sold without restriction. Altered versions of this profile shall have the original identification and copyright information removed and shall not be misrepresented as the original profile."
(reference https://www.color.org/profiles2.xalter#license)
Co-authored-by: William Desportes <williamdes@wdes.fr>
|
@Starfox64 do you think it would solve #3269 ? |
|
That's the wrong Issue ID I think. |
|
Indeed, this one: #3442 Could you rebase your work ? 🇫🇷 👋🏻 |
|
I've done a merge recently and it looks like I'm ahead of master. With regards to #3442 I think this might be fixed by this line https://github.com/dompdf/dompdf/pull/3269/files#diff-f365bcb24d5c081b6bfde4aa59a8eda68824ea9658c362098554fc659dcec1d0R3426 It's funny to see that we are literally trying to do the same thing btw, nothing spells out fun more than trying to embed XML in PDF metadata. |
Okayy, I got it wrong: |
|
https://github.com/williamdes/dompdf/tree/pdfa-2.0 and https://github.com/williamdes/dompdf/tree/feat/pdfa is a rebased version without merges |
|
FYI I'm re-targeting this to 3.1 (from 3.0.1) since it's a new feature not a patch. I know there are a lot of issues slate for 3.0.x releases but I suspect most of those will be pushed out once I have a chance to review them. |
There was a problem hiding this comment.
Can you add Fixes: #3442 to this PR ?
It passes nearly all compliance tests except
[Specification: ISO 19005-3:2012, Clause: 6.2.11.4.1, Test number: 1](https://github.com/veraPDF/veraPDF-validation-profiles/wiki/PDFA-Parts-2-and-3-rules#rule-621141-1)
The font programs for all fonts used for rendering within a conforming file shall be embedded within that file, as defined in ISO 32000-1:2008, 9.9. Failed
Let's follow up on #3443
|
Would you mind reviewing this first batch @bsweeney ? |
| /** | ||
| * @var bool Is PDF/A compliance mode enabled | ||
| */ | ||
| public $pdfa = false; |
There was a problem hiding this comment.
Do we want to generically support PDF/A since various levels of compliance are defined? Should we just support a specific version which evolves as we update the library.
Also, instead of a flag for PDF/A support should we define constants (e.g., DOMPDF::PDF17, DOMPDF::PDFA1A) for various specifications and store the desired spec in a property, using that to toggle functionality?
This PR adds experimental PDF/A compliance mode and closes #1106
I'm calling this experimental for multiple reasons:
This still should work for most people on non esoteric documents.
Addendum
Fixes #3442