Reproducible PDF output not working
Sometime ago, I asked here about reproducible PDF output, and was told
about the --nodates option of context. It worked then, but doesn't seem
to be working now, with a recent version of context.
----------------------------------------------------------------------
$ cat foo.tex
\starttext
Hello, world!
\stoptext
$ ( rm -f a b foo.log foo.pdf foo.tuc && \
context --nodates foo.tex && cp foo.pdf a && \
sleep 1 && \
context --nodates foo.tex && cp foo.pdf b ) > /dev/null && \
md5sum a b
bdd1911005623a519f5ecb3dbcb8bc7b a
06157e2840c0758ca46d5e7f0be239ef b
$ context --version
[elided]
mtx-context | current version: 2018.04.19 15:53
----------------------------------------------------------------------
File `a' has the words "pdfx:IDfoo.2018-04-24T01:49:47-19:00",
and file `b' has "pdfx:IDfoo.2018-04-24T01:49:49-19:00" at
the corresponding position.
Please tell me how to ensure that the PDF output depends only on the
source, and not on the time the output is generated.
Thanks,
Raghu.
--
N. Raghavendra
Hi Raghu, I can reproduce the problem you observe. Hans, it seems the identifier uses the time of compilation, when it should probably use the time of last modification of the source file. Best, Arthur
At 2018-04-23T23:49:19+02:00, Arthur Reutenauer wrote:
it seems the identifier uses the time of compilation, when it should probably use the time of last modification of the source file.
Yes, with the 2018.04.19 version, the identifier in the output of
`context --nodates' includes the compilation time, as in
pdfx:IDfoo.2018-04-24T01:49:47-19:00.
On the other hand, with the 2017.11.14 version, the identifier in the
output of `context --nodates' is just
pdfx:IDfoo
Raghu.
PS: Incidentally, what is the "-19:00" in date in the first identifier?
In my time zone, IST, I would have expected 2018-04-24T01:49:47+05:30.
--
N. Raghavendra
On 4/24/2018 6:28 AM, N. Raghavendra wrote:
At 2018-04-23T23:49:19+02:00, Arthur Reutenauer wrote:
it seems the identifier uses the time of compilation, when it should probably use the time of last modification of the source file.
Yes, with the 2018.04.19 version, the identifier in the output of `context --nodates' includes the compilation time, as in
pdfx:IDfoo.2018-04-24T01:49:47-19:00.
On the other hand, with the 2017.11.14 version, the identifier in the output of `context --nodates' is just
pdfx:IDfoo
Raghu. fixed in beta but no beta soon ... in lpdf-ini.lua you can try to fix this
function lpdf.id(date) local banner = environment.jobname or tex.jobname or "unknown" if not date then return banner else return format("%s | %s",banner,timestamp) end end and then run context --make Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
At 2018-04-24T09:44:09+02:00, Hans Hagen wrote:
fixed in beta but no beta soon ... in lpdf-ini.lua you can try to fix this
Thank you for the solution.
Raghu.
--
N. Raghavendra
On the other hand, with the 2017.11.14 version, the identifier in the output of `context --nodates' is just
pdfx:IDfoo
The longer identifier is definitely better, but it should be possible to make it predictable over successive runs.
PS: Incidentally, what is the "-19:00" in date in the first identifier? In my time zone, IST, I would have expected 2018-04-24T01:49:47+05:30.
I remember noticing something strange in the date format when files were compiled after midnight local time while the UTC time was before midnight. It didn’t seem enough to send a bug report at the time, but I can look into it again. And thanks to Hans for his speedy response, as usual :-) Best, Arthur
At 2018-04-24T10:03:16+02:00, Arthur Reutenauer wrote:
PS: Incidentally, what is the "-19:00" in date in the first identifier? In my time zone, IST, I would have expected 2018-04-24T01:49:47+05:30.
I remember noticing something strange in the date format when files were compiled after midnight local time while the UTC time was before midnight. It didn’t seem enough to send a bug report at the time, but I can look into it again.
Thank you for the help.
Raghu.
--
N. Raghavendra
participants (3)
-
Arthur Reutenauer -
Hans Hagen -
N. Raghavendra