On 26/05/2020 23:32, Ross Moore wrote:
Hi Phil,
On 26 May 2020, at 5:12 pm, Philip Taylor
<p.tay...@hellenic-institute.uk
<mailto:p.tay...@hellenic-institute.uk>> wrote:
Ross Moore wrote:
I’m sorry, but this just doesn’t make any sense to me — but see
further below.
No, the fourth couplet is TT, where T is "Transparency".
Unfortunately , it is a misnomer, since 00 = completely transparent
and FE is almost opaque, which is why I spoke of "opacity" rather
than transparency. Unfortunately FF is /not/ opaque when preceded by
FFFFFF, because the driver treats FFFFFF [FF] specially.
As I said, it didn’t make sense to me. :-)
Thanks for the clarification, and sorry for my added noise.
First it is important to realise that both flattening and conversion
to CMKY will take place (the document is for digital printing). When
flattening takes place, RGB FFFFFF text will completely obscure the
ground, and after conversion to CMYK there will then be no ink where
the text occurs. Unfortunately as things are at the moment, there
will be 1/256 bleed-through of the ground because the RGB white was
not perfectly opaque.
"knockout", tho' interesting, should not be needed. The example
earlier sent shews that one can get very close to 100% white (and of
course there are no white inks involved) but not to 100% and this is
what I would like to achieve (and which should, IMHO, be
achievable). Were it not for the fact that the driver treats FFFFFF
and FFFFFFFF specially, there would be no problem at all in achieving
my aim.
It looks like Akira has done what you wanted, so the exercise was a
success. :-)
What's unclear to me -- because I don't remember, if I ever knew -- is
quite why the driver wanted to treat FFFFFF(FF) specially, and therefore
what the implications of removing that behavior might be. Does this
mean, for example, that text will no longer respect colors set via other
methods such as color \specials, because the font will be considered to
have an inherent white color?
JK
