Right here! ;-) If I've got it right, there are two problems:

1. The creation date in the metadata defaults to the current date and
time so that's different with each run.
2. The file ID in the PDF trailer is also dependent on the current date
and time.

N° 1 should be solveable by explicitely setting some creation date in an
XMP metadata packet in the fo:declarations element. For example:

  <fo:declarations>
    <x:xmpmeta xmlns:x="adobe:ns:meta/">
      <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";>
        <rdf:Description rdf:about=""
          xmlns:dc="http://purl.org/dc/elements/1.1/";>
          <!-- Dublin Core properties go here -->
          <dc:title>A Forrest document</dc:title>
        </rdf:Description>
        <rdf:Description rdf:about=""
          xmlns:xmp="http://ns.adobe.com/xap/1.0/";>
          <!-- XMP properties go here -->
          <xmp:CreatorTool>Apache Forrest</xmp:CreatorTool>
          <xmp:CreateDate>2010-06-21T14:20:00+02:00</xmp:CreateDate>
          <xmp:MetadataDate>2010-06-21T14:20:00+02:00</xmp:MetadataDate>
        </rdf:Description>
      </rdf:RDF>
    </x:xmpmeta>
  </fo:declarations>

See also http://xmlgraphics.apache.org/fop/0.95/metadata.html

However, taking a short look, it looks like the metadata date is
currently always set to the current date and time. So we'd have to
change FOP to allow overriding the metadata date.

N° 2 is only solveable by introducing a configuration setting that
disables the creation of the file ID in the PDF trailer. Standard like
PDF/A and PDF/X require the presence of the file ID. But in this case,
it is unwanted, of course.

I've created a Bugzilla issue for FOP with this:
https://issues.apache.org/bugzilla/show_bug.cgi?id=49479

I can't promise that I can look into this very soon.

On 21.06.2010 13:50:31 Tim Williams wrote:
> On Mon, Jun 21, 2010 at 7:42 AM, David Crossley <cross...@apache.org> wrote:
> > Done this now. See issue
> > https://issues.apache.org/jira/browse/FOR-1200
> 
> This is good, as it fixes the symptoms, but we've got to find someone
> with pdf expertise to fix the underlying issue FOR-1077 as it's
> probably a blocker in our current state.  I reckon I'm only stating
> the obvious though:)
> 
> --tim




Jeremias Maerki