View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010054 | Scribus | Color Management | public | 2011-06-17 00:00 | 2021-12-23 22:37 |
| Reporter | chappa-ai | Assigned To | jghali | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | Mac OS X | OS | Snow Leopard | OS Version | 10.6.7 |
| Product Version | 1.4.0svn | ||||
| Target Version | 1.5.4 | Fixed in Version | 1.5.4.svn | ||
| Summary | 0010054: Scribus alters CMYK color values | ||||
| Description | CMYK 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 Reproduce | Define 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. | ||||
| Tags | No tags attached. | ||||
| Patch | No | ||||
|
|
as asked in the mailing list: do we really need a higher precision than 1%? |
|
|
IMHO from user side precision by 1% is enaugh, but from code maybe not be, specially in gradients computing... |
|
|
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. |
|
|
>> 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%. |
|
|
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! |
|
|
I, personally, have no use for decimal values. Integers are fine, so long as they're correct. |
|
|
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. |
|
|
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? |
|
|
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. |
|
|
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 |
|
|
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. |
|
|
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 ! |
|
|
added to 1.4.6svn so devs could decide what to do with this |
|
|
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. |
|
|
Thanks. So assigning to 1.5.2. Then we can bump if needed. |
|
|
Tested r22214 I cannot reproduce animore. Works fine. I watched the patch in the log. Uhh. This was huge work Jean. Thank You. |
| 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 | |
| 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 | |
| 2011-06-18 13:25 | jghali | Note Edited: 0026432 | |
| 2011-06-18 13:28 | jghali | Note Edited: 0026432 | |
| 2011-06-18 13:28 | jghali | Note Added: 0026434 | |
| 2011-06-18 13:31 | jghali | Note Edited: 0026434 | |
| 2011-06-18 16:12 | ale | Note Added: 0026436 | |
| 2011-06-18 19:41 | chappa-ai | Note Added: 0026438 | |
| 2012-06-04 12:12 |
|
Note Added: 0028069 | |
| 2012-06-04 12:14 |
|
Note Edited: 0028069 | |
| 2012-06-04 14:55 | ale | Note Added: 0028073 | |
| 2012-06-04 16:03 |
|
Note Added: 0028075 | |
| 2013-02-05 13:11 |
|
Note Added: 0029790 | |
| 2013-02-05 13:37 |
|
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 |
| 2021-12-23 22:37 | jghali | Relationship added | has duplicate 0016708 |
