color profile gets deselected

Bug #632023 reported by Alexandre Prokoudine on 2010-09-06
This bug affects 12 people
Affects Status Importance Assigned to Milestone

Bug Description

Color profile is deselected in CMS tab of Fill'n'Stroke dialog as of 0.48 and rev9734 from trunk whenever you try to edit the value by dragging a slider.

Related reports are:

su_v (suv-lp) wrote :

Reproduced with Inkscape 0.48+devel r9745 on OS X 10.5.8,
e.g. with 'U.S.-Web-Coated--SWOP--v2' ICC profile

IMHO similar to bug #166551 “color sliders don't loose focus on mouse up” the mouse focus seems get stuck within the color slider that was last dragged in the CMS tab (when using a CMYK ICC profile) and causes a change of the value on mouse-over with a subsequent collapse of the four color sliders and a change of the color profile back to <None>.

tags: added: color ui
Changed in inkscape:
importance: Undecided → Medium
status: New → Confirmed
su_v (suv-lp) wrote :

Update: This issue seems to be related to the linked ICC profile (or its version?):

Tests in Inkscape 0.48+devel r9828 (lcms 1.19) on OS X 10.5.8 e.g. with two different Fogra27 profiles:

1) Coated FOGRA27 (ISO 12647-2:2004)
- download from
- CMS color sliders behave erratically and do not allow changes

2) Fogra27L CMYK Coated Press
- downloaded from lp:ubuntu/icc-profiles
- CMS color slides work as expected and the profile stays selected

su_v (suv-lp) wrote :

Same issue reported in:

Bug #444040 “0.47pre3 win32 CMS bugs, pencil and clipping path bugs”

inkscape-devel -- Subject: Quirkiness with CMS Fill tab

Still a current bug for Inkscape 0.48.0 r9654

The issue does seem in some way related to which ICC profile is used, and also has something to do with the colour sliders not releasing mouse focus, but it is not possible to avoid the issue by using the text boxes to enter CMYK values instead.

My suspicion is that there's a problem with how Inkscape tries to adjust the colour when using certain profiles.

Does anyone have a Fogra 39 ICC profile that works with Inkscape? The one from Adobe won't work.

Sergio S (mentebinaria) wrote :

I had the same problem, but i found a way to get around it: i created a copy of the ICC profile ("U.S. Web Coated (SWOP) v2") and used a hex editor to replace the spaces and parenthesis in the name with underscores ("U.S._Web_Coated__SWOP__v2").
Not the best solution, but at least now i can edit the colours.

Sergio S (mentebinaria) wrote :

Small correction: i also had to replace the full stops, so the final name was actually "U_S__Web_Coated__SWOP__v2".

jazzynico (jazzynico) wrote :

Duplicate Bug #1264644 also reports the same issue when there's a colon in the profile name (reproduced with Coated-GRACol-2006--ISO(12647-2:2004), not when the same profile is renamed Coated-GRACol-2006--ISO-12647-2-2004-).

Changed in inkscape:
status: Confirmed → Triaged
jazzynico (jazzynico) on 2013-12-30
Changed in inkscape:
assignee: nobody → jazzynico (jazzynico)
jazzynico (jazzynico) wrote :

Apparently, the colon and full stops characters are accepted in the name (as recommended in the SVG specs), but there's something wrong with our code.

jazzynico (jazzynico) wrote :

I'm a bit stuck.
My latest findings, with a rectangle associated with a sRGB-IEC61966-2.1 profile. Everything (except the libcroco part) is In src/style.cpp:

1. The "p" value sent to sp_style_merge_from_style_string(SPStyle *const style, gchar const *const p) is correct:
** Message: sp_style_merge_from_style_string, fill:#3aa869 icc-color(sRGB-IEC61966-2.1, 0.22758831, 0.65891508, 0.41173419);

2. sp_style_merge_from_style_string then calls cr_declaration_parse_list_from_buf() (libcroco) and sends the declaration to sp_style_merge_from_decl_list().

