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

[Ross Moore]

Hi Zdenek,

On 26 May 2020, at 9:31 am, Zdenek Wagner <zdenek.wagner at gmail.com<mailto:zdenek.wagner at gmail.com>> wrote:

út 26. 5. 2020 v 0:59 odesílatel Ross Moore <ross.moore at mq.edu.au<mailto:ross.moore at mq.edu.au>> napsal:
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

You’re absolutely correct, my mistake.
Certainly I meant 0% *transparency*, the opposite of what Phil was trying to do.
It was he who said   100% opacity (= 0% ink)  which is where the error lies.
Surely 100% ink = 100% opacity = 0% transparency,  as you say.


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<https://protect-au.mimecast.com/s/tuWYCBNqgBCvBNrAuzR3NV?domain=enfocus.com>

This is another topic. This addresses "black overprint" in printing.

Sure, but it is about knocking out the colour in the background.
Using black text is probably its most common usage.
But if you want the natural paper to come through, then surely this is the only way to do it conveniently.

Otherwise you would have to manually define regions outlining the letters, and make these
boundary curves for your background. Totally impractical.
PDF does this for you, if you have used the correct way to ask for it.


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.

Sure; I’d love to see these.
I’m sure that this would most closely approach what Phil seems to want to do.



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.

<Screen Shot 2020-05-26 at 8.38.02 am.png>

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.

Phil hasn’t said what is his application.

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
http://ttsm.icpf.cas.cz/team/wagner.shtml<https://protect-au.mimecast.com/s/TZFICD1vRkCX0ZzMs5cgKz?domain=ttsm.icpf.cas.cz>
http://icebearsoft.euweb.cz<https://protect-au.mimecast.com/s/4H07CE8wlRCBMj2nhptby5?domain=icebearsoft.euweb.cz>




Philip Taylor
<Demo.pdf><Demo.tex><Lighter ground.pdf>


Sorry for my error adding to confusion.

Cheers.
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<mailto:ross.moore at mq.edu.au>
http://www.maths.mq.edu.au
[cid:image001.png at 01D030BE.D37A46F0]
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/20200525/3ca15da4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4605 bytes
Desc: image001.png
URL: <https://tug.org/pipermail/xetex/attachments/20200525/3ca15da4/attachment-0001.png>