<div dir="auto"><div data-smartmail="gmail_signature" dir="auto"><br></div><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">Den sön 7 juni 2020 21:34Philip Taylor <<a href="mailto:P.Taylor@hellenic-institute.uk">P.Taylor@hellenic-institute.uk</a>> skrev:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
BPJ wrote:<br>
<br>
> Well as everything in a computer program they are defined in the source code.<br>
<br>
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.<br></blockquote></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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</div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> 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.<br>
<br>
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.  </blockquote></div><div dir="auto"><br></div><div dir="auto">I doubt that any one implementation used in 2020 is from 1992, and each new implementation may bring with it new difficulties.</div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 :<br></blockquote></div><div dir="auto"><br></div><div dir="auto">Good! I hope the current implementation lives up to the spec!</div><div dir="auto"><br></div><div dir="auto">/bpj</div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> 7.6 Color support details<br>
> To support color, Dvips recognizes a certain set of specials. These specials start with the<br>
> keyword ‘color’ or the keyword ‘background’, followed by a color specification.<br>
><br>
> 7.6.1 Color specifications [...]<br>
><br>
> 7.6.2 Color specials<br>
> We will describe ‘background’ first, since it is the simplest. The ‘background’ keyword<br>
> must be followed by a color specification. That color specification is used as a fill color for<br>
> the background. The last ‘background’ special on a page is the one that gets issued, and<br>
> it gets issued at the very beginning of the page, before any text or specials are sent. (This<br>
> is possible because the prescan phase of Dvips notices all of the color specials so that the<br>
> appropriate information can be written out during the second phase.)<br>
><br>
> The ‘color’ special itself has three forms. The first is just ‘color’ followed by a color<br>
> specification. In this case, the current global color is set to that color; the color stack must<br>
> be empty when such a command is executed.<br>
><br>
> The second form is ‘color push’ followed by a color specification. This saves the current<br>
> color on the color stack and sets the color to be that given by the color specification. This<br>
> is the most common way to set a color.<br>
><br>
> The final version of the ‘color’ special is just ‘color pop’, with no color specification;<br>
> this says to pop the color last pushed on the color stack from the color stack and set the<br>
> current color to be that color.<br>
<br>
It would therefore seem that [x]dvipdfm[x] supports (at least) the same set of colour \specials as did/does Tom Rokicki's "DVIPS"<br>
and thus the documentation for the latter can serve as reference for the former.<br>
<br>
/Philip Taylor/<br>
<br>
</blockquote></div></div>