Menu
▾
▴
#29 Shade does not respect color space
Hello,
shaded paths are always rendered in RGB even though all three colors are given in CMYK. Filled path on the other hand are correctly rendered in the color model of the given color. This results in color "breaks" if a shaded area adjoins a filled area of the same color.
As fas as I understand the PDF specs the color space for shadings can also be chosen freely.
I attached a minimal example compiled with pdflatex.
Yours Bastian
Minimal example
Logged In: YES
user_id=1545458
Originator: YES
File Added: shadingcmyk.pdf
Compiled minimal example
Logged In: YES
user_id=886275
Originator: NO
Hi!
sorry, this is a "known problem". It is "somewhat difficult" to program this stuff (since PostScript also needs to be supported and SVG and the parser has the be partly rewritten and the problem of mixed color spaces has to be handled). However, I am aware that, in principle, it would be possible to support CMYK shadings directly.
So,... any volunteers for a good implementation (see above) are welcome...
I'm moving this to a feature request.
Best regards,
Till
Logged In: NO
I'd add a request for this feature as well. As an interim step before getting full PS and SVG compliance, would it be possible to let the PostScript/SVG drivers continue to convert to rgb, but let the PDF driver use the cmyk space? Alternatively, if you use only named colors (and those colors were defined with the cmyk space) that you not do the cmyk->rgb conversion?
I submitted a similar test case in bug 1931951 -- the gradients and the boxes in the section headings should end in the same colors, and visibly do not.
~ben
Since it seems no further development on this has happened, may I ask about a workaround? In my particular case, I'm trying to use XeLaTeX (compiling to a PDF directly), and want to produce a shading from some CMYK color to white. Now I can achieve the equivalent by using a fading instead, since fading to transparent is the same as fading to white when your paper is by default white. Unfortunately, TikZ/PGF complains that the pgfsys-xetex.def driver doesn't support fadings. How hard would it be to add fadings to the xetex driver?
~ben
Hi. In the past, fadings could not be supported by pgfsys-xetex since the backend driver of xetex (xdvipdfmx) did not support the necessary pdf-constructs. However, the xdvipdfmx people have been quite busy and now it might be possible with the latest versions. However, this is yet another feature request... Sorry, Till
I guess I don't understand the full pipeline here, but I was under the (probably mistaken!) impression that "specials" were simply instructions that were passed through unmodified from *TeX to the output file, like inline assembly in C. And that therefore, "all" that was necessary was to emit the appropriate calls to \pdfxform and it'd Just Work. Obviously I'm missing something here, so sorry if this sounds like a typical newbie-wants-the-impossible request :-\ I'd rather understand why what I was thinking makes no sense, as maybe that would lead me towards another way to work around this. I've worked my way through several of the layers of PGF, and while I wouldn't say I could contribute anything to the code yet, I am getting a sense of how it hangs together and works...
In any case, looking over pgfmanual, on page 90 where it documents pgfsys-dvipdfm.def and pgfsys-xetex.def, it would be useful to include a line saying fadings don't work...at least until they do :)
~ben
Hi!
\specials are a bit more complicated, unfortunately. You are right, the text in a special is, indeed, just passed on. However, the backend driver (like dvipdfm) will "interpret" the special. Every backend driver has its own syntax and supports different things.
Dvipdfm for instance, does not support the kind of xform-objects that are needed for fadings (namely xform objects with resource dictionaries). So, no matter what pgf would like to do, the dvipdfm driver simply *cannot* produce the necessary pdf code.
The \pdfxform command is a speciality of pdftex and cannot be used with xetex.
So, what is actually needed for fadings to work with xetex is a backend driver that offers support of the specials that are needed for fadings. xdvipdfmx in its most recent versions seems to have this support. So, someone (probably me or a xdvipdfmx developer) has to start coding the necessary specials for this particular extended version.
Till
Just pinging a followup -- has anyone looking into this?
~ben
According to http://www.nabble.com/pgf-xetex-really-doesn%27t-support-fading---td22156523.html, there's been additional interest in getting fadings to work with XeTeX/XeLaTeX. I've now encountered another situation where I'd like to use them in Beamer, but have to stick to LaTeX (and therefore lose XeTeX's fonts...)
I'd be happy to test any patched versions; I wish I could contribute a patch myself but I don't have the background knowledge of the code...
~ben
I see that Jin-Hwan Cho's patches have landed in the 6/2/09 build of PGF, and I see in that patch that the pgfsys-dvipdfx file now contains definitions for shadings and fadings. But the original problem in this feature request seems unchanged, as does the workaround with xetex and fadings, since pgfsys-xetex hasn't changed -- does the patch not help either usage?
~ben
Hi,
It's been several months with no comments on this or other cmyk colorspace bugs (e.g., bug ID: 2813307), though there have been several PGF/TikZ builds since then. Is anything happening on fixing cmyk colorspace support for shadings/fadings?
Thanks,
~ben
View and moderate all "feature-requests Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Feature Requests"
Has there been any progress over the past year in fleshing out cmyk colorspace support for shadings, or xelatex support for fadings? I'm still looking for a way to generate consistent colors in the colorspace intended for print...
I have written a package to support CMYK and Grayscale shadings. See pgf-cmykshadings. With a new version of PGF/TikZ having been released and development (hopefully) continuing, perhaps this feature could be included in the main PGF package now?
I'll take care of it.