adding support for the CMYK color space

[sauriio]

Is your feature request related to a problem? Please describe.
I would like to help on the implementation of the CMYK color space into the jspdf object, as seen on the documentation, there's native support for this kind of values, and they are natively supported on the postScript, I would love some guidance in doing it, as it could be helpful to some use cases.

Describe the solution you'd like
I was thinking on maybe using a data-* property on the object that has this need, these values could be a json encoded string with the values for each color and from there use it on the color methods of jspdf, is supported there too.

Describe alternatives you've considered
I haven't see any alternative as this will be a new feature

[yGuy]

I guess we should keep it as close to the upcoming spec as possible:

https://stackoverflow.com/a/23117858/351836 (old proposal)

https://www.w3.org/TR/css-color/#changes-from-20210601 (moves proposal)

https://www.w3.org/TR/css-color-5/#device-cmyk (current proposal?)

That means that I think at least on the svg2pdf side of things, I would prefer it if we do not come up with "our own SVG syntax". We should rather anticipate the upcoming spec changes, implement them and if this breaks the display of the SVGs in current browser implementations, it would be up to the user to encode/rewrite the cmyk colors into the upcoming SVG standard before passing it to svg2pdf. So converting non-spec confirming data-* properties would have to be done as a last step before passing the SVG DOM to svg2pdf.

[sauriio]

It sounds reasonable, I think the latest declaration (device-cmyk()) could be future proof and we could use it into jspdf, so what are the steps to take to implement it? any roadmap or direction to get these css declaration until the setFillColor or setTextColor calls?

[yGuy]

Sorry, no roadmap, here. You will have to check out the code yourself or find someone else. Personally this would be very low on my wish-list. We use this for exporting SVGs that you can actually see in a browser. So supporting something that you cannot see anyway is not high up on our wish-list. What's your use-case for this? Why can't you use the jspdf API directly if you don't have SVGs, anyway?

[sauriio]

Oh there's a use case, is to make printables pdf with this color space, I totally understand the very low wish list thing, I cannot use jspdf API directly because this is a canvas svg export into the PDF document (I dont want to generate an Image btw and add it to the document), thanks for the input!

[yGuy]

But where do you get these SVGs from? My point was that if you are generating them somehow programmatically, you could just as well use the lower-level PDF API via jspdf. What's a "canvas svg export" - HTML5 canvas that somehow converts to SVG, first? If so, you are also using an API (the canvas API) and the SVG step is just an intermediate by-product, isn't it? Why not get rid of the middle-man and use the jspdf API directly? svg2pdf also uses the jspdf API, so anything that you can do via the SVG today you can do with jspdf - and you can even use CMYK on the level of the jspdf API...