groff
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: PGP signature


reply via email to

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