Bug 127469 - Allow import of color palettes in some "popular" formats
Summary: Allow import of color palettes in some "popular" formats
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Color-Palettes
  Show dependency treegraph
 
Reported: 2019-09-10 10:11 UTC by Ulrich Windl
Modified: 2020-01-05 17:06 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
"Popular" palette file formats (file types) (7.27 KB, image/png)
2019-09-10 10:11 UTC, Ulrich Windl
Details
ZIP Archive with some palette file formats (Adobe InDesign and Photoshop, Corel Painter, Quark XPress, etc.) (24.89 KB, application/zip)
2019-09-10 10:18 UTC, Ulrich Windl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ulrich Windl 2019-09-10 10:11:41 UTC
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).
Comment 1 Ulrich Windl 2019-09-10 10:18:25 UTC
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
[...]
Comment 2 V Stuart Foote 2019-09-10 13:49:16 UTC
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/
Comment 3 V Stuart Foote 2019-09-10 14:53:05 UTC
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
Comment 4 Ulrich Windl 2019-09-12 06:15:04 UTC
(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/
Comment 5 Ulrich Windl 2019-09-12 06:27:51 UTC
(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?
Comment 6 Heiko Tietze 2019-09-12 09:22:50 UTC
(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/
Comment 7 Ulrich Windl 2019-09-12 10:06:47 UTC
(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.
Comment 8 Cor Nouws 2019-09-19 11:53:38 UTC
I would simply vote +1 for implementing importing(exporting) palettes. It is useful.
Comment 9 Heiko Tietze 2019-09-19 12:42:10 UTC
So some +1 and some -1. Up to the interested developers.