[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Reproducible dates in HTML/PDF/PS output files?

From: Werner LEMBERG
Subject: Re: [Groff] Reproducible dates in HTML/PDF/PS output files?
Date: Thu, 28 Aug 2014 06:35:33 +0200 (CEST)

>> Basically, it looks good.  However, I'm not convinced that I want
>> to *always* suppress timestamps (and a setting in a user's
>> environment is more or less permanent).  Instead, I prefer good old
>> command line options to control this behaviour.
> I'd prefer if groff would never write "CreationDate:" lines.
> I don't even see the need to provide an option to write them.

Hmm.  How are you going to handle pdftex output?  This program also
always inserts the creation date.

> The information contained is misleading in the best case, because
> the time at which the document was formatted doesn't really tell you
> anything about the document.

It does.  Together with the version information of groff, it helps
debug rendering and/or formatting issues.  I consider this quite
important – especially with TeX output it gives hints how to reliably
reproduce a document, given that it is not common to store the used
macro package versions in the document itself.  Note that this is not
a constructed argument, I actually *have* experienced this, since some
versions of pdftex indeed did produce buggy output.

> In some cases, it may mislead people to think it was recently
> modified, in almost all cases, it is just completely irrelevant.  In
> some cases, it may endanger privacy - [...]

For such cases a command line option seems adequate for me.

> At least, even if an option to write "CreationDate:" lines would be
> provided, it ought to be off by default.

Here I disagree.  But your reasoning makes me believe that both an
environment variable *and* a command line option is the way to go.

> At the very least, the option ought to be turned off in builds.  In
> a build, it is always a nuisance and never useful.

Again I disagree.  Documentation files have the tendency to be
distributed without the rest of the package.

> Having reproducible build results is always good, not only when you
> specifically require them.  [...]

Honestly, I think you are extremely exaggerating.  The last 20 years
it was fine to have such tags, and suddenly it becomes the most evil
in the world...  As has been mentioned by Mike, there are other means
like filtering output of `pdfinfo', or directly ignoring the affected
byte positions in a PDF file.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]