[bug #64592] [troff] registers .m and .M contain no initial value

[Deri James]

Follow-up Comment #3, bug #64592 (project groff):

Hi Branden,

Just a few thoughts really, I agree the registers are behaving as currently
documented, the question is whether the current behaviour makes sense.

Groff currently has no concept of opacity, gropdf allows pdfs included by
pdfpic to have objects which are not fully opaque, but that's as far as it
goes currently, so no, or null, colour can't mean transparent. Also, groff
uses the null string generally, to reset states to the previous value. So \m[]
resets stroke colour to its previous value. For these colour registers the
initial value is a null string but empirical testing shows this default colour
is black, in most cases but see below.

This is in contrast to other state variables where we document the default
value and the state variable reflects this, so the default pointsize is 10pt
and \n[.s] contains 10, the default font is Times-Roman and the initial value
of \n[.fn] is TR. Is there a reason why colour should be treated differently?

It could be argued that the default colour is in the purview of the output
driver, and in this case each device's tmac file should set the actual default
colour and document the choice in its man page. The odd man out is grotty
since the initial stroke/fill colours are probably set by the terminal
settings rather than groff, but you're more au-fait with terminal output. This
dichotomy is probably the reason for the copout about default colours in the
documentation without specifying what the actual colour would be. This may be
a strong argument for delegating the initial startup default colour to each
driver, rather than a one size fits all within groff.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64592>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/