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

Olaf Weber olaf at infovore.xs4all.nl
Sun Aug 29 20:48:03 CEST 2004


John Hobby writes:

> B. I have no objection to upgrading dvitomp to handle any
>    reasonably-standardized set of specials (including color
>    specials), as long as I don't have to do the work.  I thought
>    special-handling was a frighteningly open-ended feature, but
>    perhaps that isn't so true any more.

The specials used in practice tend to be limited to a few well-known
sets.  I do see some value in making the various programs understand
the same set of specials (where applicable).

> C. I am somewhat concerned about version control.  Are we using .ch
>    files to implement things that belong in dvitomp.web or mp.web?
>    If a feature is not system dependent and is or should be
>    implemented in everyone's version, then it should be in the main
>    sources and the main version number should be increased.

> D. There is no prohibition against people other than me touching
>    dvitomp.web and mp.web.  I just hope any such changes could be
>    done with reasonable regard for version control.

The common pattern with TeX distributions is that they keep the web
files intact, and put any changes, including extensions, in the change
files.  This even for cases where there is no license prohibiting
modification of the web files themselves.  The effect is that I am the
"gatekeeper" for the web2c change files, the MikTeX maintainers are
the gatekeepers for the MikTeX change files, and you are -- by default
-- still the gatekeeper for mp.web and dvitomp.web.

The alternative becomes that different dvitomp.web versions start
popping up because some changes were made for web2c, others for
MikTeX, and so on.  That situation isn't particularly desirable
either.

In practice, a certain amount of cross-pollination occurs between
MikTeX and Web2C at least.

Now, assuming a desire on you part not to be bothered by these things
anymore, it would make sense to look for a new gatekeeper for mp.web
and its supporting software.  (I do see continued value in having a
set of "canonical" sources that each distribution can work from.)
(Please note that I'm not saying that you should be responsible for
finding a new gatekeeper.  My preference would probably be something
like having a MetaPost+mpware maintainers group under TUG's auspices.)

A side note: string handling in the Pascal dialect used in the web
files is rather painful.  The change files, being web2c-specific can
use convenient shortcuts.

Another side note: trying out extensions in the change files before
folding them into the main distribution may be the preferred way of
working, especially if there may be a numer of quick revisions of the
code.

Final side note: for web2c all this means that the web2c version
number is more relevant to a program's identity than the version
number in the web source.  It is also why any problem with programs in
web2c should be reported to tex-k before contacting the autor of the
web source.  Which I hope the help messages and other documentation
make clear.

(Ugh, this post became much too long.  I'll shut up now.)

-- 
Olaf Weber

               (This space left blank for technical reasons.)



More information about the tex-k mailing list