[
https://issues.apache.org/jira/browse/FOP-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18137407#comment-18137407
]
Juan Manuel Méndez Rey edited comment on FOP-3367 at 11/3/26, 6:38 PM:
-----------------------------------------------------------------------
Agreed on the file ID: it now keeps the current time by default. Using the
creation date for it is opt in, with file-id-from-creation-date or
-creationdate on the command line. The note to ISO 32000-1 14.4 allows that:
"The calculation of the file identifier need not be reproducible; all that
matters is that the identifier is likely to be unique."
I have updated the description and attached a new patch. PR:
https://github.com/apache/xmlgraphics-fop/pull/134, CI passes on my fork:
https://github.com/vejeta/xmlgraphics-fop/actions/runs/41685896137
was (Author: JIRAUSER315370):
Third attempt, after carefully looking at all the previous attempts:
Looking at ISO 32000-1 14.4 recommendation: by default the file ID should keep
the current time.
Every date FOP writes in a PDF now uses the creation date set with
FOUserAgent.setCreationDate(), as you suggested in
[apache/xmlgraphics-fop#65|https://github.com/apache/xmlgraphics-fop/pull/65]
(“You can use the fop api to override dates”). Until now xmp:MetadataDate, the
page piece LastModified date and the dates of embedded files ignored it.
* New PDF renderer option file-id-from-creation-date, default false. Only when
it is enabled does the file ID use that creation date instead of the current
time. The spec allows this in the note to 14.4: “The calculation of the file
identifier need not be reproducible; all that matters is that the identifier is
likely to be unique.” The ID still depends on the content.
* New command line option -creationdate (ISO 8601, for example
2026-11-01T00:00:00Z), which sets the creation date and enables that option, so
the fop command can do what the API does. No environment variable is read.
With -creationdate and a fixed Java time zone, as suggested in FOP-2854, two
runs of the fop command give the same PDF. Distributions can then map
SOURCE_DATE_EPOCH to -creationdate in their own fop scripts and drop their
patches.
The full fop-core suite passes and checkstyle reports no violations.
New Pull request:
[apache/xmlgraphics-fop#134|https://github.com/apache/xmlgraphics-fop/pull/134]
The project CI passes all 10 jobs on my fork (Java 8 to 25, Linux and Windows):
[https://github.com/vejeta/xmlgraphics-fop/actions/runs/41685896137]
> Not all PDF dates use the creation date set on FOUserAgent
> ----------------------------------------------------------
>
> Key: FOP-3367
> URL: https://issues.apache.org/jira/browse/FOP-3367
> Project: FOP
> Issue Type: Bug
> Components: renderer/pdf
> Affects Versions: 2.12
> Reporter: Juan Manuel Méndez Rey
> Priority: Major
> Attachments: FOP-3367.patch
>
>
> [PATCH]
> The date set with FOUserAgent.setCreationDate() is only used for
> /CreationDate and xmp:CreateDate. xmp:MetadataDate, the page piece
> LastModified, embedded file dates and the file ID still use the current time,
> so the same input never gives the same PDF.
> The patch:
> * uses the creation date, when set, for those other dates
> * adds a PDF renderer option, file-id-from-creation-date (default false), to
> use it for the file ID too. By default the ID keeps the current time.
> * adds -creationdate to the command line, which sets the date and turns that
> option on
> Nothing changes when no creation date is set. With -creationdate and a fixed
> time zone, two fop runs give the same PDF, which is what reproducible builds
> need.
> PR: https://github.com/apache/xmlgraphics-fop/pull/134
> Related: FOP-2854, FOP-3040
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
