comment #12:

> If no one objects to my proposed change in comment #10, please set this ticket's status to "Confirmed" and I'll take care of it.
>
> Or someone else can.  It's a one-liner!  But I don't know what mom(7) will need to do.

Nothing.  Starting with the 2.6 release, mom explicitly calls '.gcolor default' whenever a color argument is not given to macros that optionally take one.

After the change I ran the code in comment #1 and now the second line works fine (the first line will never work properly because we don't stack colour changes).

Interestingly the call to \m[\*[curcol]] where curcol contains the word "default", causes groff to emit "mr 0 0 0". Tested on pdf, ps, dvi, html and utf8 devices, so I would be happy with this fix to the problem.

We could certainly change the `default_color` object to give it a non-empty name.  It doesn't seem like it should be a problem; the default color already can't be redefined, so it's okay if it means different things for stroke and fill.

There is also no way AFAIK to query the formatter with respect to how a color is defined in practice.  (One can of course inspect device-independent output from a document that draws using the stroke or fill colors.)

We might need to coordinate such a change with Peter Schaffter, since mom(7) got bitten by bug #64421 and had to work around it.

comment #6:

> See comment #3 which mentions two registers which reflect the default value.

I apologize for being dense, but I don't see in comment #3 (or any other comments) what registers contain the default colors.  In comment #1, Branden mentions the color named "default" but also says "I don't know that we have access via the roff language to what that default is."  Comment #3 mentions two other registers that are initially populated with default values (.fn for font and .s for type size), hence my trying to clarify whether the objection this bug is raising is (1) that .m and .M are "odd men out" in not being populated with default values, or (2) that no other mechanism exists to retrieve the default colors.

I make the distinction because (2) can be solved in a way that doesn't break compatibility.  (I don't know if this particular aspect of compatibility is important to anyone.  But some users might use the existing behavior, for example to test whether any colors changes have yet been made in a document.)  But your example in the original submission might be trying to show that the .m/.M behavior also complicates certain aspects of color handling, meaning (1) is the root problem.

Is the problem that registers .m and .M don't behave like other registers (containing the default values), or that the roff language offers no way to retrieve these defaults?

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.

Hi Deri,

I was able to confirm the initial emptiness of these registers at formatter startup.

The registers seem to be behaving as documented.

    \n[.m]         Stroke color (string‐valued); see .gcolor and \m.
                   Empty if the stroke color is the default.
    \n[.M]         Fill color (string‐valued); see .fcolor and \M.
                   Empty if the fill color is the default.

Also, there is a color named "default".

   Each output device has a color named 'default', which cannot be
redefined.  A device's default stroke and fill colors are not
necessarily the same.  For the 'dvi', 'html', 'pdf', 'ps', and 'xhtml'
output devices, GNU 'troff' automatically loads a macro file defining
many color names at startup.  By the same mechanism, the devices
supported by 'grotty' recognize the eight standard ISO 6429/EMCA-48
color names.(1)  (*note Colors-Footnote-1::)

I don't know that we have access via the roff language to what that default is.

I also don't know if we can just assume that the default stroke and fill colors are black, though it seems likely to me that that's extremely common.

What is your use case?