Created attachment 154073 [details]
"Popular" palette file formats (file types)
I have a design tool that allows to create custom palettes (e.g. from color measurements). The tool can export such palettes in several formats, but LibreOffice cannot import any of those (see attachment).
Created attachment 154074 [details]
ZIP Archive with some palette file formats (Adobe InDesign and Photoshop, Corel Painter, Quark XPress, etc.)
I'm aware of copyright issues and proprietary file formats (Adobe most likely), as well as the color-handling deficits in LibreOffice (makein cxf unusable, most likely), but some primitive format as the Corel Painter one should be easy to do (and be free of patents due to simpleness) (see attached ZIP with samples):
R:251, G:191, B:013 Leuchtendgelb
R:255, G:173, B:058 Leuchtendes Orangegelb
R:189, G:217, B:014 Leuchtendes Gelbgrün
You'll remember support for .ase is already provided (bug 84002)  --except we don't do CIE-LAB colors so your .ase when placed in the share/palette directory will give black swatches.
Conversion of the RGB color values for the Corel .color palette is a simple text edit to change to .soc
The other palettes you list also look to be CIE-Lab space, or CMYK which would not come in directly, needing internal conversion to RGB to be used.
Otherwise do not see this a appropriate. Use an external tool to build to RGB/sRGB palette and format as .SOC (or .SOG) we can consume it then.
Likewise GIMPs .gpl palettes (in RGB) are also parsed  into our color picker when place in the share/palette directory.
 The ~PaletteGPL methods of https://cgit.freedesktop.org/libreoffice/core/commit/?id=cfdefe488fedbd12f7a3daf578c889ef82e962fc
(In reply to V Stuart Foote from comment #2)
> You'll remember support for .ase is already provided (bug 84002) 
> --except we don't do CIE-LAB colors so your .ase when placed in the
> share/palette directory will give black swatches.
I did not know, also because help finds nothing for "import color".
> Conversion of the RGB color values for the Corel .color palette is a simple
> text edit to change to .soc
Also having to manipulate some files in the profile directory is not what I'd call "importing a palette". Why not add some UI (and help text) for that?
> The other palettes you list also look to be CIE-Lab space, or CMYK which
> would not come in directly, needing internal conversion to RGB to be used.
Agreed, I don't know that details of internal color handling in LibreOffice.Is it sRGB or completely uncalibrated?
> Otherwise do not see this a appropriate. Use an external tool to build to
> RGB/sRGB palette and format as .SOC (or .SOG) we can consume it then.
See above on UI and help text. In addition help knows nothing about ".ase" or "ase". So how should the user know?
>  https://gerrit.libreoffice.org/#/c/14661/
(In reply to V Stuart Foote from comment #3)
> Likewise GIMPs .gpl palettes (in RGB) are also parsed  into our color
> picker when place in the share/palette directory.
As said for "ASE", the help does not know anything related about ".gpl", "gpl", or "GIMP". So how should the users know?
(In reply to Ulrich Windl from comment #4)
> > when placed in the share/palette directory
> I did not know, also because help finds nothing for "import color".
Had a "heated" discussion about this with MikeK at the LibreOffice conference. My POV is that very seldom needed functions clutter the UI and impacts usability (more things to learn, to maintain, to translate...). We removed the ability to load/save color palettes some years ago in favor of extensions. (I created one to export the user palette.)
Mike's position is that features don't hurt and even a few users that rarely use it should be able to accomplish tasks. And it's up to UI/UX to place controls in a sane way.
My take: Nothing to say against more accepted formats but I disagree with explicit interactions.
(In reply to Heiko Tietze from comment #6)
> (...) My POV is that very seldom needed functions clutter the UI and
> impacts usability (more things to learn, to maintain, to translate...).
If memory serves me right it was in LO 4 when the dialogs became "big and almost empty", making me wonder why to waste so much screen space (in the meantime they were re-filled a bit). So my point of view is that an UI done properly can handle more feature than an UI done poorly without overloading the user.
UI design is very much a matter of taste, but I noticed that some (personal opinion follows) important features were dropped, some less needed (Avoiding "useless") features were added, and some really bad "design solutions" were kept (like the only palette available in Tools->Options: Well hidden and the least important palette IMHO).
So leaving all taste aside: I still think importing and exporting palette files in some well-documented formats is a useful thing to have. The "average day user" probably never defined a new color or changed on in a palette, so that user probably wouldn't ever see the "complicated UI" you are afraid of.
I would simply vote +1 for implementing importing(exporting) palettes. It is useful.
So some +1 and some -1. Up to the interested developers.