View Issue Details

IDProjectCategoryView StatusLast Update
0010054ScribusColor Managementpublic2017-12-20 20:58
Reporterchappa-ai Assigned Tojghali  
Status closedResolutionfixed 
PlatformMac OS XOSSnow LeopardOS Version10.6.7
Product Version1.4.0svn 
Target Version1.5.4Fixed in Version1.5.4.svn 
Summary0010054: Scribus alters CMYK color values
DescriptionCMYK color values do not seem to be getting stored with the same values entered by the user. It seems percentage values not evenly divisible by 20 are modified by less than 1%.
Steps To ReproduceDefine any CMYK color and click OK. Edit the color and notice percentage values that are evenly divisible by 20 have the same value that was entered, yet values not evenly divisible by 20 are modified to a different value.
TagsNo tags attached.


has duplicate 0013359 closedjghali CMYK values entered but saved rounded. 
related to 0012700 closed Replace the default CMYK profile 



2011-06-18 07:20

manager   ~0026429

Last edited: 2011-06-18 07:20

View 2 revisions

as asked in the mailing list: do we really need a higher precision than 1%?


2011-06-18 09:28

developer   ~0026431

IMHO from user side precision by 1% is enaugh, but from code maybe not be, specially in gradients computing...


2011-06-18 13:00

reporter   ~0026432

Last edited: 2011-06-18 13:28

View 4 revisions

It just seems odd to me from a UI perspective that if a user enters a specific value for a field, they don't get that value. What if you where entering your address and entered 83711 for your zip code, but the system actually stored it as 83713 due to a format conversion process and it didn't matter because it was "close enough"? I can accept that there isn't discernable difference between "valid" CMYK values, but hey - Gimp gets it right! If I choose, say, 43% for a value, I get 43% for that value. I had just assumed Scribus would do the same, again from an "outside the box" perspective. As a user, I shouldn't have to care about 8-bit version 16-bit, hex versus decimal....43% in the UI should be 43%, period.


2011-06-18 13:28

administrator   ~0026434

Last edited: 2011-06-18 13:31

View 2 revisions

>> I can accept that there isn't discernable difference between "valid" CMYK values, but hey - Gimp gets it right! If I choose, say, 43% for a value, I get 43% for that value.

No, Gimp does not get it quite right, because the value entered does not represent the reality of what Gimp will use :
- Gimp does not support CMYK, so that value will be converted to RGB, and worse i challenge you to get really your 43% on output with their separation plugin.
- Gimp does not support working in 16bit by channel mode only 8bit, so values between 0-100% are encoded using 255 values => the value really used for your 43% will be really 42.74% or 43.14% depending on how rounding is done, not 43%.


2011-06-18 16:12

manager   ~0026436

chappa-ai, this is where i wanted to get: if there is no use for decimal values we should only allow the user to insert integer values.

if we can agree that most people won't use decimal values, we can change the input field to only accept integer values.

if, in the future, somebody comes and ask for decimal values, we will have to implement it correctly!


2011-06-18 19:41

reporter   ~0026438

I, personally, have no use for decimal values. Integers are fine, so long as they're correct.


2012-06-04 12:12


Last edited: 2012-06-04 12:14

View 2 revisions

Just ran into a related problem. Could not set a CMYK value of 50,20%, not with any value from 50,00% to 51,00%. After closing and reopening the edit dialog it would always change to 49,80% (or 51,00%). Quite annoying. Importing the color from another document helped in the end.
It seemed like the colors are stored as 8bit integers but for some reason not all integer values were accessible.
Integer option would be great or at least a fix so that the closest possible percent value is found.

Because this bug can be easily missed and cause a document with wrong color sent out into the wild I would suggest increasing the severity of this issue.


2012-06-04 14:55

manager   ~0028073

well, fkjt79, i think that we need a decision on what to do...

should there be only integers or not?

if yes, it is probably easy to fix.

if not, what is the necessary precision? 0.01?


2012-06-04 16:03


this is a line from an .eps file (written with scribus but imported from .pdf):
1 0.0392157 0.0901961 0.45098 cmyk fill
ok, this is overkill.

but I'd say the precision should at least be what is displayed in the dialog: 0.01%

Integers only would be fine for me but the cmyk world often (mostly?) goes with percent values.

