Follow-up Comment #20, bug #64484 (group groff): Hi Branden,
With the sboxes issue I can understand what is happening, but not why!
Using this test:-
.sp 1i
\m[white]White on blue
\M[blue]\c
.\" .pdfbackground pagefill
\X'pdf: background pagefill'\c
\M[]\c
.sp 1i
\M[red]\D'C 1i'
And this command:-
test-groff -Tpdf gbr-flow.trf -Z > gbr-flow-patched.Z
And diff against an unpatched version:-
[derij@pip build (master)]$ diff gbr-flow-1.23.Z gbr-flow-patched.Z
17a18
> x X pdf: background pagefill
20,21d20
< DFr 0 0 65535
< x X pdf: background pagefill
You can see the \M[blue] (DFr 0 0 65535) has fallen down a crack somewhere,
and the reason the page is black is because the default fill colour (DFd) for
gropdf and grops is black. If you remove the \c from the \M[blue] it now
works, so it looks like your patch is dropping the colour change if it's
pending.
So you are correct in suspecting missing colours is the problem. Our groff
book may have a clue where it says:-
\m doesn’t produce an input token in GNU troff. As a consequence, it can be
used
in requests like mc (which expects a single character as an argument) to
change the
color on the fly:
.mc \m[red]x\m[]
I hope my mini test case above helps you track it down.
The two printf's I proffered should have used -z not -Z since I wanted you to
notice the errors produced by the \X example.
Cheers
Deri
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?64484>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
