[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
G. Branden Robinson
status of dev-gropdf-boxes (was: (A possible) way to change the background color of pdf)
Fri, 18 Jun 2021 03:08:12 +1000
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
> https://lists.gnu.org/archive/html/groff/2021-04/msg00000.html 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
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
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 in nroff mode. So I fixed that.
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)
 $ printf ".LP\nI'm the man in the\n.BX box\n" | nroff -ms | cat -s
Description: PGP signature