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/