3. sp_style_merge_from_decl_list() then calls sp_style_merge_style_from_decl(). The icc-color value is incorrect:
** Message: sp_style_merge_style_from_decl, #3aa869 icc-color(sRGB-IEC61966-2 0.10000000000000001, 0.22758830999999999, 0.65891507999999999, 0.41173419000000000).

jazzynico (jazzynico) on 2013-12-31
Changed in inkscape:
assignee: jazzynico (jazzynico) → nobody
houz (houz) wrote :

From what I noticed with 13748 is that the color profile gets reset when I am editing a gradient stop or a swatch (which is basically the same), solid fills work. When changing values for gradient stops I see a call to _colorChanged() every time which is not done when changing solid fills. I am not sure if this is the cause of the underlying problem though.

Nelson Lago (lago) wrote :

This bug still exists as of inkscape 0.91 r13725 (the version in xenial). I am using the "Euroscale-Uncoated-v2" profile and also tried "ISO-Uncoated", so this is not related to the profile name. Also, as mentioned by houz, solid colors work correctly, the problem occurs only with gradients.

Nelson Lago (lago) wrote :

Oops! Just noticed that the name *does* have some relevance. With "simple" profile names, solid colors work correctly but gradients do not. With "fancy" names (in my case, Coated-FOGRA39--ISO-12647-2:2004-), the problem occurs both with gradients and solid colors.

Still, if you manage to select a profile and save the file, the profile information for that color does get saved.

Emile Pesik (stuff-s) wrote :

I wondered whether the problem happened with all the profiles that Adobe make available for free to end users (, so I tried it with all of the CMYK profiles provided in the zip file and found that the problem occurs with the following 7 out of 14:


I also tried the following profile, downloaded from, and found that the problem occurs with this one too:

coated_FOGRA39_GCR_bas.icc (this is the actual profile name, as well as the file name).

As mentioned above, changing the name with a hex editor solves the problem for solid colours, but not for gradients.

When the problem occurs, the selected profile on the CMS tab jumps back to the last one that works fine, e.g. '<none>' or 'Japan Color 2001 Coated' (also in the Adobe profile pack).

I did not try any of the 8 Adobe RGB profiles also in the same pack.

This bug report is 5 years old and really ought to be addressed. Comment #10 from 2013 seems to acknowledge that the problem is in Inkscape's code, but there is no follow-up.

I'm working on CD artwork for an established artist at the moment and have to recreate some of the artwork I have been supplied with as it's not usable in its current form (wrong dimensions and in RGB). I don't have access to Illustrator, PhotoShop etc., and even if I did, I make a point of being able to do this purely with open source software. I've done a few in the past, using Scribus, Inkscape, GIMP and Krita, but it is not exactly easy, largely due to the lack of (proper) CMYK support in Inkscape and GIMP. Having this particular problem solved would go a long way in getting designs from Inkscape into Scribus for CMYK professional printing. This bug is currently a major hindrance in trying to complete this artwork.

I'm using Inkscape 0.91 r13725 on Arch Linux.

jazzynico (jazzynico) wrote :

Tried to debug it again on Windows, but unfortunately some code has changed and now Inkscape can't even load the profiles. It's probably OS related, but the new code in color-profile.cpp, ColorProfile::set, returns an empty file path. Not sure if the problem is in that part of the code or in uri.cpp. To be investigated.

jazzynico (jazzynico) wrote :

Back to Xubuntu...
The first unexpected thing is that ColorICCSelector::_colorChanged (ui/widget/color-icc-selector.cpp:737) is called twice when selecting an invalid profile. The first time with a correct name (sRGB-IEC61966-2.1), and the second time truncated (sRGB-IEC61966-2).

jazzynico (jazzynico) wrote :

The Windows specific issue (see comment #16) is now tracked in bug #1644886 "Color profiles not loaded on Windows" (

jazzynico (jazzynico) wrote :

Very hard to track...
The first invalid name I can find is from SPPaintSelector::setColorAlpha. The method is not called the first time (and the profile name is correct, see comment #17), only the second one. So I'm not sure it's a problem in style.cpp anymore.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers