Update of bug #64624 (project groff):
Category: Driver grotty => Preprocessor pic
Item Group: Rendering/Cosmetics => Incorrect behaviour
Status: None => Confirmed
Summary: [grotty] some pic actions make following text
illegible => [pic] doesn't restore fill color after writing output
_______________________________________________________
Follow-up Comment #9:
This discussion was confusing. I think the matter can be clarified by simply
running _pic_ over Dave's input and observing the output.
.do if !dPS .ds PS
.do if !dPE .ds PE
.do if !dPF .ds PF
.do if !dPY .ds PY
.lf 1
.\" nroff -p
Some text.
.lf 3
.PS 0.000i 0.500i
.\" 0 0 0.5 0
.\" 0.000i 0.000i 0.500i 0.000i
.nr 00 \n(.u
.nf
.nr 0x 1
\h'0.500i'
.sp -1
\&\D'Fg 0.000'
.sp -1
\h'0.500i'\v'0.000i'\D'P -0.100i 0.025i 0.000i -0.050i'
.sp -1
\D't 0.100p'\h'-0.100p'
.sp -1
\h'0.500i'\v'0.000i'\D'p -0.100i 0.025i 0.000i -0.050i'
.sp -1
\D't -1.000p'\h'1.000p'
.sp -1
\h'0.000i'\v'0.000i'\D'l 0.400i 0.000i'
.sp -1
.sp 0.000i+1
.if \n(00 .fi
.br
.nr 0x 0
.lf 5
.PE
.lf 6
Some more text.
Observe the `\D'F'` escape sequence setting a fill color for the output, which
is then never restored to whatever value it had before the _pic_ region.
That seems wrong to me, and would account for the problem reported. Apart
from the semantics of "fill color" being different for _nroff_ devices, I
don't think this report has much to do with _grotty_. _pic_ moved something
and didn't put it back when it was done. Preprocessors have to be careful
about that.
So, _pic_ should be made to cache the stroke and fill colors upon starting a
region, and restore them when ending one.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?64624>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
