[XeTeX] "Options for all fonts" : colo[u]r, and the transparency byte

[mskala at ansuz.sooke.bc.ca]

On Sun, 5 Jun 2011, Philip TAYLOR (Webmaster, Ret'd) wrote:
> Thank you for your prompt response, Mathew.  In fact, I am using the default
> driver (I am not aware how I might alter this), and was simply relying on it
> to "do the right thing".  If you could tell me how to identify the driver, and
> what possible additional options I might pass to it to improve matters, I

The default driver for XeTeX is xdvipdfmx; you're probably already using
it, so that's most likely not your problem.  I'm not actually sure XeTeX
*can* work with any other... but other TeX engines can.  In particular:

  * If you're using the "tex" or "latex" command to typeset your document,
    the output will generally be a .dvi file that can be processed by
    multiple drivers (but probably can't handle the kinds of graphics
    you're doing).
  * If you're using "pdftex" or "pdflatex", I think those have their own
    driver built in, as well as possibly an option to generate DVIs.
  * If you're using XeTeX or XeLaTeX, it will by default run xdvipdfmx; I
    think it's possible to separate that into another step with the
    -no-pdf option, but I don't know what other drivers can read the
    resulting .xdv file.

My next guess would be that there may be an issue with whatever you're
using to view the resulting .pdf file.  Acrobat Reader should handle
transparency (I don't have a copy handy to check, but it's usually thought
of as the gold standard); my installations of "xpdf" and KDE's "okular"
both do it; but I think older versions of xpdf don't, and there are
many other PDF viewers out there.

You may be able to check the version of your PDF files with the "file" or
"pdfinfo" commands.  My transparency-containing PDFs are reported
as version 1.5.

Another thing to try:  it's possible that using a transparent colour for
your text with the "color=" feature doesn't work even if using some other
route to transparency would work.  I tried to reproduce your problem and
realized that the feature whose documentation you quoted from is a Plain
XeTeX feature associated with the "\font" command.  I'm not familiar
enough with that low-level command to test it reliably; the approach I've
used, which has worked for me, is to use transparency at the level of TikZ
(they call it "opacity", which is just the inverse) in LaTeX, something
like this:

\begin{tikzpicture}
  \node[color=blue,opacity=0.2] at (0,0) {Blah blah};
\end{tikzpicture}

I think it'd be worth trying to set the colour and opacity in that way
rather than through the low-level \font command.

> be most grateful.  As you correctly anticipate, rasterising the output would
> be self-defeating : the whole object of this exercise is to generate a PDF
> that
> contains embedded scaleable fonts and glyphs.

Make sure your print shop can handle transparency.  If they can't, you'll
be wasting your time trying to resolve the software issues on your own
end.  I've heard professional designers claim snarkily that any shop that
can't handle (the very latest bleeding-edge optional features of...)
standard formats shouldn't be in the business, but it's a fact that many
shops who deal with the general public (e.g. Lulu, and Amazon CreateSpace)
insist resolving transparency should be the customer's problem, not theirs.

Is it *really* prohibitive to rasterize?  The resulting file sizes
shouldn't be all that bad, because of compression, and anyone with a
printer that handles huge media ought to be able to deal with files of the
size doing so requires.  They have to print photos on their printer once
in a while, and as soon as they do, they'll be handling files larger
than yours.
-- 
Matthew Skala
mskala at ansuz.sooke.bc.ca                 People before principles.
http://ansuz.sooke.bc.ca/