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

Hartmut Henkel hartmut_henkel at gmx.de
Sat Aug 28 12:39:32 CEST 2004

Hi Eddie,

On Fri, 27 Aug 2004, Eddie Kohler wrote:

> They would say "btex \Lavender{Hello} etex", with colordvi;

sure, i tried the low-level interface only to see how it works.

> or "btex \textcolor{Lavender}{Hello} etex", with the color package.

...after your patch. Tried it, works ok, thanks a lot!

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

Yes, like Green = red; my eyes have this problem :-)

> The "Crayola colors" in colordvi.sty and color.pro are interesting
> *precisely because* they have stable meanings and are interoperable.

Ok, if one finds a way to extend this palette through dvitomp...

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

Hope so, too.

> > Hope you like the modification to your patch. What do you think?
> I'm not sure I like it...
> ...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.

I would have thrown this into some colors.mp, as you also mention below.

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

Yes, metapost as such gives you the freedom of doing "any" color you
like, so this should be true for subsidiary things like btex..etex

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

When the patch is extensible without getting incompatible, no hurry.

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

I'm still more in this color.mp mood than hardcoding things. But i see
that having these definitions in the dvitomp source gives a friendly
behavior for the casual user. And i don't know a better automatic place.

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

Interesting case, but they could do this in metapost. The LaTeX and the
MetaPost user are normally the same person. And as there is no way of
getting colors defined inside btex...etex sections out so that they can
be used by metapost, it might be better to do color definitions in
metapost in the first place.

> (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?

In total, agreed. It's then adding the xalloc/free for the names,
push/pop them also and use them instead of black with warning, if colors
don't match.

Best Regards


More information about the tex-k mailing list