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): ROWS 7 COLS 1 WIDTH 140 HEIGHT 30 TEXTHEIGHT 12 SPACING 1 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) [1] --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. =-ref-= [1] https://gerrit.libreoffice.org/#/c/14661/
Likewise GIMPs .gpl palettes (in RGB) are also parsed [1] into our color picker when place in the share/palette directory. =-ref-= [1] 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) [1] > --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? > > =-ref-= > [1] https://gerrit.libreoffice.org/#/c/14661/
(In reply to V Stuart Foote from comment #3) > Likewise GIMPs .gpl palettes (in RGB) are also parsed [1] 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. https://design.blog.documentfoundation.org/2015/12/22/area-fill-options-made-consistent/ https://design.blog.documentfoundation.org/2017/03/29/libreoffice-extension-export-custom-palette/
(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.
Why is it a seldom used feature? Using consistent palettes across different applications is very useful and might be important for business uses when brand colors are enforced. It is extremely frustrating having to manually create a .sog file in a text editor and have to copy it somewhere as a root or write a script for conversions Having a UI option to import a .gpl would be so much better. There is currently no extension allowing to load an external palette in any way. The existing custom palette export extension does not address this problem. Why was such a useful feature removed? I truly hope it is added again. Thanks!
(In reply to servalli from comment #10) > Why is it a seldom used feature? Reality, and we certainly don't have folks clamoring for the feature. How often and common work flows for the suite dictate what areas of the UI needs/gets dev attention. > Using consistent palettes across different applications is very useful and > might be important for business uses when brand colors are enforced. > > It is extremely frustrating having to manually create a .sog file in a text > editor and have to copy it somewhere as a root or write a script for > conversions Two minutes work to stream edit from .gpl to .soc, not seeing an issue. .SOG is the gradient palette--don't think you meant that. > Having a UI option to import a .gpl would be so much better. Why, the .gpl GIMP palettes can already be directly read as palettes in LibreOffice--the color picker is the importer. Otherwise one just needs to copy it from GIMP's share/gimp/2.0/palettes directory to the Libreoffice's share/palette directory. Certainly not a core functional component, but broader palette management remain fertile ground for an extension. Code is welcome. > There is currently no extension allowing to load an external palette in any > way. OK, but it is trivial in any os/DE to edit format for a .soc pallet--and to drop a correctly formatted .SOC file into share/pallete directory.
Have you tried to just load the GIMP palette? Looking at the code it seems possible: void PaletteManager::LoadPalettes() ... if( aFName.endsWithIgnoreAsciiCase(".gpl") ) pPalette.reset(new PaletteGPL(aFileStat.getFileURL(), aFNameWithoutExt)); else if( aFName.endsWithIgnoreAsciiCase(".soc") ) pPalette.reset(new PaletteSOC(aFileStat.getFileURL(), aFNameWithoutExt)); else if ( aFName.endsWithIgnoreAsciiCase(".ase") ) pPalette.reset(new PaletteASE(aFileStat.getFileURL(), aFNameWithoutExt));
(In reply to Heiko Tietze from comment #12) > Have you tried to just load the GIMP palette?... Correct, the palette just needs to be copied to the share/palette directory and it will appear for use in the Color Picker.
(In reply to V Stuart Foote from comment #13) > Correct, the palette just needs to be copied to the share/palette directory > and it will appear for use in the Color Picker. Actually I would not call that "import": Import is when you open a file with some file selector, and then it's converted to the native format.
(In reply to Ulrich Windl from comment #14) > Actually I would not call that "import": Import is when you open a file with > some file selector, and then it's converted to the native format. Loading/saving of palettes requires effort from developers and, more relevant, occupies UI. That is either space for buttons or (context) menu entries. Adding controls for very rarely used functions is detrimental to usability, requires documentation, and maintenance. Back when we introduced the new area style UI with a different approach to palettes we deliberately decided against an option to save the user palettes but created an extension https://extensions.libreoffice.org/en/extensions/show/custom-palette-eport.
Hi, in 2024 is this point of view will evolve ? Some users ask for built-in custom palette.