[XeTeX] Colour specials for XeTeX

[Zdenek Wagner]

po 8. 6. 2020 v 10:48 odesílatel Philip Taylor
<P.Taylor at hellenic-institute.uk> napsal:
>
>
>
> Hallo again Benct —
>
> > 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.
>
> Dijkstra was indeed a /very/ great theoretician, and I think that the
> IT world is a far poorer place not only for his passing but for the
> passing of the generation of computer scientists that he epitomised.
> Dijkstra, I think, saw computer programming purely as an intellectual
> exercise, one that did not require access to a physical computer in
> order to be practised — all one had to do was to write the program,
> prove that it was correct, and one's task was done. These days
> computer programming has become just a pragmatic exercise, which is
> one reason why now we have such a plethora of programming languages,
> libraries, implementations, etc., from which we are expected to make
> an informed choice.  And for those of my generation (I am now 73),
> this is simply an impossible task.  I have no idea what "react"
> is/does, why no two Unices are the same, why (in general) open braces
> no longer appear vertically above the brace that closes them, etc.
> The world has moved on, and I have been left behind.  But that does
> not prevent me from yearning for "the good old days", when /enormous/
> thought went into the specification of a new programming language, and
> when there was rigour where now there is chaos.  But I digress (also
> an artifact of old age).  My point is simply that there /must/ be a
> specification for something, otherwise that "something" is at best
> unreliable and at worst completely useless.  If I have a specification
> for (say) colour \specials, and (e.g.,) xdvipdfmx (2021 release) does
> not honour those specials in the same way that the 2020 release did,
> then I have a definitive document which will allow me to determine
> which (if either) is the correct/compliant behaviour, and which is the
> incorrect/deviant.  Without such a specification, then what works
> today may not work tomorrow, and no-one will be able to say whether
> this is evolutionary or retrograde.
>
I am probably a similar kind of man. I started to work with computers
at a time when I had to leave a pack of punch cards and wait a few
hours before the operators put it to the computer and gave me the
printed results. I could have two runs per day, if I was lucky, I
managed to have the program run three times a day. Under such
situation I could not afford to write a program that does not work at
the first attempt, even a misprint caused a loss of one day of work.
Thus I learnt to write what the program is supposed to do and then
make a program which worked. Nowadays everybody has a computer and I
am afraid that the programmers just write some code and then look for
bugs. I do not understand the significance of a debugger. Of course, I
tried it but I never used it. My programs work and if occasionally
something does not where, I know where to look for the reason without
trying a debugger. I talked with a man from a computer company, he is
slightly older than me. He told me that debugging is an expensive
process. He must earn money by programming, therefore he had to learn
how to write programs that work without the need of debugging. This
means that I always have a description of a program but it does not
mean that it can serve as a user manual. And it does not mean that I
have it in a separate document. I can have it in the source code in
comments written in a human language, usually in English, sometimes in
Czech. And for this reason I like perl because POD can extract these
comments into a user manual and it does not require additional work
from me.

The request of supporting dvips specials in xdvipdfmx is not very
fair. PDF is modelled after PostScript but not the same. PostScript is
a linear language, PDF lacks programming structures but makes use of
streams, even indirect streams and indirect objects. PostScript has
one current colours, PDF has two current colours, one for fill,
another for stroke. PostScript can directly set both the colour and
the colour model by setgray, setrgbcolor, setcmykcolor or first change
the model and then set the colour by setcolor the number of parameters
of which depend on the current colour model, while PDF needs k and K
for CMYK, rg and RG for RGB, g and G for greyscale. The colour stach
is neither a feature of PostScript nor PDF, they are implemented in
the driver. It is more difficult in PDF, it is more likely to destroy
something, thus I understand that it is not implemented the same way
as in dvips. Correspondence between PostScript and PDF is not 1:1
hence the drivers must convert the same TeX specials in a very
different way to the target language.
> >
> > [snip]
> >
> > I doubt that any one implementation used in 2020 is from 1992, and
> > each new implementation may bring with it new difficulties.
>
> Yes, it may.  But if we have a specification (even one dated 1992), we
> can definitively know and state whether each new implementation is
> compliant or abberant.  This must, surely, be a Good Thing [tm], must
> it not ?
>
> ** Phil.


Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz