Document default and XMP metadata handling more properly

[j-t-1]

pypdf/pypdf/_writer.py

Lines 225 to 230 in b7ae2e5

	self._header = b"%PDF-1.3"
	self._info_obj = self._add_object(
	DictionaryObject(
	{NameObject("/Producer"): create_string_object("pypdf")}
	)
	)

The Producer key (optional and deprecated in PDF 2.0) has value:

If the document was converted to PDF from another format, the name of the PDF processor that converted it to PDF.

pypdf is not converting it from another format to PDF, it is creating it for the first time.

xmp:CreatorTool entry in the document's metadata stream can be used to represent the creation tool of the document.

xmp:CreatorTool can be used instead.

Quotes from PDF 2.O specification, Table 349 — Entries in the document information dictionary.

[stefan6419846]

This depends on how you interpret it - when creating a PDF file from scratch, IMHO pypdf can be the producer and creator. For all the other cases, this might not strictly follow the specification, but it should not do much harm to set this. From my experience, most documents will not actively use XMP metadata.

What are you trying to achieve with opening this issue? This has been like this at least since 2011 (I did not look at the older PyPI releases): c59a212 For this reason, I do not really see the need to change this unless it actually breaks some stuff.

[j-t-1]

Users may not know that we are slightly misusing this. I did not know until was reading this part of the specification. Although it could be kept as is, it could be documented or commented how we are using it.

We could also have some documentation on using XMP in https://pypdf.readthedocs.io/en/latest/user/metadata.html.

[stefan6419846]

To be honest, I do not think that this is an aspect one would regularly stumble upon - this is the first time I am aware of that someone would refer to this after it has been part of the code since version 1.4, released in January 2006 and thus nearly 20 years ago.

There are quite some code sections where we deliberately violate the standard to deal with broken PDF files - IMHO such aspects are much more important. While the wording in the PDF 1.7 and PDF 1.3 is similar, the reference to XMP is absent there (the PDF 1.3 specification does not even mention XMP). We could document this, but I do not see a real benefit from it.

Regarding XMP metadata, you are of course invited to improve the documentation.

[j-t-1]

Metadata streams were introduced in PDF 1.4, whereas we create a PDF with PDF 1.3 (unrelated not sure why not a lower version) and would be a negative having to increment this as you want to start with the lowest valid number.

Documenting this in the __init__ of PdfWriter does not fit well. Documenting it within https://pypdf.readthedocs.io/en/latest/user/metadata.html using some XMP examples may be helpful to some pypdf developers.

I have not used pypdf + XMP before, so will need to get more familiarity.