Was it because non RGB color spaces were hard, due to the program being designed around RGB and the assumption of RGB is everywhere in the codebase?
Or is it something particularly tricky about CMYK?
The previous attempt to add CMYK exporting didn't go well. The developer implemented all that in a new set of plugins instead of building the functionality into existing code. This wouldn't work. The developer apparently wasn't interested to do it right or did not have the time, he wouldn't say.
So there's the architectural aspect of this and then there's availability of a contributor willing to hacks on this.
You can read a little more about this GSoC project here: https://www.gimp.org/news/2022/06/03/cmyk-in-gsoc-2022/
Bit weird to put it like that, everyone else in the world didn't do it either, it's open source after all.
https://gitlab.gnome.org/Infrastructure/gimp-web/-/issues/25...
Years of docs gone because one unnamed maintainer forgot to update hosting. With no backups. The official roadmap https://wiki.gimp.org/wiki/Roadmap#GIMP_3.0 has been inaccessible for 3 months, which the blog glosses over as no big deal. This kind of amateurism is uncommon to Blender and Krita but rather common to GIMP; some of their maintainers have even been banned from twitter.
OMG, nope. The person in a parent thread asked a very specific question: what's tricky about CMYK support and why it didn't come earlier.
How can I answer that without explaining that CMYK exporting almost happened years before and saying what went wrong there?
Of course, it's your choice to think the worst of people.
> some of their maintainers have even been banned from twitter.
Are you referring to me?
Not only for Gimp, but for Inkscape too.[0,1]
[0] https://wiki.inkscape.org/wiki/Color_Management_Planning