Reference details regarding PDF versioning:
PDF Reference, Third Edition (PDF 1.4):
https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/pdf_reference_archives/PDFReference.pdf
Page 4 (24), 1.2 Introduction to PDF 1.4 Features.
Page 61 (81), 3.4 File Structure.
Page 63 (83), 3.4.1 File Header.
Pages 70-71 (90-91), 3.4.5 Incremental Updates (after Figure 3.3).
Page 83 (103), 3.6.1 Document Catalog.
Pages 783-786 (803-806), Appendix H, section H.1 PDF Version Numbers.
Page 790 (810), Appendix H, section H3 Implementation Notes, 3.4.1 "File Header", paragraph 13.
Page 791 (811), Appendix H, section H3 Implementation Notes, 3.6.1 "Document Catalog", paragraph 18.
Relevant note:
Self-identification of chronological versions of PDF: Identification of chronological versions of PDF can be given in two places in any PDF file since version 1.4, including PDF 2.0 files. All PDF files have a version identified in the header with the 5 characters %PDF– followed by a version number of the form 1.N, where N is a digit between 0 and 7 or a version number of 2.0. For example, PDF 1.7 would be identified as %PDF–1.7. However, beginning with PDF 1.4, a conforming PDF writer may use the Version entry in the document Catalog to override the version specified in the header. The location of the Catalog within the file is indicated in the Root entry of the file trailer/footer. This override feature was introduced to facilitate the incremental updating of a PDF by simply adding to the end of the file. As a result, it is necessary to locate the Catalog within the file to get the correct version number. Unless the PDF is "linearized," in which case the Catalog is up front, this will require reading the trailer and then using the reference there to locate the Catalog, which will typically be compressed. This has practical implications because format identification tools, including DROID, typically look for particular characters at the beginning of a file (i.e., in the header), to permit identification with minimal effort. DROID can look for characters at the end of the file, but is not able to follow an indirect reference or decompress file contents. When the version number is not the same in the header and the Catalog, there is potential for format identification errors.
Source: https://www.loc.gov/preservation/digital/formats/fdd/fdd000474.shtml#notes
Earlier note version: https://www.loc.gov/preservation/digital/formats/fdd/fdd000122.shtml#notes
Test:
pdfinfo catalog-version-test.pdf | grep "PDF version:"
shows:
PDF version: 1.4
It should display:
PDF version: 2.0
If you open the PDF with Firefox, pdf.js will tell the PDF version is 2.0.
Since PDF 1.4, PDF Version may be overriden from document catalog, something like:
1 0 obj
<<
/Type /Catalog
/Version /1.5
/Pages 2 0 R
>>
endobj
The PDF version as defined in the example above should be identified as a PDF version 1.5 instead of 1.4, even when the header says %PDF-1.4.
Poppler currently reports this as a PDF 1.4 document, as PDFDoc.cc
seems to set this based on header data only.