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

Reply via email to