Proposal: stable color spaces and earlier CMYK support

[betalars]

Why I think this should have priority

With Inkscape stating they do not want to ever support it and Scribus being nowhere near viable, the FOSS community as of now has no viable way of creating CMYK vector graphics. Therefore I am asking Graphite to push CMYK support forward (and I would be willing to contribute to that).

Properly supporting CMYK and properly emulating CMYK colors on a monitor is a really big thing. And that is especially true, because RGB is additive and CMYK is subtractive:
Full magenta and cyan will not give you a deep blue, as one would assume with RGB. (CMYK(1|1|0|0) = RGB(0|0|1)). In practice it prints more of a deep purple. And the specifics of what that blue looks like also really depend on printer, pigment and paper. So when you want to do any precise color work or fancy printing, you have to do test print with swatches of different CMYK values and then be able to trust that the CMYK value you choose for your final product is exactly what the print-head will get.

The Proposal

Graphite should internally try to keep color spaces as consistent as possible. Meaning if I put a color as CMYK, it should not be converted and be calculated as CMYK for as long as possible. If it needs to be blended with an RGB value, one of the colors will need to be converted obviously. But if everything in the document is CMYK, only the viewport should ever convert something to RGB (with exceptions for color math that does not work for CMYK).

Main benefits

• filling a gaping hole in the FOSS-toolkit
• having to do less rework when implementing color spaces down the line and having more flexibility for unique approaches because less is set in stone
• creating the best stickers is good for engagement in the FOSS community I have heard

Special Printing

Here is where it becomes really nuts:

• you can print on holographic foil
• you can print with a white sublayer
  • you can print with a partial white sublayer on holo foil so some colors appear more holographic than others
• you can print on neon paper
• you can print with pre-mixed colors (especially with Screen Printing
• you can print with neon colors
• You can print with a partial glossy top coating so some elements appear more shiny than others

A lot of these benefit from being able to use reliable color spaces without having to think about it too much.

The advanced proposal

I'd also like to see support for non-standard color spaces for printing CMYK on neon or printing with full colors. CMYK on neon is totally possible and can yield amazing results (I have tested that). This is kind of feature creep, but maybe worth to think about when we consider how to approach supporting CMYK.

Known Issues

• this adds a lot of complexity to color math and color handling. Keeping rasterized operations in a uniform RGB space may still be a good idea
• color math is really weird and creating an implementation that is not just giving a false sense of reliability but an actual benefit will be challenging
• there is a lot still to consider when it comes to especially layouting and typesetting as of now. CMYK might not be the first priority in this regard, especially because desktop publishing does not even need it to begin with.
• we will very likely have to write or own color management for more advances use cases and won't be able to rely on existing solutions

Non Issues

• pdf is the only format that supports cmyk and that is a huge beast
  We can export TIFF raster images and that will still be better than having no CMYK support at all.
• Why don't we use a big unified (RGB) color space?
  Because conversions are ambiguous. The easiest example is RGBW (used in LEDs with a white subpixel). RGB(1|1|1) is the same as RGBW(1|1|1|0) and RGBW(0|0|0|1), but those produce very different colors in the real world. For LEDs that is not a big deal because you kind of always want to use the white LED as much as possible, but with CMYK it is a different beast because the black pigment is so much more different than the color pigments.
• that is not supported in svg
  I think the "One app to rule them all" that supports "Page Layout & Print" should be able to do more than svg. We can always add a warning letting users know that some features they have in their graph are not supported by svg export and will therefore look different
  Plus: we could also just create a layer for each color channel and then set an appropriate blending mode when exporting non-rgb svgs. 😅
• what about ICC profiles?
  I think they allow for much polish, but any kind of CMYK support creates much more opportunities right now.
• Who is going to do that
  I have been meaning to relearn rust for a while and I even have a rusty implementation of RGB, RGBW and HSV color structs with implicit conversions and blend modes somewhere. My time right now is limited, but I also kind of need a pet project right now I think.

[betalars]

Another cool color space we could support, maybe even more important than hsv: https://oklch.com/

[0HyperCube]

the "One app to rule them all" that supports "Page Layout & Print" should be able to do more than svg

The goal of Graphite is to provide fun to use procedural vector animations (as discussed in my voice call with Keavon on 27th June). There is no possibility of it being used for page layout or printing workflows.

It is hardly a suitable alternative to inkscape as it does not support editing very basic SVGs, therefore I fail to see how it is "one app to rule them all".

By default, Graphite renders the document by embedding an SVG into the DOM. This approach is incompatible with supporting print colour space blending algorithms. Graphite also supports rendering with vello, which uses the color crate which states that "Print color spaces (CMYK) … are out of scope for this crate". I feel this issue of rendering is not suitably addressed in your proposal.

[betalars]

The goal of Graphite is to provide fun to use procedural vector animations (as discussed in my voice call with Keavon on 27th June). There is no possibility of it being used for page layout or printing workflows.

I can see that but I'd suggest updating the webpage then:

[Keavon]

I regrettably am forced to interject here and clarify that @0HyperCube's statements are his personal views and do not reflect the vision or roadmap of the project at large, which absolutely does include future support for CMYK, page layout, and becoming a universal tool/engine for all forms of 2D graphics editing. His statements are more indicative of the short term, but don't apply to the longer term direction of the project.