If the limitation comes from the underlying value being an 8bit int that is ok for me, too, as long as I can choose every single one of the 255 values and am not limited to only half of them as is the case for me now.


2013-02-05 13:11


Ran into this problem again. Can not set 90.20% via the controller. It always gets rounded to 89.80. Next higher step settable is 90.98. It works if I carefully navigate to 90.20% in the color chooser above.

There is definitely a rounding bug in the gui.

90.2 is falsely being rounded/floored to 90 before further processing. Then 90/100*255 = 229.5 229.5 becomes 229 as an integer. 229/255*100 = 89.8

Correctly it would go like this: 90.2/100*255 = 230; 230/255*100=90.2


2013-02-05 13:37


Just found a workaround:
- Set the color value: 90.2% (90,2% in my german version)
- Change some other color either via up/down or the color scrollcontrol and change it back.
- Close the dialog.
- Reopen the dialog - color is ok.


2015-09-22 07:56

reporter   ~0036326

This workaround does not work !!!!
The precision is needed as some printers use precise values as codes for non-standard colors such as gold or silver, and thus Scribus is not usable in this case !


2015-09-26 23:59

updater   ~0036408

added to 1.4.6svn so devs could decide what to do with this


2015-10-10 14:49

administrator   ~0036601

Removing from 1.4.6 roadmap. Given this issue requires important changes and that 1.4.x is a stable version, fixing this in 1.4.x is a no go.


2015-10-10 22:43

updater   ~0036606

Thanks. So assigning to 1.5.2. Then we can bump if needed.


2017-11-03 18:18

developer   ~0044620

Tested r22214

I cannot reproduce animore. Works fine.

I watched the patch in the log. Uhh. This was huge work Jean.
Thank You.

Issue History

Date Modified Username Field Change
2011-06-17 00:00 chappa-ai New Issue
2011-06-18 07:20 ale Note Added: 0026429
2011-06-18 07:20 ale Note Edited: 0026429 View Revisions
2011-06-18 09:28 cezaryece Note Added: 0026431
2011-06-18 13:00 chappa-ai Note Added: 0026432
2011-06-18 13:24 jghali Note Edited: 0026432 View Revisions
2011-06-18 13:25 jghali Note Edited: 0026432 View Revisions
2011-06-18 13:28 jghali Note Edited: 0026432 View Revisions
2011-06-18 13:28 jghali Note Added: 0026434
2011-06-18 13:31 jghali Note Edited: 0026434 View Revisions
2011-06-18 16:12 ale Note Added: 0026436
2011-06-18 19:41 chappa-ai Note Added: 0026438
2012-06-04 12:12 user4253 Note Added: 0028069
2012-06-04 12:14 user4253 Note Edited: 0028069 View Revisions
2012-06-04 14:55 ale Note Added: 0028073
2012-06-04 16:03 user4253 Note Added: 0028075
2013-02-05 13:11 user4253 Note Added: 0029790
2013-02-05 13:37 user4253 Note Added: 0029791
2015-09-21 15:57 jghali Relationship added has duplicate 0013359
2015-09-22 07:56 denisvanb Note Added: 0036326
2015-09-26 23:59 Kunda Patch => No
2015-09-26 23:59 Kunda Note Added: 0036408
2015-09-26 23:59 Kunda Target Version => 1.4.6
2015-09-27 00:04 Kunda Relationship added related to 0012700
2015-10-10 14:49 jghali Note Added: 0036601
2015-10-10 14:49 jghali Target Version 1.4.6 =>
2015-10-10 22:43 Kunda Note Added: 0036606
2015-10-10 22:43 Kunda Target Version => 1.5.2
2016-01-23 17:15 cbradney Target Version 1.5.2 => 1.5.4.svn
2017-11-01 12:57 jghali Target Version 1.5.4.svn => 1.5.4
2017-11-01 23:18 jghali Summary Scribus Alters CMYK Color Values => Scribus alters CMYK color values
2017-11-01 23:54 jghali Assigned To => jghali
2017-11-01 23:54 jghali Status new => resolved
2017-11-01 23:54 jghali Resolution open => fixed
2017-11-01 23:54 jghali Fixed in Version => 1.5.4.svn
2017-11-03 18:18 PeterBenedek Note Added: 0044620
2017-12-20 20:58 cbradney Status resolved => closed