@Carey Underwood: As you may know or not, CMYK numbers don't mean a thing unless they are related to a CMYK profile. That's why Jon Cruz suggested you to use one. If you already know the risks of not using color management and just want a "close enough" approximation the CMYK tab is your friend.
(I won't get into much detail about color management, I don't want to sound like an ass about it. If you feel I should get into more detail, let me know.) However, I see your point. Values shift while writing them in each box which makes impossible to input some values verbatim. But I would say this is normal. What inkscape does is taking the common components of CMY and placing some "ink" on K. So when you have any value >0 on all three CMY spinboxes, the value on K and the rest of the spinboxes will change. But the resulting color seems rather logical. For instance, you have 0/30/30/0, and then go to the C spinbox and input 30. * What you would expect is this: 30/30/30/0 * What you get is this: 1/0/1/30 That's because CMY 30/30/30 is a neutral color[*] (i.e.: gray) so inkscape decides using K=30 and lowering CMY to 0 (or almost), since that's an equivalent neutral color. So when you write c:81 m:18 y:34 k:0 the values shift because inkscape takes into consideration the three >0 values and looks for an equivalent color using K too. In other words, even though values shift you're getting the "right" color (as right as it can which an unmanaged system like this). [*] With real inks this equivalence is not right, C usually has to be higher than the rest to get a neutral color. -- You received this bug notification because you are a member of Registry Administrators, which is the registrant for Fedora. https://bugs.launchpad.net/bugs/166622 Title: HSL and CMYK pickers shift colors _______________________________________________ Mailing list: https://launchpad.net/~registry Post to : registry@lists.launchpad.net Unsubscribe : https://launchpad.net/~registry More help : https://help.launchpad.net/ListHelp
