\documentclass{article}

\usepackage{shortvrb}

\MakeShortVerb{\|}

\begin{document}

\title{Some thoughts on colour support in \TeX}
\author{David Carlisle}
\date{1994/02/16}

\maketitle

\section{The Problem}

\TeX\ does not have primitive support for colour, so the amount of
support possible depends on the dvi driver being used.

Roughly this may be split into `levels' of support. Depending on the
circumstances, a TeX style aimed for a driver at one level may want to
emulate the features of a higher level driver, or flag errors.

For instance for a monochrome device, sometimes it makes sense to
silently ignore colour commands (typically if this is just a `preview'),
but sometimes a user would want to be informed that the \TeX\ file
(perhaps prepared at another site) asks for colour. 

\begin{description}
\item[level 0]
 Monochrome driver
\item[level 1]  
 Support for setting the current colour at a certain point in the dvi
 file. 

 Essentially all PostScript drivers have at least this level of
 support. However it is impossible to guarantee colour is correctly
 handled across page breaks, or after floating bodies such as figures.

\item[level 2] 
 The driver maintains an internal colour stack and maintains this stack
 across page breaks. (Rokicki's dvips) 

 At this level it is possible to correctly deal with `non-split
 insertions' such as figures and tables. However if there is only one
 stack maintained, then only one `text galley' may correctly support
 colour. For LaTeX there are two such areas of the page that may be
 split. The main text, and footnotes. If a footnote containing a colour
 command is split with a driver at this level, that footnote and the
 whole of the following page may get incorrect colours.

\item[level 3]
 The driver supports more colour stacks, or a more general register
 mechanism out of which such a series of stacks could be implemented.

 Future versions of dvips may support this. 
\end{description}


\section{Page Boundaries}
For any of the above levels, supporting colour across page
boundaries comes in various flavours.
 \begin{itemize}
 \item Support works as long as no post-processor re-arranges the pages.
 \item  Support works as long as any page re-arrangement happens *after*
   the driver. PS drivers at level 2 or 3 can should support this, so
   PS utilities may be used to select or re-arrange pages for
   printing.
 \item Support works even if pages are re-arranged by a dvi->dvi
    program. 
   I do not see how this can be made completely robust using \TeX.
   In order to allow any kind of dvi-dvi page rearranging, the output
   routine would need to have much greater colour `awareness'. It would
   be possible to implement a scheme using marks to initialise the
   colours on each page, but it would need a general mechanism of using
   `typed' marks, so that the use of marks for more usual uses, such as
   head lines, does not interfere with the color commands.
 \end{itemize}
`lack of support' in this context may for example mean that a request
for blue text at the beginning of a document results in the whole
document being printed blue. However if just a few pages, not starting
with page 1, are printed, then the colour request is `lost' and the
pages come out black. This should be contrasted with a font selection
where a request such as |\bf| results in bold fonts being explicitly
specified in all subsequent parts of the dvi file, so that any part of
the document may be printed bold on any driver that supports page
selection. 



\section{Changes to existing formats required to support colour}

The main changes relate to the wish to support the |{\rm   }| syntax for
colour commands. This requires a certain amount of |\aftergroup|
trickery. |\aftergroup| works as expected as long as it is working on
the right group. Certain \TeX\ primitives, have implicit groups, which
are not the `right group' in this context. (If you are bothering to
read this section you know why:-). principally the bad commands are:

|\halign \valign \setbox \insert|

In a context where the argument is not under the control of the
macro, but rather random user-supplied input, extra grouping will
need to be added so that the |\aftergroup| tokens turn up at the right
place. Furthermore, any such uses that cause the `saved text' to be
used later, after some user supplied text, will require the saved
text to be saved with an explicit color setting, noting the color at
the time of the save.

\LaTeXe\ has these `extra groups' added at (most of) the required
points, and executes |\set@color| whenever it is saving a box that may
be used later. |\set@color| is initially defined to do nothing, but a
colour package may redefine it to preserve the current colour (in a
|\special|) within the box being saved.


\section{`Named' Colours}

rgb or cmyk specifications do not refer to a `colour' so much as
instructions on how to generate a colour. By definition the colours
generated by the same rgb specification on two devices may be look
different. So if a particular colour in a dvi file is defined by a rgb
or cmyk specification different colour processes will produce
different colours.

However if the dvi file asks for `pantone xyz' then the driver is
supposed to produce that colour exactly (eg in a professional print
run, it might use ink of the specified colour, rather than mixing the
primary colours to achieve the effect. Similarly although the named
colours in dvips' color.pro are specified by cmyk, the users are
supposed tune the exact numbers relating to each colour. So if a site
has two colour printers with different characteristics, by having a
color.pro set up for each printer, the same dvi file produces similar
results on the two printers. However a dvi file containing explicit
cmyk specials will produce diferent colours on the two printers.

note that in this section the user syntax is not the issue, the
question is whether the dvi file contains
|\special{blue}| or |\special{0 0 1}|.


\section{\LaTeX\ User interface for colour}

\subsection{Defining Colours}


|\definecolor{mygreen}{rgb}{.1 1 0}|

The second argument determines the colour model model. The syntax of
the third argument depends on the model, but is typically, for
numeric colour models, a comma separated list of numbers between 0
and 1.

\subsection{Using Colours}

\noindent|{\color{Blue} blue text}|\\
|{\color[rgb]{0, 1, 0} green text}|

Note that spaces are ignored after |\color{Blue}|.

The default form access a predeclared colour which must have been
defined previously with the |\definecolor| command. If given an optional
argument, then it specifies the colour model used in the
specification in the mandatory argument. this colour need not have
been pre-defined.

\noindent|\textcolor{Blue}{blue text}|\\
|\textcolor[gray]{0.7}{grey text}|

Just syntactic sugar for |{\color...}|.

The `named' colour model may support any colours known to the
driver, eg dvips' color.pro cmyk settings, or `pantone' named colors
or ... There is also be a way for a user to allocate a name to
(eg) an rgb colour. The driver may choose to give these named models
names like `pantone' or `crayola' rather than `named'.

\noindent|\definecolor[rgb]{mygreen}{.1, .9, 0}|\\
\vdots\\
|{\color{mygreen} mygreen text}|

\subsection{Page colours}
|\pagecolor| Takes the same arguments as |\color| but globally sets
the background colour. 

\section{The internal interface to the colour driver files}

Any file that interfaces the user-level commands to low level
|\special|'s should define the following commands. They should
\emph{not} rely on the above LaTeX interface. Other packages may choose
to offer a different top level syntax (e.g.\ without any optional
arguments).

|\set@color| should 
\begin{itemize}
\item add a |\special| to set the color defined by |\current@color|.
\item launch an |\aftergroup\reset@color|.
\end{itemize}

Note that \LaTeX2e\ kernel calls |\set@color| at the start of saved
boxes, although the default definition is |\relax|.

|\reset@color| should 
\begin{itemize}
\item pop the colour stack.
\item ideally, this just sends a colour pop to a driver maintained
  stack.  
\item otherwise \TeX's save stack has to make do as the colour stack, in
  which case |\reset@color| should just set the current colour to the
  colour specified by |\curent@color|.
\end{itemize}


|\current@color| This should be initialsed by the driver file to the
internal representation for `black'.

For each `colour model' the driver file supports, the file should
define: 

|\color@|\emph{model}   (eg |\def\color@rgb#1{...}| )

This should take one argument, a \emph{colour specification} and:
\begin{itemize}
\item define |\current@color| to be an internal representation
  of the current colour (as used by the |\special| command)
\item call |\set@color|.
\end{itemize}


|\definecolor@|\emph{model}  (eg |\def\definecolor@rgb#1#2{...}| )

This should take two arguments record the `user' level \emph{name} |#1|
as being the colour specified by the argument |#2| in the model
\emph{model}. 
The command |\\color@|\emph{name} should be defined to expand to a call
to a normal colour model. If the arguments to the color commands are
checked, then the checking may be done at the time of definition, in
which case |\\color@|\emph{name} may expand to an `unchecked' version of
the color command, so the color is not re-checked every time it is used.

eg |\definecolor{myblue}{rgb}{0, 0, 1}| should either
define |\\color@myblue| to be 
|\color@rgb{0, 0, 1}|
or, if that would cause the argument to be checked every time,
|\color@rgb@{0, 0 ,1}|
where the |rgb@| model does no checking.

It is up to the driver file whether the validity of the arguments is
checked, or whether they are passed straight on to the driver.



\end{document}