Re: [Groff] inconsistencies with color specification

[Ralph Corderoy]

Hi Bernd,

> On Sun, Oct 21, 2001 at 08:37:38PM +0200, Werner LEMBERG wrote:
> >   . New troff output format:
> > 
> >       for RGB:        m r rrrrggggbbbb
> >       for CMY:        m c ccccmmmmyyyy
> >       for CMYK:       m k ccccmmmmyyyykkkk
> >       for GRAY:       m g gggg
> >       default colour: m r|c|k|g -1
> > 
> >     The same with DF -- Both m and DF have exactly two arguments,
> >     simplifying the parsing process.  Additionally, the leading
> >     `##' are gone since they are redundant.  Only hex values in the
> >     range 0-0xFFFF are used.
>
> This is a good idea.

I agree.

> To stay in-line with the handling of white space in the intermediate
> output format, the following could be helpful:
> 
> - The space between the command, the subcommand, and the argument is
> optional because the command letters have a fixed length.
> 
> - The m command must either be terminated by a space or tab or
> newline character just like the t command.

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.

This isn't a complaint, I'm just trying to learn more about the reason
behind the groff_out extensions.

> 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.

Cheers,


Ralph.