Re: [Groff] inconsistencies with color specification

[Werner LEMBERG]

> > Given the spaces in `mr000011112222' should be optional, as you
> > said above, why does it need terminating by whitespace since the
> > endpoint is always known, i.e. `mr000011112222thello' has only one
> > parse tree.
>
> Basically, you are right, but the default -1 is hurting, so the
> argument has a variable length.
> 
> Maybe it would be a good idea, to define a different subcommand letter
> (e.g. d or the digit 0) for setting the default.  
> 
> Then it would be possible to split the color argument into several
> arguments, each representing a color part with a fixed lenght of 4.
> This would not change the look and feel, but would be cleaner in the
> parser.

To be really conformant with the troff output format, the following
would be ideal:

  m r red green blue
  m k cyan magenta yellow black
  m c cyan magenta yellow
  m g gray
  m d

The color components are always decimal values, simplifying parsing.

The question is whether we want that (at least I don't oppose --
nobody really reads that format).

> Werner, I think I could do the groff_out programming in
> libdriver/input.cc, but not the troff and postprocessor parts.

Thanks for the offer, but I'm already in the process of changing it,
and I need the parsing stuff also for testing.


    Werner