-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create PDF/A documents #132
Comments
@rru-hgb, if you have updates or input on the requirements, please let us know. |
@hochleitner
One not so elegant aspect is that the PDF metadata need to be contained in a separate file ( Some relevant links:
One should also look into |
I'll have a look at it asap. I've read up on the topic as well, and it seems a whole bunch of things is involved. Metadata, color intents, oof. I've added a new Release 2024 milestone, where I'll add all the relevant issues for next year's release. I think a 1-year release cycle with a target of the end of February might work well. If necessary, we can always add a fall release. |
Great. In the meantime I checked |
Just pushed a new and IMO much better variant of PDF/A generation in branch pdf-a-l3. It is based on the forthcoming LaTeX kernel functions for PDF management and extremely simple to use. The only caveat is that Overleaf has no recent version of the
@hochleitner Pls. look at it carefully. If adopted, what else remains to do:
Here is useful link: https://ctan.org/tex-archive/macros/latex/contrib/pdfmanagement-testphase |
The remaining points are completed (translated to TODO: mention PDF/A in README, add link to online validator. |
I fixed files Removed remaining ocurrances of Added a short section on PDF/A and links in Plus another full rebuild. Everything looks good now, pls. check the PR. |
@hochleitner |
Okay, it took me ages to finally check it all out - sorry for the huge delay. Here are my thoughts:
I wonder how much effort it is to reach PDF/A-2a. Because proper accessibility is something we need to tackle sooner or later, maybe the l3 functions will improve this workflow too. |
In the latest commit (b6d93dc) I tested the idea of making local copies of the recent
This works locally as expected. Then uploaded a zipped version to Overleaf, which immediately complains that some of the files cannot be parsed(!). The resulting output is PDF/A (at least Acrobat Reader says so, not tested for actual compliance) but contains garbage before the document starts. In summary, I do not think this a viable option. The project directory is messed up and it still does not work. We should wait for Overleaf to update their LaTeX environment. |
So, I deliberately waited this long to add something to the issue of PDF-A creation (cough, cough), but at least there is good news. Overleaf now includes So, it seems we should be able to merge #160 and make PDF-A generation a default in the |
Looks good! I tested the PDF/A setup with the most recent MikTeX update and also on Overleaf. I suppose we can merge the pdf-a-l3 branch ... |
New efforts on archiving and publishing theses (throughout the whole FH OÖ) have brought up the requirement that archived theses should be in PDF/A format to prevent modification. We should therefore update the PDF generation process to make this possible with the template.
I suggest adding an additional package parameter since it is probably not always desired to create a PDF/A.
It has not been decided which PDF/A standard will be required (there are PDF/A-1 to PDF/A-4 with different subtypes (a, b, c, etc.). We should probably check which ones are feasible and which ones aren't (the accessible versions, e.g., PDF/A-1a, will be problematic with LaTeX as far as I can tell). There might still be potential to influence the final decision if we bring up valid technical requirements/limitations.
The text was updated successfully, but these errors were encountered: