groff
[Top][All Lists]
Advanced

[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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]