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
