[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
> 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
> 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
that[2].
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*
Regards,
Branden
[1]
https://git.savannah.gnu.org/cgit/groff.git/tree/contrib/sboxes/msboxes.ms?h=dev-gropdf-boxes
[2]
https://git.savannah.gnu.org/cgit/groff.git/commit/?h=dev-gropdf-boxes&id=fd15f9f61f199f51559195546e3abcc827023331
(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
[4]
https://git.savannah.gnu.org/cgit/groff.git/commit/tmac/s.tmac?id=e260fc23612e9c865a01bc25fbc154fe67608680
signature.asc
Description: PGP signature