Openpdf: Incorrect information about the library

[V-F]

The library version is currently parsed from the manifest file in the
com.lowagie.text.VersionBean class . If a program is built as a single jar file the manifest file of the library will be replaced and incorrect information will be parsed. This information is used by creation of pdf document (see: com.lowagie.text.pdf.PdfPages line: 152 / com.lowagie.text.pdf.PdfStamperImp line: 170. The constant com.lowagie.text.pdf.PdfName.ITXT is also no longer relevant). It probably makes sense to store the library information in a property file or as constant values.

[andreasrosdal]

@V-F Can you please propose a better implementation and submit a PR?
@albfernandez @asturio @sixdouglas What do you think of this?

[asturio]

I think a property file, created at build time (maven can do this for you) is a nice solution, and the VersionBean Voodoo is no longer necessary.

[andreasrosdal]

Please make sure that this works in all use cases, for example also when OpenPDF is used in a Java webapp on Tomcat.

[sixdouglas]

@asturio @andreasrosdal any news about my last changes? Did you have time to have a look at it? Can you give some input to make it fit your will?

[mkl-public]

The constant com.lowagie.text.pdf.PdfName.ITXT is also no longer relevant

More to the point, the value, the name ITXT, has been registered as prefix for second-class names by Bruno Lowagie on behalf of 1T3XT BVBA on 29.04.2009. Thus, its use is up to iText to decide and its use in OpenPDF may eventually not be desired anymore.

You might want to consider registering an own prefix to use instead or dropping the version string injection altogether.

---

To clarify: This is not a matter of a code license being satisfied, not about whether using OpenPDF is ok or not. It's about the output PDFs being valid PDFs: Using another developer's registered names with a content differing from everything that developer would have used as a value may be considered invalid (and neither Bruno nor the former 1T3XT BVBA would use "OpenPdf" as part of the value of ITXT).

(Admittedly it's about an aspect of the output PDFs that most likely no PDF parser / validator will ever test unless someone is explicitly attempting to construct an issue.)

[Lonzak]

Luckily the other messages have been deleted - no one with a sane mind would want you to stop sharing your extensive PDF knowledge, MKL!

But back to the point: I have registed a 2nd class prefix once and I agree with MKL. The prefix "belongs" to the iText guys and a such proud project like openPDF should get its own.

One last thing: Bruno always mentioned that he is able to recognize PDFs created with iText due to some hidden markers/attributes etc. This proprietary info is imho one of those markers. So I removed it in my (temporary) fork a long time ago...

[sixdouglas]

I totally agree with you.
Hard with the code, kind with with the guys.
Deep knowledge are needed, specially for people like me, new on the project.
This said, I don’t really understand what you mean by “register”

[mkl-public]

@Lonzak

One last thing: Bruno always mentioned that he is able to recognize PDFs created with iText due to some hidden markers/attributes etc. This proprietary info is imho one of those markers. So I removed it in my (temporary) fork a long time ago...

It is one such marker but as it's so obvious it clearly is usually removed by people trying to hide the actual producer. Other markers are less obvious, in particular a combination of PDF generation properties, e.g. the preferred eol-marker, the choice of direct or indirect objects for certain dictionaries, the position of certain dictionaries in the serialized file, ...

By removing the entry from your fork, you only stop those who only look superficially... ;)

@sixdouglas

This said, I don’t really understand what you mean by “register”

See ISO 32000-2, _Annex E (normative) PDF Name Registry_

This annex discusses a registry for developers, controlled by ISO and currently provided by Adobe on behalf of ISO.
...
To avoid conflicts with third-party names and with future versions of PDF, ISO maintains a registry for certain private names and formats. Developers shall only add private data that conforms to the registry rules. The registry includes three classes:
...
Second class. Names that are applicable to a specific developer. ISO does not register second-class data formats. ISO distributes second-class names by registering developer-specific 4-byte prefixes.

Strictly said this prefix plus an underscore shall form the start of every second class name of the developer in question, so one could argue ITXT alone is a non-conforming name. (I'm not sure, though, probably ITXT alone is even registered as a class 1 name, so don't count on ITXT alone being non-conforming...)

Meanwhile you find the class 2 registry here: https://github.com/adobe/pdf-names-list

[Lonzak]

@MKL I know that it only was a superficial way and that the way a PDF is structered is a kind of fingerprint in itself...
Thanks for the list! Some years back I asked adobe (I think it was Leonard) for that exact list but they didn't give it out. Nice to finally see it...
And I didn't know that you registered your own prefix MKLx :-)

[mkl-public]

@Lonzak

Some years back I asked adobe (I think it was Leonard) for that exact list but they didn't give it out. Nice to finally see it...

Beware, see the Additional Details in the README:

The XLSX file in this repository contains all developer prefixes that have been added to the list since 2008 (when ISO 32000-1 was published). This document is maintained by the maintainers of this repository and no PRs to change it will be accepted.

NOTE: Due to legal reasons, Adobe maintains the list of all registrations that occured prior to that 2008.

Thus, don't count on the list being complete.

[sixdouglas]

Ok, with this explained, I agree with you for OpenPdf to have this kind of prefix registered.

[mkl-public]

@sixdouglas

OpenPdf to have this kind of prefix registered

There also are alternatives, e.g. one could stop injecting such a marker altogether or one could use a comment in a prominent position, e.g. before the startxref keyword as done by newer iText versions:

trailer
<</Size 21/Root 12 0 R/Info 11 0 R/ID [<903db25aad61d741a1c42adaa817180e><c46269b186e33bfde99f25326441f2b1>]>>
%iText-5.5.11
startxref
197644
%%EOF

(And it's really not that important; when I wrote that comment yesterday, I didn't think that issue would become a topic almost of its own...)

[asturio]

It should be nice to have a registered prefix, but as I see in the list, and in the registration template, the Information for a "Open Source Project" could be difficult, as there is no address, no "single person", an no e-mail address for OpenPDF as an organization.
Any ideas on that?

[Lonzak]

Prefix: LBRP_ (For LiBRePdf) but other suggestions are welcome...
First Name: Andreas
Last Name: Rosdal
Email: andreasrosdal[at]somemail.net (an email he is willing to provide)
Entity/Organization Name: OpenPDF
Create Date: date

[andreasrosdal]

@Lonzak I have somewhat retired from maintaining this project, I'm so busy with other things. We need more other people to contribute to maintenance, such as yourself. So using my name in the registration would not be the best alternative.