On Thu, Apr 04, 2024 at 06:21:37PM -0500, G. Branden Robinson wrote: > Hi Christof, > > Thanks for the report. > > At 2024-04-04T23:44:25+0200, Christof Meerwald wrote: > > There appear to be two bugs in how gropdf (from 1.23.0) writes the > > CreationDate/ModDate. To demonstrate I am running > > > > while sleep 60; do date; echo "" | > > groff -Z -Tpdf | gropdf | fgrep -a Date; done > > The body of this loop can be simplified. > > echo | groff -Tpdf | grep -a Date > > I can't reproduce this problem with groff 1.23.0.
Oh yes, it's a Debian/Ubuntu groff 1.23.0 (didn't think it had any additional patches). > > $ ~/groff-stable/bin/groff --version | head -n 1 > GNU groff version 1.23.0 > $ echo | SOURCE_DATE_EPOCH=1000000000 ~/groff-stable/bin/groff -Tpdf \ > | grep -a Date > 5 0 obj << /CreationDate (D:20010908204640-05'00') > /ModDate (D:20010908204640-05'00') > > > I don't think there should be a "+" sign in the last component of the > > dates, it should probably be > > > > D:20240404233357+02'00' > > > > instead of > > > > D:20240404233357+02'+00' > > I agree that that looks weird. (On the other hand, ASN.1 date syntax > does not come naturally to me.) And I _can_ reproduce it with groff > Git. > > $ ~/groff-HEAD/bin/groff --version | head -n 1 > GNU groff version 1.23.0.1094-94002 > $ echo | SOURCE_DATE_EPOCH=1000000000 ~/groff-HEAD/bin/groff -Tpdf | grep -a > Date > 5 0 obj << /CreationDate (D:20010909014640+00'+00') > /ModDate (D:20010909014640+00'+00') so these should actually be D:20010909014640Z00'00' so that's a third bug then. > > And I am pretty sure we didn't just switch to summer time at around > > 23:32 here. > > > > gropdf 1.22.4 doesn't appear to have these bugs. > > I infer that you are using a Debian-derived groff package carrying a > patch by Colin Watson that he committed to groff Git shortly after the > 1.23.0 release. > > https://git.savannah.gnu.org/cgit/groff.git/commit/?id=d7bbfb04ea25a82a8597cdef6ebb391cb78ab47c > > Colin, can you double-check whether you're producing a date format > conformant with ยง7.9.4 of ISO 32000? I'm attaching the relevant pages > of Adobe's gratis version of the standard. I am attaching a patch that should address all three bugs. Christof -- https://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org
--- gropdf.orig 2023-07-14 18:44:41.000000000 +0200 +++ gropdf 2024-04-05 14:09:39.776316096 +0200 @@ -344,13 +344,7 @@ # If we get here, $papersz was invalid, so try the next one. } -my @dt; -if ($ENV{SOURCE_DATE_EPOCH}) { - @dt=gmtime($ENV{SOURCE_DATE_EPOCH}); -} else { - @dt=localtime; -} -my $dt=PDFDate(\@dt); +my $dt=PDFDate(time); my %info=('Creator' => "(groff version $cfg{GROFF_VERSION})", 'Producer' => "(gropdf version $cfg{GROFF_VERSION})", @@ -633,14 +627,19 @@ sub PDFDate { - my $dt=shift; + my $ts=shift; + my @dt; my $offset; + my $rel; if ($ENV{SOURCE_DATE_EPOCH}) { $offset=0; + @dt=gmtime($ENV{SOURCE_DATE_EPOCH}); } else { - $offset=mktime((localtime $dt)[0..5]) - mktime((gmtime $dt)[0..5]); + @dt=localtime($ts); + $offset=mktime(@dt[0..5]) - mktime((gmtime $ts)[0..5]); } - return(sprintf("D:%04d%02d%02d%02d%02d%02d%+03d'%+03d'",$dt->[5]+1900,$dt->[4]+1,$dt->[3],$dt->[2],$dt->[1],$dt->[0],int($offset/3600),int(($offset%3600)/60))); + $rel=($offset==0)?'Z':($offset>0)?'+':'-'; + return(sprintf("D:%04d%02d%02d%02d%02d%02d%s%02d'%02d'",$dt[5]+1900,$dt[4]+1,$dt[3],$dt[2],$dt[1],$dt[0],$rel,int(abs($offset)/3600),int((abs($offset)%3600)/60))); } sub ToPoints