Re: [Groff] Is there a good way to get time/date?

[Steve Izma]

> > In order to get the time/date I've done:
> >     
> > 
> > .sy echo Printed `date` >current.date
> > .so current.date
> > .sy rm current.date
> > .sy stat \n(.F | fgrep Change >change.time
> > .so change.time
> > .sy rm change.time
> > 
> > And it produced:
> >             Printed Tue Apr 25 13:09:26 EDT 2000
> >       Change: Tue Apr 25 13:08:33 2000(00000.00:00:53)
> > 
> > Is there a better way?  There could be.
> > (this is very useful when doing documents)

> AFAIK, there is no better way.  Here is the (similar) example given in
> groff.texinfo:

>   .sy perl -e 'printf ".nr H %d\\n.nr M %d\\n.nr S %d\\n",\
>               (localtime(time))[2,1,0]' > /tmp/x\n[$$]
>   .so /tmp/x\n[$$]
>   .sy rm /tmp/x\n[$$]
>   \nH:\nM:\nS

> To use the sy request we need the -U switch which is not optimal.

> Maybe we shall add registers to provide the current time also in
> gtroff?


I capture the output of the date program as a string variable on
the groff command line and then have a macro that prints that
string at some appropriate place on the page (our production
pages include printer's crop marks, so the date goes outside the
trim area):

groff -mwhatever -dpr_time="`date`" filename

We almost always run groff from within a shell script that does
other kinds of conversion work (e.g., tagged files to a data
stream with troff requests) so this definition is built into the
script and no one needs to worry about typing it everytime. It
also allows for including the user's name in the same place on the
output, more or less like this:

groff -mwhatever -duser=$LOGNAME -dpr_time="`date`" filename

so that the sheet coming out of the printer is quickly associated
with the person who sent it (we don't waste paper on banner
sheets).

By the way, I apologize for not responding to questions about our
use of XML and groff that were raised late last year. Almost all
my mental energy at work has been focused on getting our system
to work on some of the journals we publish, and it's been rather
exhausting. I've finally got a bit of breathing space, but not
yet enough to describe our approach in detail.

In brief, I have written some python scripts to aid in creating
XML from RTF documents; we use Vi on Linux for fixing the tags
and creating files conforming to something close to the ISO 12093
serials or journals DTD; and we use nsgmls to validate the files.
Then for typesetting, I include groff in a pipeline with another
python script (that converts the XML to groff requests) and
output PostScript. The scripts are not particularly efficient and
I think I may have some fundamental problems in the approach I
have used for creating troff requests from the hierarchy of XML
tags, but it currently works well enough to get journals and
some books out the door to the printers. We use 400Mhz PC's
running Debian 2.1 GNU/Linux; it takes 30 to 40 seconds
(depending on graphics) to create the PostScript for about 200
pages from the XML files (most of this speed is due to groff; I'm
sure that my pipeline before groff can be made much more
efficient).

I still need to document the details of this process because I
desperately need advice on at least a couple of basic issues:

- to what extent does groff need to know the hierarchical
  relationships (parent-child-grandchild, etc.) of the structure
  of the XML document?
- I use only macro packages that I have written for XML-type
  projects; since XML imposes severe restrictions on what can
  occur within a document, this theoretically makes macro writing
  much easier; but how do you write some macro libraries that
  will work for as many projects as possible?

I realize that you can't do much with these questions without
some examples, so that's what I hope to work on in "spare" time
over the next couple of months.


-- 
Steve Izma,                               (519) 884-0710 ext. 6125
    Wilfrid Laurier University Press      FAX: (519) 725-1399
    Waterloo, Ont., Canada N2L 3C5        address@hidden