[Top][All Lists]

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

status of dev-gropdf-boxes (was: (A possible) way to change the backgrou

From: G. Branden Robinson
Subject: status of dev-gropdf-boxes (was: (A possible) way to change the background color of pdf)
Date: Fri, 18 Jun 2021 03:08:12 +1000
User-agent: NeoMutt/20180716

At 2021-06-15T11:01:30+0100, Deri wrote:
> On Tuesday, 15 June 2021 10:29:37 BST Hans Bezemer wrote:
> > Dear all,
> > 
> > I want to have a black background with green text for my slides.
> > 
> > If I'm correct this can't be set within groff.
> Hi Hans,
> In the message
> a way
> of setting the paper colour in pdf files is described. Currently you
> need to checkout the gropdf- boxes branch of the git repository to use
> it.

Since I said I'd work on this, and it's stalled, it might be a good idea
to report where I am with it to the list.

Things started nicely, but the article that Deri wrote to document it[1]
is a quasi-quine.  That's cool, but in its current form the document is
basically double the length it could be.  I fear for future revisions
driving things out of sync, so what I wanted to do was move the document
to an *.in file and have the full version generated with Make and some
simple sed tricks to escape *roff syntax when presenting the document's
source within itself, and of course some special marker to prevent
infinite recursion.  Amid chewing on this I became worried that my
approach would slather my name next to every line of the document in
"git blame" output and look like credit-thieving.

Another thing I noticed was that our ms package's support for changing
the font family integrated poorly with headers and footers.  I fixed

When thinking about how to incorporate this new feature into existing
documentation, I happened across existing uses of the "box" concept in
ms(7), and that reminded me of an annoying problem where ".BX" rendered
like total weird-looking crap[3] in nroff mode.  So I fixed that[4].

Finally, and on a front that isn't a technical problem but which simply
makes me uncomfortable, every time I rebase master onto a branch, the
piles and piles of commits that have happened on master since the last
sync point create a blitz of traffic to the groff-commit list.  Is this
okay?  Or can we work around it somehow?

Or should I just try to hurry up and finish the work on the branch so
that the blitz doesn't keep happening?  *laughcry*


    (this commit is also on the master branch)
[3] $ printf ".LP\nI'm the man in the\n.BX box\n" | nroff -ms | cat -s

Attachment: signature.asc
Description: PGP signature

reply via email to

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