CMYK colors work at the moment by specifying the color as cmyk(...) which transforms internally to an rgb color (all R can understand). Then the pdf(colormodel="cmyk") device transforms these rgbs back to cmyk.
This process is a bit lossy as cmyk colors are overspecified (ie. two different cmyk colors can map to the same rgb), but that's not usually a big deal and the resulting PDF looks fine, at least on screen.
A bigger problem is that the rgb colors representing cmyk colors look totally different as rgb colors, for instance if outputting a png. For that reason we have to switch between style_atlas and style_atlas_cmyk as appropriate.
A slightly bigger problem, again, is that the relative luminance and related functions do not work properly for these pseudo-rgb colors, so contrasting text colors are poorly chosen (e.g. white when it should be black, etc). I added the biases parameter to contrasting_colors() to hack around this, but it doesn't really work.
A proper solution would be to have a colormodel parameter in contrast_colors() and co, and calculate it differently (however that is) for pseudo-cmyk colors.
CMYK colors work at the moment by specifying the color as cmyk(...) which transforms internally to an rgb color (all R can understand). Then the pdf(colormodel="cmyk") device transforms these rgbs back to cmyk.
This process is a bit lossy as cmyk colors are overspecified (ie. two different cmyk colors can map to the same rgb), but that's not usually a big deal and the resulting PDF looks fine, at least on screen.
A bigger problem is that the rgb colors representing cmyk colors look totally different as rgb colors, for instance if outputting a png. For that reason we have to switch between style_atlas and style_atlas_cmyk as appropriate.
A slightly bigger problem, again, is that the relative luminance and related functions do not work properly for these pseudo-rgb colors, so contrasting text colors are poorly chosen (e.g. white when it should be black, etc). I added the
biasesparameter to contrasting_colors() to hack around this, but it doesn't really work.A proper solution would be to have a colormodel parameter in contrast_colors() and co, and calculate it differently (however that is) for pseudo-cmyk colors.
This needs some proper thought though.