[tex-k] dvitomp update: support \Black, \Red, and similar colordvi commands

[Eddie Kohler]

Hartmut Henkel wrote:
> Hi Eddie,
> 
> by accident I stumbled over your patch (in the teTeX-beta-2.96.7
> distribution), which provides a colorstack to dvitomp. It's a funny and
> quite useful feature. Just to re-iterate, one can say "btex
> \special{color push Lavender}Hello\special{color pop} etex" and gets a
> colored text, since dvitomp writes out an .mpx file containing
> "withcolor R G B" strings. It's also compatible with colordvi.sty.

Right.  The point is that it's compatible with colordvi.sty and color.sty, which 
are supported by dvips et al.  No one would actually say "btex \special{color 
push Lavender}Hello\special{color pop} etex".  They would say "btex 
\Lavender{Hello} etex", with colordvi; or "btex \textcolor{Lavender}{Hello} 
etex", with the color package.


> While checking what your patch does (seems one needs to read the source
> code to understand what's going on, as I couldn't find other
> documentation), it appears that you have hardcoded 67 RGB colors into
> the source code of dvitomp, like:
> 
> 
>>def_named_color('Cerulean', 0.0600122, 0.889988, 1.0);
> 
> 
> IMHO special things like colors with RGB values should be under user
> control (e. g. if one wants to extend the color list), and are misplaced
> in program sourcecode. They should instead end up in some separate
> driver or data file (as done by dvips). Also I could not find a way how
> one could extend the set of colors in dvitomp other than adding to the
> source and recompiling. In particular, it seems not to be possible to
> define a new color in metapost so that it gets accessible within
> btex...etex, vice versa.

I think you're wrong here.  The dvips color.pro file would hypothetically let 
users override the color definitions in colordvi.sty.  But no one has ever done 
that in the history of the world, I bet.  The "Crayola colors" in colordvi.sty 
and color.pro are interesting *precisely because* they have stable meanings and 
are interoperable.


> The whole mechanism seems to be built to be compatible with the ancient
> LaTeX 2.09 file colordvi.sty. Which is IMHO fixating an obsolete thing
> (if this colordvi.sty is senseful for nowadays applications, it should
> be updated to the newest LaTeX version, e. g. namespace reserved for
> these specials).

The named colordvi specials are also used by \usepackage[usenamed]{color}, which 
*is* up to date.  My next mail will contain a simple patch to dvitomp.ch that 
accepts colors from \usepackage[usenamed]{color}.  (Thanks for prodding me to do 
this!)  Hopefully that patch can get in to the next web2c and teTeX beta.


> While playing with dvitomp, I found that your color stack seems to work
> equally well, if the colors are handled only by name and not by their
> RGB values. The conversion between names and RGB values seems not needed
> in dvitomp as it can be left to metapost. E. g. you could define a color
> in the metapost source, then access this color in a btex...etex section,
> and finally metapost replaces the name given to it by dvitomp with the
> RGB value. Then I tried a raw patch, where I threw out any dependency on
> color names and RGB values from dvitomp. You find a dvitomp.ch version
> compatible with the current teTeX-beta-2.96.7 dvitomp.ch file at
> 
> http://www.circuitwizard.de/misc/dvitomp.ch.new
> 
> and a test file:
> 
> http://www.circuitwizard.de/misc/xx.mp
> 
> The patch allows to define any RGB color in metapost, and these are then
> accessible in the btex...etex sections by your \special{color push NAME}
> mechanism. It's still compatible with colordvi.sty, you only need to
> define the colors (e. g. "Red = red;") in metapost to make them
> accessible. BTW the source code actually got a lot simpler, as any R G B
> stack operations vanished. And the color list has gone. The changes were
> more or less just throwing things out.
> 
> Hope you like the modification to your patch. What do you think?

I'm not sure I like it.  When I say, in LaTeX,

    \documentclass...
    \usepackage[usenamed]{color}
    \begin{document}
    \textcolor{Red}{This is red!}
    \end{document}

I get red text.  So, when I say, in MetaPost,

    verbatimtex %&latex
    \documentclass...
    \usepackage[usenamed]{color}
    \begin{document}
    etex;
    ... in a beginfig ...
       btex \textcolor{Red}{This is red!} etex

I should get red text.  I don't like the extra step of saying "color Red; Red = 
red;", which is unnecessary in latex/dvips.

But you're right that my patch, as is, doesn't allow for user-defined colors. 
So how can we support user-defined colors?


(1) Dvips already supports specials for user-defined colors.  Rather than "color 
push Red", you can say "color push rgb 1 0 0.5" and such, or "color push cmyk 1 
0 0 1".  The current LaTeX "color" package supports defining new colors this 
way:  \definecolor{COLORNAME}{rgb}{1,0,0.5}, for example.

The dvitomp.ch patch should parse these specials as well as the named specials. 
  Then people could keep using the existing color package, and there would be no 
surprises.  I didn't do this parsing because it was more Pascal programming than 
I wanted to tackle at the time. :(


(2) Alternatively, web2c could use a version of your patch instead of mine. 
We'd also need a 'color.mp' include file that defined the existing Crayola 
colors.  Users would have to include 'color.mp' in their Metapost source, as 
well as the '\usepackage{color}' in the embedded TeX/LaTeX.  Not a huge deal, 
but one more thing you have to remember.  And users who wanted to use the 
existing \definecolor syntax would be left out in the cold.  You'd sort of be 
forking the "color language".


(3) Perhaps a mixed approach is best.  dvitomp would parse the existing color 
names, but if it saw an unknown color name, it would pass it through unchanged, 
as in your patch.  It would also parse "rgb" specials.


I think (3) is the best way to go.  What do you think?

Eddie