[XeTeX] \font "<platform font>":color=FFFFFF produces black, not white glyphs \font "<platform font>":color=FFFFFF produces black, not white glyphs, re-visited

Zdenek Wagner zdenek.wagner at gmail.com
Tue May 26 01:31:34 CEST 2020

út 26. 5. 2020 v 0:59 odesílatel Ross Moore <ross.moore at mq.edu.au> napsal:

> Hi Philip,
> On 25 May 2020, at 9:00 pm, Philip Taylor <P.Taylor at Hellenic-Institute.Uk>
> wrote:
> [UNIV: Plain XeTeX] —
> Way back in 2015, I asked :
> >* Could anyone explain why the continuum that exists from color=000000 to
> *>* color=FEFFFF, color=FFFEFF and color=FFFFFE breaks at color=FFFFFF ?
> *> >* To ensure 100% consistency between the proofing version of a book (which has
> *>* marginal notes in red to ensure that the proof-reader can unambiguously
> *>* identify the callouts for each image) and the CRC-ready version, I prefer
> *>* not to disable the marginal note mechanism, which /might/ lead to different
> *>* pagination (although tests suggest, but cannot prove, that it does not) but
> *>* instead to make the marginal notes invisible by changing their colour from
> *>* DF0000 to FFFFFF.
> *To which Khaled Hosny kindly replied :
> That is a bug in xdvipdfmx; FFFFFF will be converted by XeTeX to
> FFFFFFFF when written to the XDV, but xdvipdfmx uses the 0xFFFFFFFF
> value to mean that no color have been selected so ends up ignoring the
> color here. A work around is to set the color to FFFFFF00 (or any other
> value for the alpha since xdvipdfmx does not support transparency
> currently).
> and at the time, that appeared to solve my problem. However, it would
> appear that since then "xdvipdfmx" has been enhanced to support
> transparency, as a result of which Khaled's suggested FFFFFF00 no longer
> works (the text is invisible, see attached).  Could anyone tell me how,
> short of using \specials, I can achieve 100% white with 100% opacity (= 0%
> ink) in XeTeX ?
> I’m sorry, but this just doesn’t make any sense to me — but see further
> below.
> Surely 100% opacity means that the blend between background and foreground
> is 100% background, 0% foreground.
> Thus your text will be invisible, whatever colour has been specified; that
> this is white becomes irrelevant.
> The only way to get 100% white, over a coloured background, would be with
> 100% ink, so 0% opacity.
> Any other opacity level will allow some of the background colour to be
> mixed in.
> At least that is how I understand what colour mixing is all about.
> Sorry, correct me if my English is wrong but I would expect 100% ink =
100% opacity = 0% transparency

> However, there is another PDF parameter called “knockout”.
> See this link for an brief description of the issue:
> https://www.enfocus.com/en/products/pitstop-pro/pdf-editing/knockout-white-text-in-a-pdf

This is another topic. This addresses "black overprint" in printing. The
idea is that process colours are printed in the following order:
cyan-magenta-yellow-black. If you want to print a yellow text on a cyan
background, RIP must erase the cyan plate to white where the characters
will later appear on the yellow plate, otherwise the text would not be
yellow. If the offset films are not precisely adjusted, you will see colour
artifacts at the boarders of the characters. If you want to type a dark
text (usually black) to a light background, it can just be overprinted. In
order to make it work, both colours must be defined in CMYK (not RGB, not
grayscale). Professional Acrobat since version 9 contains a prepress
checking function which can verify whether overprint was really used. Black
overprint is implemented in my zwpagelayout package. It was tested in
xelatex, pdflatex, and latex + dvips. The package does not my test files.
If you like, I can send them.

> How to achieve knockout using TeX+gs or pdfTeX or XeTeX?
> I’m not at all sure. It must have a graphics state parameter.
> The next image shows what I think is the relevant portion of the PDF specs.
> There’s a whole section on “Transparency Groups”, but mostly it is about
> how different transparent objects
> must combine to produce the final colour where objects overlap.

Transparency should not be used for prepress. It works fine on office
printers but often come out as black on phototypesetters and CTP.

> After a cursory look, I think you need to use a Form X Object, which can
> be done in pdftex using the  \pdfxform  primitive,
> with appropriate attributes specified.
> For XeTeX you would need to be using  \special  commands.
> Someone here must have some experience with this.
Zdeněk Wagner

> Philip Taylor
> <Demo.pdf><Demo.tex><Lighter ground.pdf>
> Hope this helps.
> Stay safe.
> Ross
> Dr Ross Moore
> Department of Mathematics and Statistics
> 12 Wally’s Walk, Level 7, Room 734
> Macquarie University, NSW 2109, Australia
> T: +61 2 9850 8955  |  F: +61 2 9850 8114
> M:+61 407 288 255  |  E: ross.moore at mq.edu.au
> http://www.maths.mq.edu.au
> CRICOS Provider Number 00002J. Think before you print.
> Please consider the environment before printing this email.
> This message is intended for the addressee named and may
> contain confidential information. If you are not the intended
> recipient, please delete it and notify the sender. Views expressed
> in this message are those of the individual sender, and are not
> necessarily the views of Macquarie University. <http://mq.edu.au/>
> <http://mq.edu.au/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/xetex/attachments/20200526/90eee350/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2020-05-26 at 8.38.02 am.png
Type: image/png
Size: 384071 bytes
Desc: not available
URL: <https://tug.org/pipermail/xetex/attachments/20200526/90eee350/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4605 bytes
Desc: not available
URL: <https://tug.org/pipermail/xetex/attachments/20200526/90eee350/attachment-0003.png>

More information about the XeTeX mailing list.