Re: [Groff] inconsistencies with color specification

[Bernd Warken]

On Tue, Oct 23, 2001 at 06:47:56PM +0100, Ralph Corderoy wrote:
> 
> 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.

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


################

> > To be smarter on the postprocessor input, the default color should be
> > actived if the last argument contains any character that is not a hex
> > digit or if the length of the argument does not suit. Nevertheless
> > grtoff should always output -1 for this case.
> 
> That seems to open up ambiguities.
> 
>     m r 0000111x2222    is the still 2222 consumed even though
>                         `default' is returned?
> 
> Sticking with `-1' allows everything else to be an error highlighting
> any problems ASAP instead of fishing around with the final output later
> wondering why some colour change is wrong.
> 
You are right.


Bernd Warken