Set to new.

This is reproducible in 1.0.3 and in a current internal version. I do
not get 100/100/0/0 as result but the counts are diffferent than the
ones I typed in. They are changed after the dialog is closed.
Reassigned to Christian.

Set target to next build and prio to 3.

thorsten, please have a look

This is inevitable, unfortunately, because we store color in RGB internally. The 
circumstance when these changes do happen is when all three color components (CMY) 
are greater than zero. The common value (i.e. the smallest of all three values) is then 
transfered to K. For example, your C=80, Y=46, M=9, K=0 example becomes C=71, Y=37, 
M=0, K=9, because magenta's 9% is moved to key, and the other two components are 
reduced accordingly.

There are plans to have CMYK stored as an internal format, 
too. But this is probably beyond 2.0

-

*** Issue 51262 has been marked as a duplicate of this issue. ***

Changed OS to All as this issue affects *NIX as well.

*** Issue 41948 has been marked as a duplicate of this issue. ***

I've got a similar problem with CMYK in OOo 2.1. I try setting up a company logo
standard colour (Pantone 301C = CMYK 100% / 53% / 16% / 22%) OOo's RGB result is
(0 / 64 / 158) which is much darker than a (more) "true" conversion which gives
(1 / 94 / 168).
When I change back (in OOo) from RGB to CMYK I get a result of (62% / 37% / 0% /
38%) - this is an unacceptable deviation which can easily be seen to be much
darker than the orriginal - the black (or key) is more and all other colours are
less. Why did you go for this implementation?

Converting between RGB and CMYK is very difficult and several methods are
available - all give inconsistent results. The best method is to use ICC
(International Colour Consortium) profiles to convert between colour spaces. So
why not do away with storing to CMYK (for that matter RGB as well). These are
device dependant and will thus appear different on different machines. Even the
same RGB value will look different when printed, and could even look different
on another screen.

I suggest storing in something like CIELAB, the standard of the ICC profiles
which makes it easy to change from any colour space to another (including RGB,
CMY, CMYK, HSV, HSL, LUV, XYZ, LAB, etc.) with very little programming. There is
even an opensource ICC engine http://www.littlecms.com/ , which can then be
incorporated in office - making it a true device INDEPENDENT program.

@irneb: your comments make perfectly sense - the reason why we still don't
handle colors != RGB internally is that massive amounts of code need to be
changed. But rest assured that we're aware of the problem, and whenever we
rework code in the graphics subsystem, we abstract away from the color space.

*** Issue 69105 has been marked as a duplicate of this issue. ***

In pre press we need  black, which is  c 50% m 40% y 40% k 100%. Actually, when
defining this, the result is c 0% m 0% y 0% k 100%, which is "not black enough".

As a stop-gap measure, would it be possible to change only the piece of code
which translates RGB to-and-from CMYK? Obviously this is the major problem which
causes the inconsistency. Even if OOo still stores the colour in RGB form, a
more "accurate" conversion method would at least provide a more consistent CMYK
value. It might still deviate slightly, but to such small effect that the
difference wouldn't be discernible by eye.

As for the "more-black-than-black" colours, this would only be possible using a
different colour storage method. I even think only CMYK has this ability, which
is actually defining a colour which "doesn't exist". The reason behind these
colours are usually to force a printer to use all 4 its inks when creating
black, usually to compensate for the black ink dye being a bit too gray.

In this case we generally don't adjust for such in the documents. We adjust the
printer's settings using colour correction methods. If you know the black comes
out too washed out, the printer needs to be adjusted either mechanically (by
using blacker ink) or through software (using colour correction in the driver).
But then, that's because we own our own large format printers. When you have to
rely on some outside printer service, you don't have this option. I would advise
however, that you use some other type of program for pre-press ... maybe
something like a DTP (search for Scribus)?

Suggestion:
The conversion from CMY to CMYK as described in http://www.easyrgb.com/math.html
(link from wikipedia) leads to this problem. What about converting as follows:

CMYK => RGB

R = maximum((1 - C + (CONST_C - 1) K), 0) * 255
G = maximum((1 - M + (CONST_M - 1) K), 0) * 255
B = maximum((1 - Y + (CONST_Y - 1) K), 0) * 255

RGB => CMYK

cmy_C = 1 - (R / 255)
cmy_M = 1 - (G / 255)
cmy_Y = 1 - (B / 255)
K = minimum(cmy_C, cmy_M, cmy_Y)
C = cmy_C + (CONST_C - 1) K
M = cmy_M + (CONST_M - 1) K
Y = cmy_Y + (CONST_Y - 1) K

where CONST_C, CONST_M and CONST_Y must be in range from 0 to 1. They might be
configurable dependant on pre press demands. If most brilliant black is
CMYK(0.5/0.4/0.4/1.0) we have to choose CONST_C as 0.5 or 50% and so on.
CMYK values that whould result in a colour more black than the most brilliant
black are changed accordingly.

The problem would still be that the OD# file saves the colour as RGB values. So
this then needs to be exported into a file type which has CMYK abilities
(something like PDF, JPG or TIFF). In which case you can use a PDF Printer
driver (seeing as OOo's PDF export doesn't do CMYK) and apply one of the CMYK
ICC profiles to this driver. You could even obtain the ICC profile specific to
the printer you intend sending it to (hopefully the print-shop or whatever has
such :) ).

The ICC profile can be seen as the formula you suggest with a varying constant.
Depending on the darkness of the colour the constant might need to increase /
decrease. This is accomplished in the profile by having certain sample colours
with near exact matching coordinated values in the target space. The colours in
between then gets extrapolated, so the more samples the more accurate.
http://www.color.org/

As I've stated there is a open source ICC engine available
(http://www.littlecms.com/) which has a reasonably simple way of sending an RGB
value and obtaining another colour space value as result. In their tutorial they
even have a sample of how to convert a BMP between RGB->CMYK and CMYK->RGB.

My suggestion was not intended to be a proper solution but merely a work around
for the fact that OOo is an rgb based software.
Its colour range so far is from cmyk(0 / 0 / 0 / 1) to cmyk(0 / 0 / 0 / 0). It
might be a good idea to express these limitations in the corresponding dialogue.
If done so, it would be quite sufficient to accept that entered values slightly
differ from those that are transformed to and back from rgb. But still the
limitation of colour range is ugly and should be configurable. So my wish would
be: Having a simple standard transform with cmyk2rgb( rgb2cmyk( Colour A)) is
always Colour A and rgb2cmyk( cmyk2rgb( Colour B)) is close to Colour B as long
as Colour B is in the configured range from let's say cmyk(0.5 / 0.4 / 0.4 / 1)
to cmyk(0 / 0 / 0 / 0). An additional plug in based on "little cms" might be fine.

Reset to default assignee.

*** Issue 126550 has been marked as a duplicate of this issue. ***