[XeTeX] Colour specials for XeTeX

[BPJ]

Den sön 7 juni 2020 21:34Philip Taylor <P.Taylor at hellenic-institute.uk>
skrev:

>
>
> BPJ wrote:
>
> > Well as everything in a computer program they are defined in the source
> code.
>
> That is the very antithesis of Dijkstra's position on the subject, and I
> strongly agree with him !  The behaviour / syntax / semantics are described
> outside of the program — the program is merely one of many possible
> realisations of the desired behaviour.
>

Dijkstra was a great theoretician, and in principle it is of course right
that the spec/documentation should dictate the behavior, but as we all know
there is usually, for practical reasons, more or less distance between
theory and practice, and in practice a piece of software does what the code
tells it to do, no more no less.  Personally I hate it when the
spec/documentation describes some feature only to be told that it is "not
(yet) implemented", yet partial or divergent implementations are quite
common, and at the end of the day a partial implementation is usually
better than no implementation at all. I am myself involved in a project
which has several implementations for different languages and it is very
hard to keep them all in synch, not least because the different
implementations depend on different libraries which dictate how and if
things can be done more or less easily. In practice one implementation is
ahead of the other two while another is more or less stalled. No fun but a
fact of life, especially in a volunteer project where time is limited.

In my daytime work as a documentation writer/translator (since comparative
philology jobs are short in supply so that I must take whatever job needs a
polyglot :-) it is rather the rule that the documentation lags behind the
implementation than the other way around, not least because documentation
writers depend on information relayed from designers and/or developers,
which often is of let's say differing quality. I'm usually faced with notes
in what amounts to a mixture of Swedish/Danish and English jargon which I
have to iron/flesh out to something users will understand. With volunteer
projects documentation is of course usually written by the developers
themselves and documentation may lag behind implementation because writing
documentation is seen as hard and/or time consuming


> > It is not the first time some feature of a computer program is
> insufficiently or not at all documented, and probably not the last time
> either. It is certainly disappointing when you for whatever reason can't
> figure them out from looking at the source code, but it is also good to
> keep in mind that the reason some feature is undocumented often is that the
> developers consider the feature unreliable. The code may be retained either
> because the developers hope to fix it if and when they figure out how to do
> it, or because removing it may cause other things to break, so there may be
> "good" reasons if you can't get them to work as intended or expected. I
> sincerely hope you find a workaround.
>
> Well, the set of colour \specials in which I am interested appear to have
> been existence since 1992 or earlier, so if they /were/ unreliable one
> might think that that would have been noted and reported by now.


I doubt that any one implementation used in 2020 is from 1992, and each new
implementation may bring with it new difficulties.

But I am delighted to say that having searched the online TUGboar archive,
> I was able to track down some of the earlier discussion of this set of
> specials, especially in articles written by Thomas Hafner, and these in
> turn led me to investigate the documentation for Tom Rokicki's "DVIPS"
> program ('TeXdoc dvips'), in which, to my great joy, I was able to read :
>

Good! I hope the current implementation lives up to the spec!

/bpj


> > 7.6 Color support details
> > To support color, Dvips recognizes a certain set of specials. These
> specials start with the
> > keyword ‘color’ or the keyword ‘background’, followed by a color
> specification.
> >
> > 7.6.1 Color specifications [...]
> >
> > 7.6.2 Color specials
> > We will describe ‘background’ first, since it is the simplest. The
> ‘background’ keyword
> > must be followed by a color specification. That color specification is
> used as a fill color for
> > the background. The last ‘background’ special on a page is the one that
> gets issued, and
> > it gets issued at the very beginning of the page, before any text or
> specials are sent. (This
> > is possible because the prescan phase of Dvips notices all of the color
> specials so that the
> > appropriate information can be written out during the second phase.)
> >
> > The ‘color’ special itself has three forms. The first is just ‘color’
> followed by a color
> > specification. In this case, the current global color is set to that
> color; the color stack must
> > be empty when such a command is executed.
> >
> > The second form is ‘color push’ followed by a color specification. This
> saves the current
> > color on the color stack and sets the color to be that given by the
> color specification. This
> > is the most common way to set a color.
> >
> > The final version of the ‘color’ special is just ‘color pop’, with no
> color specification;
> > this says to pop the color last pushed on the color stack from the color
> stack and set the
> > current color to be that color.
>
> It would therefore seem that [x]dvipdfm[x] supports (at least) the same
> set of colour \specials as did/does Tom Rokicki's "DVIPS"
> and thus the documentation for the latter can serve as reference for the
> former.
>
> /Philip Taylor/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/xetex/attachments/20200608/262857fc/attachment.html>