[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Groff] inconsistencies with color specification
From: |
Werner LEMBERG |
Subject: |
Re: [Groff] inconsistencies with color specification |
Date: |
Sun, 21 Oct 2001 20:37:38 +0200 (CEST) |
> > > So someone has to find a simpler solution. Is there a
> > > reasonable appromixation with linear optimization?
> >
> > Though I haven't researched them, I believe the patents to be
> > quite broad.
>
> I posted a few days ago about how X11R6's Xcms library, typically
> part of Xlib.a, has conversions between RGB, CMY, and CMYK IIRC.
> Some of those were non-linear using pre-computed lookup tables.
Dear friends,
the discussion on colours shows that it is a quite complicated topic.
Since I want to have simple code in groff, I plan to revise the
current colour implementation as follows.
. troff commands stay identical: .defcolor, \m, and \M. New: A
predefined (background/foreground) colour called `default' which
is driver specific. This colour can't be redefined. I need
default colours for proper TTY support which can have a reverse
mode, i.e. switched background and foreground colours.
. 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.
As you can see, I want to shift the responsibility for colour
handling from troff to the output driver. If a colour is defined
in CMYK, troff's intermediate output format uses the `m k'
command, and the output driver has to decide what to do with it.
The colour conversion routines in colour.cc will no longer be used
by troff. They will be provided for the driver so that a colour
can be converted to a supported colour model. I think that the
current conversion algorithms are sufficient, given that groff
doesn't manipulate colours of graphics but only coloured text and
background.
By default, troff will use the RGB colour definitions in the
various colour*.tmac files. If a document needs CMYK values, it
should load a customized colour definition file, redefining the
RGB colour definitions with CMYK ones.
Please comment.
Werner
Re: [Groff] inconsistencies with color specification, Bernd Warken, 2001/10/19
- Re: [Groff] inconsistencies with color specification, Stewart C. Russell, 2001/10/19
- Re: [Groff] inconsistencies with color specification, Ralph Corderoy, 2001/10/19
- Re: [Groff] inconsistencies with color specification,
Werner LEMBERG <=
- Re: [Groff] inconsistencies with color specification, Bernd Warken, 2001/10/21
- Re: [Groff] inconsistencies with color specification, Ralph Corderoy, 2001/10/23
- Re: [Groff] inconsistencies with color specification, Bernd Warken, 2001/10/23
- Re: [Groff] inconsistencies with color specification, Werner LEMBERG, 2001/10/26
- Re: [Groff] inconsistencies with color specification, Ralph Corderoy, 2001/10/27
- Re: [Groff] inconsistencies with color specification, Werner LEMBERG, 2001/10/27
- Re: [Groff] inconsistencies with color specification, Bernd Warken, 2001/10/27
Re: [Groff] inconsistencies with color specification, Bernd Warken, 2001/10/27
Re: [Groff] inconsistencies with color specification, Bernd Warken, 2001/10/27
Re: [Groff] inconsistencies with color specification, Ralph Corderoy, 2001/10/27