Improve PDF metadata support in PGF #17233
Conversation
|
👍 In principle, but I think that this should get some through tests while we are thinking about it. Do we want to push this to 3.4 or try to squeeze it in for 3.3? |
|
This is difficult to test, because unlike the builtin PDF export, the PGF backend uses latex, which has no |
|
I guess you could possibly use pdfinfo (from poppler) or mutool (from mupdf) as optional test dependency to extract the metadata? |
|
It doesn't print |
|
Also, another possibility is pikepdf, which we could use from Python. |
This takes keys that match the PDF specification instead of lower-case, 'pdf'-prefixed keys, so is a bit simpler. Also, deprecate ability to accept key case-insensitively, as that is not done in the PDF backend.
This ensures that the same default values are produced, and more importantly ensures that the same keys are accepted. Previously, PGF only allowed a subset of keys.
It's something internal to the PDF backend, and there's no need to require the metadata to use that type instead of a plain string.
This is supported through the multipage PdfPages, but not direct output of a single figure via PGF.
They're basically the same, but with different `pgf.texsystem` settings.
|
That was a good idea, because I found a few bugs in the PGF side, as hyperref seems to have some differing requirements on the format for things. |
PR Summary
The PGF backend only supported PDF metadata using the multi-page
PdfPagesclass; this adds support for adding metadata to single-figure saving directly viasavefig.Additionally, refactor the metadata support from the PDF side into a common function to setup and verify metadata that can be used in the PGF side as well. This ensures that the same set of keys is allowed, which weren't before.
PR Checklist