Forrest
  1. Forrest
  2. FOR-1077

new CreationDate causes constant differences in output pdf documents

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 0.9, 0.10-dev
    • Fix Version/s: 0.10-dev
    • Component/s: Plugin: output.pdf
    • Labels:
      None

      Description

      A problem has recently occurred with generating PDFs and publishing them. See the massive amount of commits to the Forrest "site" svn today when two different committers updated the website. Every PDF changed. I did some investigation and can see that a CreationDate is being added. This is of course is changing on every run of forrest.

        Activity

        Hide
        David Crossley added a comment -
        Deferred to v0.10-dev
        Show
        David Crossley added a comment - Deferred to v0.10-dev
        Hide
        Tim Williams added a comment -
        Show
        Tim Williams added a comment - Add reference to FOPs report on this. https://issues.apache.org/bugzilla/show_bug.cgi?id=49479 ... and conversation.... http://www.mail-archive.com/dev@forrest.apache.org/msg16478.html
        Hide
        Jeremias Maerki added a comment -
        I'm pretty sure it's not only the XMP packet that has triggered this. It's not just the creation date that changes each time a PDF is generated. The "ID" trailer element is generated from the current date & time as per recommendation in the PDF specification.

        Furthermore, even if the creation date is set in the XMP packet, it is explicitely not taken into account when the PDF is generated. This is a merge rule for XMP data.

        So how to go about this:
        Ideally, Forrest would only recreate the PDF if the source file was actually changed but that's probably unrealistic. So let's look at FOP: The "ID" element is actually optional but was introduced because PDF/A functionality requires it. It would be easy to enable the "ID" element only if PDF/A is enabled. Handling XMP metadata is more complicated. Even if you don't supply an XMP packet in fo:declarations, some minimal XMP metadata is generated. And the XMP metadata is synchronized with the legacy "Info" object in the PDF which also contains the creation date.

        The only way I see is that some sort of special profile (like the PDF/A and PDF/X profiles) is created that would skip the elements that change every time the PDF is generated. That would take quite a bit of work though. And it would have to be enabled in Forrest/Cocoon somehow once it's available.
        Show
        Jeremias Maerki added a comment - I'm pretty sure it's not only the XMP packet that has triggered this. It's not just the creation date that changes each time a PDF is generated. The "ID" trailer element is generated from the current date & time as per recommendation in the PDF specification. Furthermore, even if the creation date is set in the XMP packet, it is explicitely not taken into account when the PDF is generated. This is a merge rule for XMP data. So how to go about this: Ideally, Forrest would only recreate the PDF if the source file was actually changed but that's probably unrealistic. So let's look at FOP: The "ID" element is actually optional but was introduced because PDF/A functionality requires it. It would be easy to enable the "ID" element only if PDF/A is enabled. Handling XMP metadata is more complicated. Even if you don't supply an XMP packet in fo:declarations, some minimal XMP metadata is generated. And the XMP metadata is synchronized with the legacy "Info" object in the PDF which also contains the creation date. The only way I see is that some sort of special profile (like the PDF/A and PDF/X profiles) is created that would skip the elements that change every time the PDF is generated. That would take quite a bit of work though. And it would have to be enabled in Forrest/Cocoon somehow once it's available.
        Hide
        David Crossley added a comment -
        Did some quick investigation. This seems related to FOP's "XMP metadata" ability, which was recently utilised at Forrest in r632916.

        http://wiki.apache.org/xmlgraphics-fop/HowTo/XMP
        shows that CreationDate is internal FOP metadata. I cannot yet see if it can be disabled.
        Show
        David Crossley added a comment - Did some quick investigation. This seems related to FOP's "XMP metadata" ability, which was recently utilised at Forrest in r632916. http://wiki.apache.org/xmlgraphics-fop/HowTo/XMP shows that CreationDate is internal FOP metadata. I cannot yet see if it can be disabled.

          People

          • Assignee:
            Unassigned
            Reporter:
            David Crossley
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development