Option to convert to PDF/A

[fbotelho]

The PDF/A standard is designed for the archival of information, i.e. it ensures that there are no dependencies in the way the file is created, which would prevent it from remaining viewable, over time, exactly as it was when it was created. It is especially important for libraries, governments, and any entity interested in ensuring that information remains accessible over long periods of time. A Description of the PDF/A standard is available here:
https://en.wikipedia.org/wiki/PDF/A

It would be great to have an optional parameter on Pandoc, which would create PDF/A files without requiring the end-user to understand its technical requirements.

[adunning]

This could be done straightforwardly by adding a variable to the LaTeX and ConTeXt templates. Our method of loading hyperref would also need to change slightly (see p. 12 of the manual at https://www.ctan.org/pkg/pdfx). Note that it only works with XeLaTeX and LuaLaTeX from TeX Live 2016, and that the pdfx package isn't included in a slim installation of TeX Live (i.e. BasicTeX), so it certainly shouldn't be a default.

For ConTeXt, see http://wiki.contextgarden.net/PDF/A.

[jgm]

Do you want to do a PR to the template along these lines, as a starting
point?

+++ Andrew Dunning [Nov 04 16 16:01 ]:

This could be done straightforwardly by adding a variable to the LaTeX
and ConTeXt templates. Our method of loading hyperref would also need
to change slightly (see p. 12 of the manual at
[1]https://www.ctan.org/pkg/pdfx). Note that it only works with XeLaTeX
and LuaLaTeX from TeX Live 2016, and that the pdfx package isn't
included in basic installation of TeX Live.

For ConTeXt, see [2]http://wiki.contextgarden.net/PDF/A.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, [3]view it on GitHub, or [4]mute the
thread.

References

1. https://www.ctan.org/pkg/pdfx
2. http://wiki.contextgarden.net/PDF/A
3. Option to convert to PDF/A #3215 (comment)
4. https://github.com/notifications/unsubscribe-auth/AAAL5Bvuadwd9_Dii_W_Hq9ns0cmfHXqks5q67ksgaJpZM4Kp_1X

[adunning]

What would be the best way to implement this? I see two options:

1. A variable called pdfformat that directly feeds options to the pdfx package, e.g. a-3b.
2. Boolean variables such as pdfa, pdfx, etc. that would be configure these broader standards with the most recent available.

The first option would be a simpler implementation in the template, and provide maximum flexibility and forward compatibility; but it would mean a different interface for LaTeX and ConTeXt.

The second option could allow the same variables to apply to both systems, and take the bother of figuring out the exact version of the standard out of the hands of the user; but then if someone wanted something specific, it would necessitate a custom template.

I do wonder how broadly useful this option would actually be, given that tagging isn't supported by the pdfx package.

[jgm]

The simpler option sounds fine to me. +++ Andrew Dunning [Jan 03 17 17:40 ]:

…

What would be the best way to implement this? I see two options: 1. A variable called pdfformat that directly feeds options to the pdfx package, e.g. a-3b. 2. Boolean variables such as pdfa, pdfx, etc. that would be configure these broader standards with the most recent available. The first option would be a simpler implementation in the template, and provide maximum flexibility and forward compatibility; but it would mean a different interface for LaTeX and ConTeXt. The second option could allow the same variables to apply to both systems, and take the bother of figuring out the exact version of the standard out of the hands of the user; but then if someone wanted something specific, it would necessitate a custom template. I do wonder how broadly useful this option would actually be, given that tagging isn't supported by the pdfx package. — You are receiving this because you commented. Reply to this email directly, [1]view it on GitHub, or [2]mute the thread. References 1. #3215 (comment) 2. https://github.com/notifications/unsubscribe-auth/AAAL5GLKVDiA2yefB5VPN_fWs74R9VgDks5rOviTgaJpZM4Kp_1X

[mb21]

Option two might make sense if we had more PDF generators that could output PDF/A, but wkhtmltopdf won't support PDF/A anytime soon...

[adunning]

Has it been determined whether this is desirable? I am wondering whether I should simply close https://github.com/jgm/pandoc-templates/pull/231 or put up a new PR in this repository. The limitations of xpdf expressed there, meaning that it's not really practical with XeLaTeX, are still present.

[jgm]

I remember looking into this and finding that the requirements for fully conforming pdf/a were very extensive, and not addressed simply by the template changes -- this is probably why I didn't merge the PR, but I honestly can't recall.

I don't think there's much point in making the template changes unless we can combine these with the other changes that would be needed for conforming pdf/a output.

[adunning]

Yes, I think that makes sense, especially since the changes do make the template rather more complex. Perhaps there will be a better route some day …

[hmenke]

I could provide an adapted ConTeXt template which generates PDF/A-1b:2005. This requires some setup on the user side though because ICC profiles have to be installed manually due to licensing reasons.
Furthermore it will not ✨ magically 💫 generate PDF/A. All included images have to conform with PDF/A, the font must embeddable, colours must be compatible, etc.

[mb21]

As much as I like the idea of PDF/A: I guess there are applications that can automatically post-process PDFs to generate PDF/As (by converting images, removing unsupported features etc.), right? So if the user would have to run one of those to make sure all her images/fonts are compliant anyway, I'm not sure it helps a lot if pandoc gets you halfway there?

On the other hand, if there are simple changes that can be done to the existing ConTeXt template that help PDF/A production, that would certainly be welcome. But I dread the added complexity of a second ConTeXt template that needs to be maintained...

[fbotelho]

I think that this is important functionality and I vote for inclusion, but of course, I am not a developer so follow your best judgement. Thanks for mentioning the existance of software that does this conversion into PDF/A compliant documentation. I will try to find it for Arch Linux. Fernando

[fbotelho]

This might not help me, since I will need to be able to distribute the code, but I am sure it will help others.