Created attachment 101316 [details] LibreOffice '.odg' file showing recommended color palette The current color palette used by LibreOffice is not reproducible across a range of display monitor brands, types and settings (e.g. LCD vs. CRT), printer brands, types and settings (e.g. laser vs. ink jet) and software type (e.g. native LibreOffice '.odg' vs. 'pdf'). Recommend using the standard color palette shown in the attached file: <RgbColorVectors_18JUN2014.odg> Page 1 shows the color palette; page 2 shows the mathematics used to generate the palette; page 3 shows two representative color wheels. The advantage of this color palette is that it is independent of display monitor, printer and software technology. This is the same color palette that many manufacturers use to test their products. It will never go obsolete so long as 256-bit RGB color vectors are used. The attached document has been placed into the public domain. Operating System: All Version: 4.1.6.2 release
enhancement request. status NEW
Perhaps same request as Bug 42159 or Bug 37480. Or hex color picker: Bug 44366
(In reply to comment #2) > Perhaps same request as Bug 42159 or Bug 37480. Or hex color picker: Bug > 44366 No, it's not the same request. This bug is regarding the default color palette.
(In reply to comment #0) > Created attachment 101316 [details] > LibreOffice '.odg' file showing recommended color palette > > The current color palette used by LibreOffice is not reproducible across a > range of display monitor brands, types and settings (e.g. LCD vs. CRT), > printer brands, types and settings (e.g. laser vs. ink jet) and software > type (e.g. native LibreOffice '.odg' vs. 'pdf'). > > Recommend using the standard color palette shown in the attached file: > <RgbColorVectors_18JUN2014.odg> Page 1 shows the color palette; page 2 > shows the mathematics used to generate the palette; page 3 shows two > representative color wheels. > > The advantage of this color palette is that it is independent of display > monitor, printer and software technology. This is the same color palette > that many manufacturers use to test their products. It will never go > obsolete so long as 256-bit RGB color vectors are used. That's true, and it's also incredibly easy to implement. However, I'm thinking the reason that it's not used is because the colors aren't very pleasant to look at (at least the fully saturated colors can be quite an eyesore). There's also a lack of light options. Those are just my initial observations, though -- it'd be good to see some research on this. Could you make an example document showcasing these colors? I'd be especially curious about how well they work in charts.
Created attachment 104569 [details] Version compatibility problems with color palette on OpenOffice The OpenOffice drawing file showing examples of how the color palettes changed between version 3.4.1 and 4.0.1.
Created attachment 104570 [details] Standard color palette that I've adopted for my documents This is the standard color palette that I've adopted for my documents. My documents are heavily used by electronic engineers, and so it's based on the electronic color code, where the numerals '0' - '9' are assigned a color.
Created attachment 104571 [details] A document example showing how I use colors This is a document in '.pdf' format that shows how I use my color palette.
@ Mirek2 "example document" The color palette I proposed is intended to solve device compatibility and software longevity issues. It's an objective compromise to a solve a problem that is inherently subjective to every person. It will always be necessary to allow a user to make his or her own colors. In fact, it is doubtful that any two graphic artists would agree on the best choice of colors. For example, the color brown is almost impossible to match between devices. If you have to use brown, then you will probably need to adjust the color mixture so that it looks good on your monitor. However, be prepared to have your 'brown' look more orange or red on other devices. I've attached some examples for your consideration: < OpenOfficeColorPalette_08DEC2013.odg > shows color palette compatibility problems between different versions of OpenOffice. < StandardColorPalette_06MAY2014.odg > shows the standard color palette that I've adopted in my line of work. I wouldn't expect others to like it, as it's intended to be used by electronics engineers. < WbBridge_28MAR2012.pdf > shows a '.pdf' example of a document that I created in my line of work. These documents sometimes take two or three years to complete, so any change of color palette during revision changes is annoying.
Created attachment 104623 [details] Spreadsheet for generating color vectors of a specified greytone A LibreOffice Calc '.ods' (spreadsheet) file for generating color vectors of a specified greytone. Instructions are provided inside the spreadsheet. This spreadsheet has been injected into the public domain.
Talking points about a color palette organized according to gray scale (a.k.a. gray tone, or luminance contrast): 1) In the human visual system, color recognition is secondary to gray scale recognition. The following quotes from Marmor and Ravin (2009) describe the role of color during visual processing in the brain: “Thus, the color information has already been segregated from the more basic (evolutionarily older) mechanisms of perception, which are effectively color-blind. The bottom line is that we need luminance (brightness) differences to optimally recognize shapes, faces, depth, and movement.” (p. 55) “To summarize, color alone will not function effectively to represent objects (or depth), unless it also provides realistic luminance contrast. Most representational artists recognize light and dark aspects of the paintings accordingly, such as in Raphael's Renaissance painting 'A Lady with Unicorn'.” (p. 57) 2) The most common form of color blindness is a red-green color deficiency, and is typically found in men. These people tend to see colors as shades of blue and yellow. According to Marmor and Ravin (2009): “Red-green color deficiency affects 8 to 10 percent of males, so it is not uncommon.” (p. 88) 3) People with a color deficiency tend to rely on gray scale color recognition. According to Marmor and Ravin (2009): “Because colors are less subjectively intense, the color-deficient person – and artist – tends to be more sensitive to subtle lights and darks which may be obscured by colors that distract our attention (as in camouflage).” (p. 89) “When asked about colors in the countryside, he [Jens, an artist with a red-green color deficiency] responded: 'Well mostly these are known, and my mind tells me one thing and my eyes another. Essentially I am seeing a lot of contrast. I like things with contrast in them.'” (p. 90) 4) Ansel Adams, a well-known American landscape photographer who worked exclusively with black-and-white images, relied on the 'Zone System' for his photographs. This system divided an image into eleven (11) gray tone levels between black and white. 5) Many people print color images on black-and-white printers. 6) Many technical artists design their images so that they can still be useful (recognizable) when printed on black-and-white printers. 7) A color palette organized according to a gray tone scale is the easiest way to mentally convert a color image to a monochrome image. This allows the graphic artist to more easily design color works that will still look good when printed on a black-and-white printer. Cite: Marmor, Michael F. and James G. Ravin. The Artists Eyes : Vision and the History of Art. Abrams, 2009. ISBN: 978-0-8109-4849-5
Regardless of whether this proposal becomes the default palette I do feel it would be good to have this tonal / standardised palette available. The percentage naming (rather than subjective naming) of hues is much clearer and important for the role this palette fulfills e.g., "64% Magenta" vs "Magenta 4". Excellent work Wade. Thank you for sharing. Very interesting. (In reply to comment #4) > There's also a lack of light options. I agree, but attachment 101316 [details] indicates a subtractive rather than additive approach to creating a palette i.e., emulation of CMYK using RGB. In simple terms this is why it works the way it does in practice. This is a specialised palette targeting interoperability that I feel would be a great asset to LO.
Could you create a .soc palette with 10 columns (see color picker design: https://redmine.documentfoundation.org/attachments/download/138/color-picker.png) based on your calculations? That way people could get a feeling for it and decide if it would work well as default palette.
(In reply to comment #12) > Could you create a .soc palette with 10 columns ... The colour picker was changed in v4.2 (bug 67653) to use 12 columns (to bring it in-line with AOO) and under v4.3 and v4.4 it still uses this layout. To get similar tonal values aligning in columns (for this specialised palette) will require additional filler swatches.
@Krisztian, you've been deeply into this code of late for your GSOC project. Any thoughts?
Created attachment 105105 [details] SOC example, using fillers for missing values (In reply to comment #13) > The colour picker was changed in v4.2 (bug 67653) to use 12 columns (to > bring it in-line with AOO) and under v4.3 and v4.4 it still uses this > layout. To get similar tonal values aligning in columns (for this > specialised palette) will require additional filler swatches. Here is a thrown together example SOC file. I have made the additional filler swatches (at bottom) as dark as possible to ensure they are clearly distinguishable from the above palette values. Each filler swatch is also named in an abbreviated manner for clarity. Note that instead of "Gray" I have used "White" for the monochromatic series as a pale grey being labelled as "90% White" seems clearer than "90% Gray". I have also placed the monochrome series at top, in order to make it easier to distinguish Black and the darker grey swatches from the filler swatches.
Created attachment 105106 [details] Screenshot of color picker using the provided SOC.
@ Owen Genat "screenshot of color picker" (In reply to comment #16) > Created attachment 105106 [details] > Screenshot of color picker using the provided SOC. I think you're close. It would work better if the grey scale tones between BLACK (0% grey) and WHITE (100% grey) were aligned with the color grey scale values. If you choose the same values that were in my chart it would mean 12 rows and 13 columns (or, alternatively 13 rows and 12 columns if you do in the other direction). My diagram uses twelve (12) color vectors plus grey, but you could go with 3, 6, 12, 24, 48, etc. You can see the idea better if you print out your color picker on a black and white laser printer. That's something akin to how a person with a color deficiency might see them, too. The lighter tones for all the colors should line up with the corresponding grey tone. That will give the color deficient person, as well as the graphic artists designing colors for B&W printers, a fighting chance to make their documents look good. In fact, I use the color palette to evaluate laser printers. For example, a Xerox Phaser 5500 produces a substantially different grey tone pattern (and color rendition) than a Lexmark M1145. I don't know for sure, but I suspect this might be because of their toner powder or their color calibration. Also, most of the laser printers are weighted toward the blue end of the scale. That means that blues turn out black. That's not done on purpose; its a problem for them -- a remnant of their technology. I'm looking at the standard color palette in much the same way as television color bars. In fact, I'll most a comparison so that you can see how that works.
Date: 22 AUG 2014 From: Wade D. Peterson, Silicore Corportion To: File Subj: Comparative analysis using television color bars Subject: comparative analysis between television color bars and the proposed grey scale color palette. Description: this is a comparative analysis. It describes how a television color bar standard is applied in the broadcast television industry. This is not a proposal; rather it's a way to compare and contrast the proposed grey scale color palette to a similar technology used in another field. Talking points: 1) Color bar test patterns are used in the broadcast television industry as a quality control tool for the purpose of calibrating people, equipment and systems. For example, they are used to align color television sets. 2) There is a Wiki at: http://en.wikipedia.org/wiki/Color_bars 3) An example is the EG 1:1990 “Alignment Color Bar Test Signal for Television Picture Monitors”. It is published by The Society of Motion Picture and Television Engineers. A free pdf archive document can be obtained by accessing: http://standards.smpte.org/, and then doing a search for “color bars”. [I can't post it myself on this thread because of copyright violations]. Find “EG 1:1990” in the list; you should be able to download it at no cost. Note: this is an older analog TV standard that they now make available at no charge. 4) Figure 2 of the EG 1:1990 shows the how the alignment color bars are documented in a standard. This standard is used for the NTSC television signal. 5) The exact colors such as “YELLOW”, “GREEN” or “RED” are not explicitly shown. Instead, they represent saturated electronic signals. 6) The color bars are generally broadcast in conjunction with a 1,000 Hz audio tone. This allows the volume level and audio distortion to be calibrated too. 7) In preparation for a television show, the 'bars and tone' (as they are known) are first broadcast from the studio. Technicians monitor the signal at various points along the signal path. This includes camera equipment; amplifiers; microwave links; cabling; television transmitters; receivers and TV sets. 8) The bars and tone are used in two different ways, depending on the equipment. A color bar ‘card’ is used to align television cameras. The camera is focused on the standard (printed) card, and the output signal is inspected with an oscilloscope to see if it’s capturing the correct colors in its output signal. A color bar ‘pattern generator’ is used to align the rest of the television network. The pattern generator produces a standard color signal, which is then connected to the TV network. Technicians throughout the network inspect their signals with an oscilloscope and calibrate their equipment accordingly. 9) The EG 1:1990 is copyrighted by The Society of Motion Picture and Television Engineers. 10) Colors themselves are not offered copyright protection in the United States, or the rest of the world under the Berne convention. 11) A pattern of colors is copyrightable (much like a color photograph) so long as it expresses an idea, and it takes some level of originality to create it. The Courts sometimes use the “sweat of the brow” test to determine this. That is, if it took some “sweat of the brow” to make it, then copyright protection is afforded. 12) The Society of Motion Picture and Television Engineers (SMPTE) has an intellectual property policy statement at: https://www.smpte.org/sites/default/files/SMPTE_IP_Policy_2013-08.pdf 13) Section 9.3 of the SMPTE policy is the Copyright Policy. It says: “The Society shall own the copyrights of all Engineering Documents and Registered Disclosure Documents, whether in draft or published form.”
(In reply to comment #17) > I think you're close. It would work better if the grey scale tones between > BLACK (0% grey) and WHITE (100% grey) were aligned with the color grey scale > values. If you choose the same values that were in my chart it would mean > 12 rows and 13 columns (or, alternatively 13 rows and 12 columns if you do > in the other direction). My diagram uses twelve (12) color vectors plus > grey, but you could go with 3, 6, 12, 24, 48, etc. Thanks for clarifying the naming of the monochrome scale. It is not going to be possible to change the layout of the colour picker from 12 to 13 columns, so we are going to have to use a row-per-hue (rather than column-per-hue) layout for this palette if all the scales are to run in the same direction. This is actually simpler for palette creation as a hue > tone (rather than tone > hue) order in XML entries makes more sense IMO. Most palettes tend to have a greater number of hues than tones. (In reply to comment #18) > 2) There is a Wiki at: http://en.wikipedia.org/wiki/Color_bars Here in Australia we use the PM5544 (PAL) test pattern: http://en.wikipedia.org/wiki/Testcard ... in place of the NTSC one, which you indicate later under point (4). > 3) An example is the EG 1:1990 “Alignment Color Bar Test Signal for > Television Picture Monitors”. [...] Find “EG 1:1990” in the list; you should > be able to download it at no cost. Note: this is an older analog TV standard > that they now make available at no charge. I can see the entry in the search list, but it does not appear to be free (US$50.00 showing here). Standards that are not freely available make it more difficult for others to implement. Many documents have author / publisher copyright but are still made freely available. This applies to points (9) and (12) also. A patent is a much more significant issue than copyright, although I sincerely doubt a palette in different arrangement. > 10) Colors themselves are not offered copyright protection in the United > States, or the rest of the world under the Berne convention. LO can use generic colour names, e.g., "58% Magenta" or "Pinkish-purple 123". Branded colour names are however only likely to be usable under license, e.g., "Pantone 630 C". This issue would not appear to affect this palette but IANAL.
Created attachment 105128 [details] SOC palette using rows instead of columns. Here is a reorganised version of the previous SOC file. Each column now aligns with a percentage saturation value. The monochrome scale has been renamed as requested but still sits at the top. Filler swatches have been renamed for greater consistency, with a new initial entry (0%) that is dark and higher entries (50%+) that are now pale.
Created attachment 105129 [details] Screenshot of color picker using row-based SOC. Relates to attachment 105128 [details].
(In reply to comment #19) > > 3) An example is the EG 1:1990 “Alignment Color Bar Test Signal for > > Television Picture Monitors”. [...] Find “EG 1:1990” in the list; you should > > be able to download it at no cost. Note: this is an older analog TV standard > > that they now make available at no charge. > > I can see the entry in the search list, but it does not appear to be free > (US$50.00 showing here). Standards that are not freely available make it > more difficult for others to implement. Many documents have author / > publisher copyright but are still made freely available. This applies to > points (9) and (12) also. A patent is a much more significant issue than > copyright, although I sincerely doubt a palette in different arrangement. That’s interesting. I was able to download the EG 1:1990 standard for free. The copy I received had a copyright notice (plus surplusage) that reads: “Downloaded by guest on 2014-08-20 from IP 71.216.229.113 @ SMPTE All Rights Reserved.” I did a reverse lookup on the IP address from mxtoolbox.com, and it showed my correct location of 44.98 -93.2638 (Hennepin County Library in Minneapolis, Minnesota USA). -Wade
(In reply to comment #21) > Created attachment 105129 [details] > Screenshot of color picker using row-based SOC. > > Relates to attachment 105128 [details]. Greytone organized from left to right is okay with me. Congratulations Owen! From what I can tell, you're now the proud parent of the world's first internationally recognized color palette standard which is organized by greytone! -Wade
(In reply to comment #19) > A patent is a much more significant issue than > copyright, although I sincerely doubt a palette in different arrangement ... would be affected. I forgot to finish this sentence.
This pre-dates the rework of the color picker, now it is much easier to add external palettes. For the moment, we do not want to include this palette as the default, but happy to add it as an alternate one. It is enough to add the .soc file to extras/source/palettes/ and add it to extras/Package_palettes.mk Wade: Do you think you can create a patch for this, and push it to gerrit? https://wiki.documentfoundation.org/Development/gerrit
Migrating Whiteboard tags to Keywords: (easyHack DifficultyBeginner TopicUI) [NinjaEdit]
(In reply to Jan Holesovsky from comment #25) > This pre-dates the rework of the color picker, now it is much easier to add > external palettes. Right. Removing EasyHack status for now, as there is quite a bit of discussion, ambiguity and complexity in this (as witnessed by > 20 comments). Also moving this to UNCONFIRMED/ux-advise for now. And with that, just leaving: http://www.evolutionarydesigns.net/blog/2010/08/27/color-palette-generators/ here too, which links various online palette generators, that might either be used for inspiration or integration.
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
Back to NEW, we need a decision here. I like the idea of mathematically generated colors. But we should also think about cleaning up what we have. * cmyk: 216 unnamed colors in tiny steps that looks like a replacement for the rgb input * gallery: 61 colors w. gray scale, yellow to red, pink to violett, light blue to dark blue, green, brown/ocker; unnamed * html: 131 colors similar to "gallery" but finer grained; strangely named like "ghostwhite F8F8FF 248.248.255" * libreoffice: the branding colors + black & white; with (improvable) names * palette: 77 darker red, green and blue colors; unnamed * scribus: 545 named colors, guess for compatibility * standard: Symphony based palette in 10x12 colors plus "nice", pale and chart colors; well named * tango: 27 named colors from tango * web: 232 unnamed greenish, reddish and blueish colors (document, + user, + recently used) (named = "Red" instead of "255,0,0") So my suggestion is: * remove cmyk, gallery, html, palette, web * add this "tonal" palette here, when the names are improved (design only easyhack), but also add Breeze colors (https://community.kde.org/KDE_Visual_Design_Group/HIG/Color)
(In reply to Heiko Tietze from comment #29) > So my suggestion is: > [...] Maybe an idea to ping people that worked on the various previous changes?
Having an "html"-palette is not bad and the names are not "strangely", see the definitions in https://www.w3.org/TR/css3-color/, section 4.3. Extended color keywords But we need to verify, that the values and names are really exactly as standardized in CSS (and SVG). And they should not be translated, because they are keywords.
(In reply to Cor Nouws from comment #30) > Maybe an idea to ping people that worked on the various previous changes? Pinged Christoph and KJ. Not sure who else (Astron perhaps, but at least Tin Man has changed priorities; talked to him in Brno). (In reply to Regina Henschel from comment #31) > Having an "html"-palette is not bad and the names are not "strangely", see > the definitions in > https://www.w3.org/TR/css3-color/, section 4.3. Extended color keywords When I stated 'unnamed' the text is "10-255-76" or "100%24%4%" or "255,44,76". The X11 colors are nice, thanks for the reference.
(In reply to Heiko Tietze from comment #32) Hi all, > So my suggestion is: > * remove cmyk, gallery, html, palette, web > * add this "tonal" palette here, when the names are improved > (design only easyhack), but also add Breeze colors > (https://community.kde.org/KDE_Visual_Design_Group/HIG/Color) I actually erased those palettes from my config folder. The point that they have no "natural" name isn't the only problem but they are also cluttered. Furthermore, I like the smaller color palettes but I found a fault on them: colors look unsorted. Thus, from my user perspective I'd recommend to order in columns (or rows) the colors any palette. For example, in this "tonal.soc", there are some white spaces in order to maintain some consistency with the tones. Any other color palette should > When I stated 'unnamed' the text is "10-255-76" or "100%24%4%" or > "255,44,76". The X11 colors are nice, thanks for the reference. As Heiko already knows, I recently coded an app in Fortran 90 that generates a color palette based on 12 RGB base colors. One could use, for example, the branding LibO colors, or Tango or Breeze, to generate a palette. The way it does it's maybe suboptimal (Tomaž sugested to use HSL instead RGB coordinates) but it works. Of course, more work could be putted on it. For the ones interested, the code is in https://drive.google.com/open?id=0B4KD0YqmpaatRGVlVngyRFgwZ0U and an example screenshot is in: https://wiki.documentfoundation.org/File:Paleta_generada.png Sadly, mi app doesn't name colors other than its position on the matrix (Emphasis 1, 2, etc.). But I've been thinking on how automatically name picked colors. Maybe my head is quite a block, but It's simpler for me to think about RBG coordinates, which are in a cubic space. Thus, one could assign dummy names for specific spaces in the RGB cube. Thus, the name of a picked color inside the space R < 10, G < 10, B < 100 could be something like "Dark blue". Nothing special, of course! And all the space RGB should be covered. But as a result all colors would have a _nicer_ name.
Owen Genat committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6f3bf1cdc48b62caec1e54a6aa6db41b4a56d1c4 tdf#80196 - Standardize color palette using mathematically generated colors It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 128925 [details] layout in columns for better UX in swatch picker @Wade, Owen, * Here is a reworked layout of the palette as .SOC, just copy it into the $ORIGIN/share/palette directory to test. I've reordered this back into a columnar layout, with the gray scale as the top row and then picking up the colors in columns. I've inserted blanks to hold the layout to fit our default 12 column swatch picker. I think this is going to be more visually appealing UI for folks to pick colors while maintaining Wade's technical goal.
Created attachment 128926 [details] clip of suggested tonal_column.soc in the Swatch picker
Created attachment 128927 [details] tonal_row (In reply to V Stuart Foote from comment #35) > I think this is going to be more visually appealing UI... Looks very similar to me, both are really nice. If we go with the column variant I suggest to invert and start with dark colors in order to have less (literally) whitespace by default. Adding a screenshot of the tonal palette in rows for the lazy ones.
(In reply to Heiko Tietze from comment #37) > ... > Looks very similar to me, both are really nice. If we go with the column > variant I suggest to invert and start with dark colors in order to have less > (literally) whitespace by default. No, the whitespace here is actually appropriate for the blank swatches--it represents an sRGB color that would be saturated and clipped as out of gamut for the color space. I've just assigned a default #FFFFFE to each place holder. Also, while the Hue by row presentation includes the 0% and the 91% values (all black) with the columnar layout I've removed them. The only loss is a visual ability to equate gray scale to a Percentage value for a color hue--where the gray scale 0 - 100% aligned over each of the hues. A reasonable trade off to have a clean UI with our limited swatch picker. If the swatch picker could be to enhanced to read a layout value (count of grid columns) from the SOC file and expand to 13 columns--the gray scale could be included as a column.
Created attachment 128928 [details] Wade's original color table normalized by graytone With a 12 column layout we lose the gray scale <--> color hue equivalancy--but note the 0% colors are all the same and the 91% and 100% values are saturated out of the sRGB gamut. Color swatches for those three rows can be omitted for use in the UI.
(In reply to V Stuart Foote from comment #38) > No, the whitespace here is actually appropriate for the blank swatches... Putting whitespace in the top rows makes reduces the usable space. Inverting the palette and starting with dark colors at top provides more space to usable colors.
(In reply to Heiko Tietze from comment #40) > Putting whitespace in the top rows makes reduces the usable space. Inverting > the palette and starting with dark colors at top provides more space to > usable colors. But completely looses the beauty/utility of the palette--white at top for out of gamut colors is _functional_, not decorative! This full palette is visible in the swatch picker and quite functional--reverse the colors and it becomes a mess.
Created attachment 128930 [details] tonal_col (In reply to V Stuart Foote from comment #41) > > But completely looses the beauty/utility of the palette--white at top for > out of gamut colors is _functional_, not decorative! Functional because you have the choice between 20 white? Here is what I mean.
(In reply to Heiko Tietze from comment #42) > Created attachment 128930 [details] > tonal_col > > (In reply to V Stuart Foote from comment #41) > > > > But completely looses the beauty/utility of the palette--white at top for > > out of gamut colors is _functional_, not decorative! > > Functional because you have the choice between 20 white? Here is what I mean. No, functional because the position of the blanks has symbolic meaning to the color table they represent. Fortunately the new Area fill dialog shows the whole palette. But the 12x7 (or 12x8 as yours shows) of the swatch picker crops the color table. With your suggested inverted layout, after the gray scale in the 1st row--the 2nd and 3rd rows of 10% and 20% values are not of much use. It positions the 30% values in the 4th row, while cutting off view of the more useful 73% and 82% level Magenta, Cyan and Yellow. They are less significant/useful colors so invert and position 10% and 20% to the bottom where it does not matter if they are not always visible. The blanks in the upper rows have relative meaning.
The column based color chart based on Wade's original ODG, attachment 101316 [details], is up for review... https://gerrit.libreoffice.org/#/c/31061/
V Stuart Foote committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2bea44c420c3d2dcc55504c3922aea8562a35db8 Revert "tdf#80196 - Standardize color palette using mathematically generated colors" It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
vsfoote committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5c12939540fafb02de2f8c91a3022f9e16a1e38f tdf#80196 - Standardized color palette normalized by graytone It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #46) > vsfoote committed a patch related to this issue. When is it necessary to change Package_palettes.mk? Haven't done it for the other patches from bugs 104053, 104052, 104051, 104050, 104048, and in particular 104047.
Some values are strange or duplicated - I would remove them 100% Grey - #FFFFFF or in other words "pure" black other examples: 82% Blue saturated - #FFFFFE 82% Az saturated - #FFFFFE 82% SG saturated - #FFFFFE ... This values are black (or just one value from black) and duplicated and: 65% Green saturated - #FFFFFE 65% Red saturated - #FFFFFE ... black - but 65% saturated? I don't think so.. this is strange
(In reply to Heiko Tietze from comment #47) > (In reply to Commit Notification from comment #46) > > vsfoote committed a patch related to this issue. > > When is it necessary to change Package_palettes.mk? Haven't done it for the > other patches from bugs 104053, 104052, 104051, 104050, 104048, and in > particular 104047. I think this is needed for packaging. If you don't specify this the palettes won't be copied to share folder and won't be available in the installation.
(In reply to Tomaz Vajngerl from comment #48) > Some values are strange or duplicated - I would remove them > Tomaž, please review attachment 101316 [details] -- what I've done here is provided placeholders in our 12 column swatch picker that retains the hue based columnar layout of the source color table. Each column shows a single color hue in increasing graytone (e.g. reduced black) scale. While the row based alignment might have been more complete (keeping the graytone scale values aligned with the corresponding color values, it required a lot more "place holders" and wasn't the best UX, nor visually appealing. Without the placeholder--or if the a single color value has the same label--the swatch picker currently removes the color swatch and destroys the chart like layout achieved. I took the names/labels for the colors from the Wade and Owen Genat's work--where labeling each hue with its graytone percentage is obvious. But the color abbreviations for the place holders are a little wonky. Violet -> Vi, Azure -> Az, Spring Green -> SG, Chartreuse Green -> CG, Orange -> Or and Rose -> Ro but they have to have distinct labels. No reason not to give them a label appropriate to the color column they represent--so keeping the percentage and the color and add saturated. Each could have a more concise label, even drop saturated as Heiko suggested. First round I'd just labeled each "Saturated", but the swatch picker filters them out that way--and each would have to have a different color to use the same label. > 100% Grey - #FFFFFF > > or in other words "pure" black you of course meant "white", and the place holders are blanked to white as well (#FFFFFE) to represent them as "saturated" since the hue couldn't be shown nor represented in sRGB. I suspect that with the way some of the "dark" DE inverting the whites and blacks you might be confused.
Ah, OK - I understand now. Would be nice if we wouldn't need placeholders but yeah.. that's not possible ATM.
could change the name from tonal_column.soc to tonal.soc and maybe adjust the abbreviations if folks really object. Otherwise this is in place. Version: 5.3.0.0.alpha1+ Build ID: 0de1b34a89a5bafa87a031da7e53e902ec14312c CPU Threads: 1; OS Version: Linux 4.4; UI Render: default; VCL: gtk2; Layout Engine: new; TinderBox: Linux-rpm_deb-x86@71-TDF, Branch:master, Time: 2016-11-22_11:44:11 Locale: en-US (en_US.UTF-8); Calc: group
renamed to tonal.soc and adjusted abbreviations https://gerrit.libreoffice.org/#/c/31136/
(In reply to V Stuart Foote from comment #53) > renamed to tonal.soc and adjusted abbreviations > https://gerrit.libreoffice.org/#/c/31136/ OoGamut? Wouldn't 'saturated' be adequate? Or at least without the "Oo".
Actually looked around for how palette folks refer to "Out of gamut" warnings. Some hyphenated, some italicized but no standard and technically here we are not saturated in sRGB--but "out of gamut" for this tonal palette, so abbreviated.
(In reply to V Stuart Foote from comment #55) > Actually looked around for how palette folks refer to "Out of gamut" > warnings. Then we should write it out. Worst case is "73% Char Green (Out of Gamut)" or "73% Chartreuse Green (Out of Gamut)". This will likely not crash the display manager.
V Stuart Foote committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=98419425080f58880f2d0d85749a4a55e8abb40b tdf#80196 - another attempt at renaming to tonal.soc and adjusting names It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
V Stuart Foote committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=792d7d29688a0273f346a9baa23d415a7f8f55d8&h=libreoffice-5-3 tdf#80196 - rename palette to tonal.soc and adjusting names It will be available in 5.3.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Gabor Kelemen committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=50a210d48b7db47eaaafeb5520bd796d8e690346 tdf#105000, related tdf#80196: Make new color names translatable It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #59) > Gabor Kelemen committed a patch related to this issue. >... This patch moves the percentage from the beginning of the color names to the end, like from "83% Green" to "Green 83%". This was necessary for the upcoming localization of color names.
Gabor Kelemen committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8901c7c7bc4db5076a615ef942af6fb65e943ee3 tdf#105000, related tdf#80196: Make new color names translatable It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Gabor Kelemen committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=11d0e4d946950204fd9f1d23f206b91e8326388e&h=libreoffice-6-0 tdf#105000, related tdf#80196: Make new color names translatable It will be available in 6.0.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.