As discussed in bug 80196 and in http://nabble.documentfoundation.org/quot-LibreColour-quot-palettes-for-LibreOffice-td4200043.html streamlining the palettes is needed. The LibreColor palette (more fancy name than CIE-HLC) would be a valuable addition.
Spent some time in Scribus 1.5.2 and downloaded and installed the OCSC CIE HLC palette (via Windows -> Resources -> Palettes category). Not so sure this should be a palette to adopt as a replacement LibreOffice standard.soc in whole. Yes it has application for reproducible color management for desktop publishing support, but the HLC colors are rather muted--and the palette lacks handling of the primary colors. Folks will find it too muted and not the best sRGB color space coverage. Still it would be a useful palette to bundle, and perhaps provide some mechanism for import of the OCSC libary of palettes to LibreOffice. Some technical issues on using the CIE HLC in LibreOffice. As noted, would need to resolve how to label each color swatch to show in its tool-tip popup. Any freieFarbe / freeColour naming in Deutsch would have to be translated--or maybe better drop any color names and depend on the swatch viewer alone (similar is done now for a few of the palettes--where for some reason naming for cmyk uses CMY, and gallery uses CMYK) -- but which sRGB (decimal or HEX) or CMYK (decimal)? And, if moving forward with an HLC based model, it is appropriate/necessary to rethink grid layout for the swatch display. Currently we use 12 columns--chosen to hold black, white and our 10 increments of gray1 - gray10. Something like the HLC tables organized by Hue 000 -> 360 into 36 tables, would need to go into a 9 column layout, with divider between the Hues--and the table would need to describe swatch blanks for colors outside the sRGB color space. Download Owen G.'s tonal_row.soc (attachment 105128 [details] from bug 80196) to $ORIGIN/share/palette and you can see challenge of the swatch view being fixed number of columns. Also, since each swatch from a palette will be shown on opening the color picker, the color picker widget currently has no support for an HLC CIE LAB color reference. Rather, like Scribus, we provide only an HSV (i.e. our HSB panel) based color cylinder representation drawn from sRGB values in the .soc palette. Can conversions showing HLC field be added? =-ref-= https://en.wikipedia.org/wiki/HSL_and_HSV https://en.wikipedia.org/wiki/HCL_color_space http://cscheid.github.io/lux/demos/hcl/hcl.html
In https://gerrit.libreoffice.org/#/c/31025/1 is what Christoph Schaefer prepared.
heiko tietze committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e92f098ae50c6de5f1ca4714cd77eb29e2b591cd tdf#104052 - Add LibreColor palette 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.
Heiko: erm, what? maybe it's wort to check licenses before committing (or in this case: asking to commit stuff? From https://cgit.freedesktop.org/libreoffice/core/commit/?id=e92f098ae50c6de5f1ca4714cd77eb29e2b591cd: diff --git a/extras/source/palettes/librecolour.soc b/extras/source/palettes/librecolour.soc new file mode 100644 index 0000000..e87cfaa --- /dev/null +++ b/extras/source/palettes/librecolour.soc @@ -0,0 +1,1039 @@ +<?xml version="1.0" encoding="utf-8"?> +<!-- dtp studio oldenburg (http://www.dtpstudio.de) --> +<!-- Creative Commons Attribution-NoDerivatives 4.0 --> [...] NoDerivatives? WTF?
I think this should be reverted, and if it isn't until tonight when I am near my ssh key I am going to do that myself.
https://creativecommons.org/licenses/by-nd/4.0/: "NoDerivatives — If you remix, transform, or build upon the material, you may not distribute the modified material." Definitely non-free.
(In reply to Rene Engelhard from comment #6) > https://creativecommons.org/licenses/by-nd/4.0/: > > "NoDerivatives — If you remix, transform, or build upon the material, you > may not distribute the modified material." > > Definitely non-free. That's how it was sent to me. Will ask Christoph to comment here about a normal CC by-sa. The discussion about this palette run on the design mailinglist.
Then you shouldn't have committed it. Blindly putting something in the tree is bad. ALWAYS check licenses BEFORE. (FWIW, I think you know it - but just going sure, mentioning something here is not sufficient either, it has to be changed in the actual file.)
(In reply to Rene Engelhard from comment #8) > Then you shouldn't have committed it. Commit service without the right to change the author and an overseen request do to so was the reason for where we are. Just to mention that the procedure is clear.
no, Heiko, that is irrelevant. *You* have to check the license. Who committed it or who is recorded as the author/committer is totally non-relevant. There might be a procedural problem here but the problem here is that YOU submitted a non-free file for committing. That already shouldn't have happened.
Jan Holesovsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=728c9a0d47b83910c5a9e38ac5c80f34fe3dfe54 Revert "tdf#104052 - Add LibreColor palette" 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.
Heiko: I am sorry, but I've reverted the commit for the moment... Hopefully the author will provide us with a version we can consume - can you please reach out to him? Thank you!
What's the problem with this licence? We (freeColour) discussed the licensing options with an IP lawyer and came to the conclusion that, to guarantee the same outcome on all platforms and the reliability of the physical colour reference in connection with any programme, the ND option is the best. I've had this discussion in other contexts already, and the major concern was that using any of the colours in a document creates a derivative. This is *not* true. Using a colour is what is says: use, which is not limited by the licence. The ND option only serves to guarantee the correctness of the colour values and the related colour codes. You can compare it to an open standard. The ODF spec would be useless if anyone could modify the text and distribute the modified version as an original. It's the same with colours.
> What's the problem with this licence? We (freeColour) discussed the licensing > options with an IP lawyer that is probably the problem. > and came to the conclusion that, to guarantee the > same outcome on all > platforms and the reliability of the physical colour reference in connection > with any programme, the ND option is the best. Your opinion. But it violates the open source Defnition. Remember you are contributing to a open source project (or well, Heiko did). https://opensource.org/osd-annotated So it's not something we should ship. > I've had this discussion in other contexts already, and the major concern was > that using any of the colours in a document creates a derivative. This is > *not* true. Using a colour is what is says: use, which is not limited by the > licence. I didn't claim so. Still you can't modify it. > The ND option only serves to guarantee the correctness of the colour values > and the related colour codes. You can compare it to an open standard. The ODF > spec would be useless if anyone could modify the text But a "random" color palette is not a standard. And saying that, by Debians standards (DFSG, which the OSD is actually based on) standard texts or RFCs are not suitable for Debian main either. Regards, Rene
(In reply to V Stuart Foote from comment #1) > Spent some time in Scribus 1.5.2 and downloaded and installed the OCSC CIE > HLC palette (via Windows -> Resources -> Palettes category). Not so sure > this should be a palette to adopt as a replacement LibreOffice standard.soc > in whole. > > Yes it has application for reproducible color management for desktop > publishing support, but the HLC colors are rather muted--and the palette > lacks handling of the primary colors. Folks will find it too muted and not > the best sRGB color space coverage. > > Still it would be a useful palette to bundle, and perhaps provide some > mechanism for import of the OCSC libary of palettes to LibreOffice. > > Some technical issues on using the CIE HLC in LibreOffice. > > As noted, would need to resolve how to label each color swatch to show in > its tool-tip popup. Any freieFarbe / freeColour naming in Deutsch would have > to be translated--or maybe better drop any color names and depend on the > swatch viewer alone (similar is done now for a few of the palettes--where > for some reason naming for cmyk uses CMY, and gallery uses CMYK) -- but > which sRGB (decimal or HEX) or CMYK (decimal)? > > And, if moving forward with an HLC based model, it is appropriate/necessary > to rethink grid layout for the swatch display. > > Currently we use 12 columns--chosen to hold black, white and our 10 > increments of gray1 - gray10. Something like the HLC tables organized by Hue > 000 -> 360 into 36 tables, would need to go into a 9 column layout, with > divider between the Hues--and the table would need to describe swatch blanks > for colors outside the sRGB color space. > > Download Owen G.'s tonal_row.soc (attachment 105128 [details] from bug > 80196) to $ORIGIN/share/palette and you can see challenge of the swatch view > being fixed number of columns. > > Also, since each swatch from a palette will be shown on opening the color > picker, the color picker widget currently has no support for an HLC CIE LAB > color reference. Rather, like Scribus, we provide only an HSV (i.e. our HSB > panel) based color cylinder representation drawn from sRGB values in the > .soc palette. Can conversions showing HLC field be added? > > > =-ref-= > https://en.wikipedia.org/wiki/HSL_and_HSV > > https://en.wikipedia.org/wiki/HCL_color_space > > http://cscheid.github.io/lux/demos/hcl/hcl.html The HLC colours are "muted" for a reason: They can be replicated in CMYK, so if you are working in a cross-media workflow (web and print) and need a maximum of colour correctnes without resorting to spot colours, this is what you want.
(In reply to Rene Engelhard from comment #14) > > What's the problem with this licence? We (freeColour) discussed the licensing > options with an IP lawyer > > that is probably the problem. > > > and came to the conclusion that, to guarantee the > same outcome on all > > platforms and the reliability of the physical colour reference in connection > > with any programme, the ND option is the best. > > Your opinion. But it violates the open source Defnition. Remember you are > contributing to a open source project (or well, Heiko did). > > https://opensource.org/osd-annotated > > So it's not something we should ship. > > > I've had this discussion in other contexts already, and the major concern was > that using any of the colours in a document creates a derivative. This is > > *not* true. Using a colour is what is says: use, which is not limited by the > > licence. > > I didn't claim so. Still you can't modify it. > > > The ND option only serves to guarantee the correctness of the colour values > > and the related colour codes. You can compare it to an open standard. The ODF > spec would be useless if anyone could modify the text > > But a "random" color palette is not a standard. And saying that, by Debians > standards (DFSG, which the OSD is actually based on) standard texts or RFCs > are not suitable for Debian main either. > First of all, a colour palette is not code, it's content, so the Open Source defifinition doesn't apply here. Second, you can modify the palette. What you can't do is modify it and distribute it under the same name, pretending it's the original version. The colours themselves are (s)RGB values, which means they cannot be protected. Everyone can modify the colour values and distribute a new palette, provided they remove the colour codes (names) and any relationship with fF / fC and the physical colour reference. Third, this is not a "random" palette. It's a colour collection that has been created with a lot of research and testing behind it.
> First of all, a colour palette is not code, it's content, so the Open Source > defifinition doesn't apply here. It's bits and bytes thus it's software thus it has to fullfill the DFSG (read: OSD). That is Debians position. Stuff like this is non-free and would be needed to remove. a nuisance, so I am and will continue fighting against inclusion of this as long as it's non-free. > Third, this is not a "random" palette. It's a colour collection that has been > created with a lot of research and testing behind it. It is. It is a palette done by some people (with or without research is not relevant here) provided by some company. Not a Standard. You started this, not me...
Couldn't this palette be generated at run-time by code? Or be hardcoded as data instead of in a file? Then it would be clearly code (and licensed as such), and also there would be no risk of any clueless individual modifying and redistributing it without renaming it, so both parties in this discussion would be happy. In general, I don't see the point in having separate data files for a few kilobytes of data that is not supposed to be changed. Sure, it takes a bit of more effort to write the code so support hardcoded palettes in the source code, but it could even be an Easy Hack.
(In reply to Tor Lillqvist from comment #18) > Couldn't this palette be generated at run-time by code? Possible for this particular palette but for none of the others. Palettes are usually done to have a set of predefined colors. When your interest is to access a calculated value there is always the option to enter the RGB code. Christoph explained the reasoning behind the LibreColor palette in the mailing list, referenced in comment 0.
> Possible for this particular palette but for none of the others The others, if there similarly is a good idea to make it harder for people to intentionally (or unintentionally) edit the palette, could also be hard-coded in the source code instead of being separate files. (Obviously, any code additions and changes must be licensed the way we want, so it would still be possible to edit the palettes in the source code and recompile, but at least it would be a bit harder.)
(In reply to Rene Engelhard from comment #17) > > First of all, a colour palette is not code, it's content, so the Open Source > > defifinition doesn't apply here. > > It's bits and bytes thus it's software thus it has to fullfill the DFSG > (read: OSD). That is Debians position. Stuff like this is non-free and would > be needed to remove. a nuisance, so I am and will continue fighting against > inclusion of this as long as it's non-free. So a JPEG or PNG file is software? That's news to me. As for Debian's position, I frankly don't care about it. They're "freedom" fundamentalists and remind me of people who insist on talking loudly during a burial ceremony or a piano concerto and rely on their right to free speach. > > > Third, this is not a "random" palette. It's a colour collection that has been > created with a lot of research and testing behind it. > > It is. It is a palette done by some people (with or without research is not > relevant here) provided by some company. Not a Standard. You started this, > not me... Please pay attention and also follow the mailing list discussion. This palette is not provided by a company (although technically it is). The palette is being offered by a non-profit organisation, freieFarbe e.V. The only reason the company is listed as a copyright holder is that the chairman of the non-profit org uses the infrastructure of his former company, which as of now exists only on paper, for the purpose of the non-profit organisation. If it helps, we can change the copyright notice to "freieFarbe e.V.". Moreover, CIE LAB *is* an international standard. The original fans and palettes use CIE LAB and its user-friendly equivalent CIE HLC. The SOC palette for CIE HLC is the RGB version using an sRGB profile to convert CIE LAB to RGB. Finally, let me ask you a question: Would it be fine with you if a competitor of LO (MS, Corel, whoever) crippled this magnificent software and slapped the LO logo on it, just to damage its reputation? I don't think so, and there are rules regarding the use of the LO logo. Does that make LO non-free? Likewise, the *only* reason we chose the ND option for this palette was to prevent mean-spirited users and / or competitors from undermining the reliability of the palette in real-world workflows.
Christoph, a friendly advice from somebody who has been here long enough to notice a trend: It's not worth it to argue with Rene.
(In reply to Tor Lillqvist from comment #20) > > Possible for this particular palette but for none of the others > > The others, if there similarly is a good idea to make it harder for people > to intentionally (or unintentionally) edit the palette, could also be > hard-coded in the source code instead of being separate files. (Obviously, > any code additions and changes must be licensed the way we want, so it would > still be possible to edit the palettes in the source code and recompile, but > at least it would be a bit harder.) That would require a lot of coding, because the underlying colour values are in CIE LAB, so you'd need to create algorithms to convert CIE LAB to HLC, then write an algorithm to create colour incrementals of 10 in CIE HLC, and also skipping "impossible" colours, You'd also need to write code to convert CIE LAB to sRGB using a widely recognised sRGB colour profile, because sRGB doesn't equal sRGB, unfortunately. freieFarbe / freeColour is currently working on the release of the source code of a hitherto closed-source colour software under the GPL v.2. It includes all of the required algorithms, which are also commented. Unfortunately, this takes a lot of time, because the copying and licensing notifications need to be added to every single source file (c. 4000). We also have to create the infrastructure (source code repo, bugtracker, mailing list etc.). In short, it'd be much easier to include the CIE-HLC palette as is.
> So a JPEG or PNG file is software? That's news to me. Yes. We also remove non-free images. > As for Debian's position, I frankly don't care about it. They're "freedom" fundamentalists Yes, we are. And you don't care about free software, otherwise you wouldn't have used ND. Clear position on each side. In that I agree, we have our positions and won't change it. > Finally, let me ask you a question: Would it be fine with you if a competitor > of LO (MS, Corel, whoever) crippled this magnificent software and slapped the > LO logo on it, just to damage its reputation? Ubuntu does that to Debian. While I don't like that it's (partly) free sofware so allowed... > I don't think so, and there are rules regarding the use of the LO logo. Does that make LO non-free? We had that fight already with OOo. There is common sense. And there's a difference between logo copyright and the right to modify. But the exact same nonsense here causes iceweasel vs. firefox and thunderbird vs. icedove, where Debian DID NOT do broken changes but just security updates on older versions and/or building so it integrates into the distro. Yes. And I didn't say about keeping the name. That "renaming" *is* allowed. If ND (then the name is totally bullshit and should be something else saying "don't distribute under the same name") > Likewise, the *only* reason we chose the ND option for this palette was to > prevent mean-spirited users and / or competitors from undermining the > reliability of the palette in real-world workflows. Again, common sense. > and remind me of people who insist on talking loudly during a burial ceremony > or a piano concerto and rely on their right to free speach. No,Saying something somewhere (with exceptions when it becomes criminal) is free speech, but here this is just bad behaviour and disturbing. Again, common sense.
(In reply to Tor Lillqvist from comment #22) > Christoph, a friendly advice from somebody who has been here long enough to > notice a trend: It's not worth it to argue with Rene. Thank you, Tor! I'm new here, and I have no idea who's in charge ;) Christoph
What tml probably meant is what I outlined in my reply, it's definitely not worth arguing with me about that because "you are not allowed to modify" is non-free and I am not going to go away from that standpoint or accept addition of this. if it was ever added and it stayed "you are not allowed to modify" I have the *obligation* to remove it, I don't even have a choice if I thought otherwise. You and tml might disagree; just think of the fact that it actually *was* reverted based on my comment, so I am not absolutely wrong. (I could share (private) IRC snippets supporting this, but I refrain from doing so.)
(In reply to Rene Engelhard from comment #24) > Clear position on each side. In that I agree, we have our positions and > won't change it. Exactly, positions are clear. I will bring this topic onto the table at the ESC. Either we reduce the demands for CC license or publish the palette as an extension. Thank you all for commenting.
Christoph: What would you think if somebody else (like me) (in my own time, this is not something I do paid work for) added the data from that palette as a built-in palette, in the source code, and thus obviously licensed using the usual license combination. Would that be useful? Or would you still then be afraid that somebody goes through the pain of intentionally modifying it and building LO but still uses the same name, and redistributes such a LO?
(In reply to Tor Lillqvist from comment #28) > Christoph: What would you think if somebody else (like me) (in my own time, > this is not something I do paid work for) added the data from that palette > as a built-in palette, in the source code, and thus obviously licensed using > the usual license combination. Would that be useful? Or would you still then > be afraid that somebody goes through the pain of intentionally modifying it > and building LO but still uses the same name, and redistributes such a LO? Tor, there's no problem with your suggestion. Neither RGB nor HLC values as such can be subjects to copyright. Feel free to add the palette to the source code! As I've written before, we only use ND protection to ensure the integrity of the colour values in cross-media workflows, as well as the reliability of the physical colour reference. Thank you very much for your offer!
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=250680f57b74f55071d2431e5941dacffa018be4 tdf#104052: Add LibreColor palette 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 Christoph Schäfer from comment #16) > Second, you can modify the palette. What you can't do is modify it and > distribute it under the same name, That is not what the license says, quoting https://creativecommons.org/licenses/by-nd/4.0/: > NoDerivatives — If you remix, transform, or build upon the material, > you may not distribute the modified material. So redistribution of modified versions is unconditionally not allowed, which makes it non-free software and I’m pretty sure Debian would not be the only distribution having issues with that. I’m guessing you want a license similar to TeX license which allows modification and distribution of modified version as long as they are renamed, unlike CC BY-ND.
(In reply to Commit Notification from comment #30) > Tor Lillqvist committed a patch related to this issue. I'm definitely against this hackish solution. When we start to add parts of our variable artwork into the code we cannot guarantee the expected flexibility. The user will never understand why changing palettes is possible except the LibreColors.
I thought the whole point was that the LibreColors palette is not changeable? Oh well, feel free to revert then.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0183432b6a4080f19711a723b9e2301bb738160c Revert "tdf#104052: Add LibreColor palette" 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 #30) > Tor Lillqvist committed a patch related to this issue. > It has been pushed to "master": @Tor, that was pretty cool, thanks! Unfortunately an issue with the packing of these color swatches into our swatch picker makes this CIE standard palette less useful than it could be. In CIELAB there are 36 Hues, and in HLC notation each hue can be represented as an 8 x 8 grid--with saturated colors assigned place holders. With our 12 column swatch grid in our color picker we loose a lot of the utility of HLC notation because our picker provides for no sense of the palette's layout. We loose the structure and the palette becomes just a bunch of swatches strung together to fill the columns. You can get a feel for it if you review the PDF of the color fan the CIELAB HLC [1]. Each of the 36 color Hue has its own chart, and the charts are relative to each other in sequence. Being able to physically match the fan swatch to a color choice from our swatch picker would be exceptional for folks needing process colors. Not sure exactly how this could be supported--but adding means to structure our palette views would be very helpful, either with a "hard coded" palette as you've provided for LibreColour's HLC, but in general. =-ref-= [1] http://dtpstudio.de/cielab/downloads/hlcfaecher.pdf
(In reply to Khaled Hosny from comment #31) > (In reply to Christoph Schäfer from comment #16) > > Second, you can modify the palette. What you can't do is modify it and > > distribute it under the same name, > > That is not what the license says, quoting > https://creativecommons.org/licenses/by-nd/4.0/: > > NoDerivatives — If you remix, transform, or build upon the material, > > you may not distribute the modified material. > > So redistribution of modified versions is unconditionally not allowed, which > makes it non-free software and I’m pretty sure Debian would not be the only > distribution having issues with that. > > I’m guessing you want a license similar to TeX license which allows > modification and distribution of modified version as long as they are > renamed, unlike CC BY-ND. Hi Khaled, The situation with colours is a bit different from code, so it's not the same licensing issue as TeX. Please let me explain why this palette exists and how it came into being. The most widely used colour system out there is Pantone (actually serveral "systems"). There are others, and all of them are proprietary. The problems with Pantone are countless, and in my opinion it's one of the worst colour reference producers in the market. First of all, the licensing conditions are draconian. You aren't even allowed to compare a Pantone colour to another colour! Second, Pantone colour references are *not* reliable. You can buy three seemingly identical references and get three slightly different colour representations. Third, Pantone has changed the numbering scheme over time and assigned new colours to existing codes, which can lead to confusion in colour communication. Fourth, you can't rely on digital Pantone colour libraries even if they are included in a product from the same vendor. For example, if you're a user of Adobe CC, the Pantone libaries in Photoshop, Illustrator and InDesign aren't identical. From a colour-related point of view Pantone colours aren't even a real colour system, just a random collection of colours. One of the goals of freieFarbe / freeColour is to provide a non-proprietary alternative to Pantone & Co. Since colour is a physical and physiological phenomenon, it can't be protected by copyrights or patents. Hence the idea to create a free colour reference based on CIE LAB. LAB is a colour model that comprises all colour visible to the human eye, and it's used for colour calculations by all professional graphics programmes, including GIMP, Inkscape or Scribus. If you look at the Pantone colour libraries shipped with products from Adobe, Corel or Quark, you'll find that the colours are all stored in LAB, even if the software displays something different. fF / fC created a colour fan using the LAB model for users of programmes that actually allow for working in LAB mode, e.g. Photoshop. This is useful if you want to find out how a display colour will look in print, but it's useless if you want to select a real-world colour and use it in a computer software. So we created another colour reference, using a more intuitive representation of LAB, namely HLC. HLC is to LAB what HSV is to RGB (roughly). It's *very* intuitive, and, having worked with Pantone, HKS and RAL colour references in the past, I never found it easier to find a particular colour on a printed fan than with HLC. The colour reference is (obviously) printed with CMYK colours on high quality coated paper. It's the maximum quality and colour correctness currently achievable with the four process colours. The original digital colour palette uses LAB values to enable precise colour conversion from LAB to various output targets, depending on the respective ICC profile. The RGB palettes for LibreOffice, GIMP et al. have been created using a standard sRGB profile, so what we have here is a subset of LAB, as well as a subset of sRGB, namely all colours that can be reproduced in CMYK (hence the "muted" colours). Unlike TeX, neither the RGB values nor the HLC numbers can be protected by copyrights nor any other rights -- it's just physics and numbers. The only reason we use a licence at all is that a systematic collection of colours like CIE-HLC that refers to a real-world colour fan can be, and we do use copyright and the specific CC-BY-ND licence to prevent users from damaging others. Let's assume someone removes one third of the colours and still distributes the palette under its name. So someone buys the colour fan, relying on the information that all colours on the fan are included in the digital version, but then won't find them. Who will be blamed? The non-profit organisation that wants to liberate colour! Back to Pantone -- better the devil you know etc. Or assume someone modifies the RGB values: Changing R:45 G:50 B: 35 to R:43 G:50 B:35 won't make much of a difference, but changing R to 25 will. The result will be mismatches. Who will be blamed? Likewise, adding colour steps beyond the increments of 10 we chose, e.g., H:220 L:40 C:20 to H:225 L:40 C:20 will result in users not finding the colour in the reference. Who will be blamed? Thus, the only way to preserve the integrity of the palette in connection with the physical fans is to disallow modifications. fF / fC wants colour to be free, but freedom doesn't mean anarchy. Moreover, producing these fans (CIELAB and CIEHLC) in their current quality was really expensive. Members of the initiative spent a lot of their own money to make them a reality (that was before the initiative was recognised as a non-profit organisation) as a contribution to the liberation of colour from companies like Pantone. They don't want their efforts to be sabotaged by others, including companies that don't like competition from a non-profit organisation. If you think Ballmer's Microsoft or McBride's SCO were ruthless and mean, you probably have no experience with some so-called colour vendors! Summary: The colours and the numbers as such aren't and cannot be protected by copyright (unlike TeX), only this particular combination. And the licence's only purpose is to preserve a truly free colour alternative from sabotage.
(In reply to Heiko Tietze from comment #32) > (In reply to Commit Notification from comment #30) > > Tor Lillqvist committed a patch related to this issue. > > I'm definitely against this hackish solution. When we start to add parts of > our variable artwork into the code we cannot guarantee the expected > flexibility. The user will never understand why changing palettes is > possible except the LibreColors. Heiko, I can't see what's wrong with having two standard palettes hard-wired into LibreOffice: one reasonably-sized sRG palette and CIE-HLC. That way, they can be assured to have two standard palettes available that cannot be changed, even by coincidence, which helps to secure colour communication across computers, platforms and workflows. In cross-media workflows that's what you want, and LibreOffice is by far the best office suite in these workflows. I presented LibreOffice plus the HLC palette and the related colour fan to some influential people of Switzerland's publishing scene as a follow-up to a presentation on cross-media publishing two weeks ago. The feedback was very positive, and I've already been notified that some Swiss publishing companies decided to throw out OO.o after these two presentations, or installed LO in addition to MS Office. Safe colour communication is very important here! fF and com2publish will also produce videos to promote LibreOffice as the ideal office suite in cross-media workflows. Having CIE-HLC + an sRGB palette hard-wired into the programme makes it even easier to convince people to switch! The only required addition is an update to the help files. I'd volunteer to write it in English and German.
(In reply to Christoph Schäfer from comment #37) > I can't see what's wrong with having two standard palettes hard-wired into > LibreOffice: You sacrifice consistency, transparency, and flexibility for having one static configuration. Consistency means similar functions behave the same. Palettes can be edited locally, delete, added, have the same naming scheme (i.e. lower case, whoever introduced that) etc. Transparency is not given to the user, she is not able to know why this particular palette behaves differently. And we also loose the flexibility to adjust things, perhaps beyond the layout (Stuart suggested, if I understand right, an internal layout with whitespaces to align the colors), e.g. renaming the palette. Assuming we get the enhanced extension manager, I blogged about recently, there should be not only an option to download palettes (or more general, objects) but also to delete them. People who do not do professional desktop publishing, guess >80%, will hardly use this palette and prefer either what their OS provides (Tango, Breeze, Windows/Azur, and MacOS/Capitain? - the latter are todos) or use the tonal swatch. And finally I care more about Libreoffice branding colors. Why not hard code these colors? <- This is not a question, at least not to me.
(In reply to Heiko Tietze from comment #38) > (In reply to Christoph Schäfer from comment #37) > > I can't see what's wrong with having two standard palettes hard-wired into > > LibreOffice: > > You sacrifice consistency, transparency, and flexibility for having one > static configuration. No. As long as it's possible to create a local copy of the palette, you don't. >Consistency means similar functions behave the same. It also means that basic colours remain the same across installations of the same product. > People who do not do professional desktop > publishing, guess >80%, will hardly use this palette The whole reason for the existence of the HLC SOC palette is that people who *don't* do desktop publishing can safely use these colours in cross-media workflows without risking glaring discrepancies between the colours in a presentation and a printed flier (for example). Do you have any idea about the headaches office files can create for people in design departments, graphics bureaus or printers when it comes to colour and colour consistency? The HLC SOC palette enables users to eliminate these headaches and related costs.
> It also means that basic colours remain the same across installations of the > same product. Yes, and that's why I would have agreed to the code thingy. Heiko didn't want it.. If the file itself with ND ever entered the code (which I don't hope) it will definitely be removed from what many distributions ship. Thus you actually achieve the opposite you wanted. Many people simply won't have that palette in their installs.
(In reply to Rene Engelhard from comment #40) > > It also means that basic colours remain the same across installations of the > > same product. > > Yes, and that's why I would have agreed to the code thingy. > > Heiko didn't want it.. > > If the file itself with ND ever entered the code (which I don't hope) it > will definitely be removed from what many distributions ship. Thus you > actually achieve the opposite you wanted. Many people simply won't have that > palette in > their installs. If it's hard-coded into LibreOffice the ND option goes away and LO can use it under its own licence. I'd only ask for a comment in the code that the colour values and colour codes better not be changed. As I've written before, we only want to protect the integrity of the palette to enable its usage with the freieFarbe colour fans, not restrict users.
For those who don't know what cross-media publishing means and why the integrity of the palette is so important: If you want to publish across all available media, there are two ways you can do it: 1) traditionally with the best results but time-consuming and expensive; 2) in a streamlined cross-media workflow with a little loss of quality, but also at much lower costs and little to no discrepancies in the display of colours. Option 1) means for images to be kept in a large colour space like ECI RGB and then manually adjusted for specific output targets like Web, CMYK print, digital print etc. Fill colours, especially for logos can be spot colours (and often are), which offer a wider gamut than can be achieved by CMYK printing or web colours. Spot colours require an extra printing plate per colour, which makes printing very expensive. There will also be huge discrepancies between professionally printed fliers, brochures etc., the print result on deskjet printers, presentations and the web. With option 2) some brilliance in print and high-definition display systems is being sacrificed to save costs and to minimise the discrepancies between allegedly identical colours in different media. For that purpose the colour gamut is limited to sRGB. Instead of adjusting colours images for each output target, they are simply kept in the sRGB colour space, the only necessary editing being up or downscaling (e.g. for print or web), which can be automated. For fill colours, this means not only reducing the available colours to sRGB but a further reduction to a subset that can be reliably reproduced in CMYK. This doesn't only reduce the time consumed by graphics professionals and hence the related fees, but also the printing expenses (no spot colours involved). Moreover, colour discrepancies between different media and printing methods are negligible. Colours will always be *very* similar. For an office suite like LibreOffice this means that once a "corporate" colour identity has been developed using the "safe" HLC palette and the fF fans, non-designers can use these colours safely for all kinds of colour-related work, including letterheads or presentations. They don't even need the fans (only graphics professionals do). If it's possible to save local copies of the hard-coded palette, a company, non-profit organisation, whatever could also provide a stripped-down version of the HLC palette to its employees with only a subset of colours allowed for colour communication. It took freieFarbe e.V. and its predecessors a lot of time, money and testing in real-world scenarios to create the free fans and the palette, but it was worth it, I believe, because it "just works". HTH
Stuart's comment #35 is very important here (and was something I immediately also thought of when doing my awful ugly C++ hack): the way the swatches in each palette are displayed should depend on the palette. It is counter-productive that every palette is displayed in the same way, as rows of 12 swatches. That makes it hard to find colours that are perceptional close in palettes based on actual perceptional colour models, like the HLC one here. Perhaps we could even have some 3D thing to select colours from a palette, where the shape of the arrangement of swatches (blobs?) depends on the colour model, as device-independent colour spaces after all are three-dimensional. (But sure, I doubt anybody is going to fund any work on improving this. And distributing palettes as extensions containing just .soc files sure won't help.)
(In reply to Tor Lillqvist from comment #43) > Stuart's comment #35 is very important here (and was something I immediately > also thought of when doing my awful ugly C++ hack): the way the swatches in > each palette are displayed should depend on the palette. It is > counter-productive that every palette is displayed in the same way, as rows > of 12 swatches. That makes it hard to find colours that are perceptional > close in palettes based on actual perceptional colour models, like the HLC > one here. Perhaps we could even have some 3D thing to select colours from a > palette, where the shape of the arrangement of swatches (blobs?) depends on > the colour model, as device-independent colour spaces after all are > three-dimensional. > > (But sure, I doubt anybody is going to fund any work on improving this. And > distributing palettes as extensions containing just .soc files sure won't > help.) Absolutely true, but it becomes awfully difficult when palettes are using Hex codes only, and named RGB colours aren't really helpful either, aren't they? With HLC it would be relatively easy, because one could define a grid with each increment of the Hue value using one or several rows (including empty "cells" if there aren't enough colours to fill a row). I'm not sure how to achieve this with a hard-coded rich sRGB palette, though. As for a 3D display: forget it! People aren't used to this kind of thing, and LibreOffice doesn't support LAB. It also doesn't have to, because it's an office suite. The "genius" (it wasn't my idea) of using HLC instead of LAB, LCH or RGB is that it's 1) very intuitive and 2) even if you don't understand the underlying colour model you can still use the simple numbering scheme (000-10-00, 000-20-00 etc.) to find a colour. Agreed on the use of an extension, too, obviously.
(See the discussion at <https://lists.freedesktop.org/archives/libreoffice/2016-November/076004.html> "Allow extensions to provide color palettes" for a potential way of providing this palette as a .oxt extension.)
(In reply to Stephan Bergmann from comment #45) > (See the discussion at > <https://lists.freedesktop.org/archives/libreoffice/2016-November/076004. > html> "Allow extensions to provide color palettes" for a potential way of > providing this palette as a .oxt extension.) Thanks for checking back. We have a color palette, actually a couple of, with some kind of an installer in our repository, http://extensions.libreoffice.org/extension-center/zd-color-palettes. Didn't have time to dig into but likely they do what you suggest.
(In reply to Heiko Tietze from comment #46) > Thanks for checking back. We have a color palette, actually a couple of, > with some kind of an installer in our repository, > http://extensions.libreoffice.org/extension-center/zd-color-palettes. Didn't > have time to dig into but likely they do what you suggest. Ah, interesting. But that one does creative things via some included BASIC code instead. (As I wrote, the "plain" way of providing palettes in extensions will only work in future versions of LO.)
Extensions that involve BASIC code that pokes around in your LibreOffice configuration and/or installation. Sounds legit. At least it is not a hack.
> We (freeColour) discussed the licensing options with an IP lawyer and came to the conclusion that, to guarantee the same outcome on all platforms and the reliability of the physical colour reference in connection with any programme, the ND option is the best. Issue # 1: AFAIK, the degree to which ND permeates the work-product has not been tested in court. Just because the creator intends for No-Derivatives to be limited to the specific colours in this specific colour swatch in this specific file format is no guarantee that a court will rule that way. Distribute it within LibO, and The Document Foundation, EV is at risk of being on the wrong side of a very expensive lawsuit. Distribute it as a third party extension, and let users decide if the benefits outweigh the legal risks. License the entire extension as _CC-BY-ND 4.0 (International)_. Issue # 2: Subsets and supersets. By using an ND license, this group of colours is effectively excluded from being used as the basis for a colour scheme --- any colour scheme. It doesn't matter if the resulting palette is corporate branding, or a party theme. FWIW, I don't see the FreeColour as being the instigator of the lawsuits, but rather, the estate and heirs of FreeColour. Neighbouring rights, greedy heirs, sleazy lawyers, and targets with pockets deep enough to pay, but not quite deep enough to rebuff paying the danegeld. I am not a lawyer. This is not legal advice.
(In reply to jonathon from comment #49) > Issue # 1: AFAIK, the degree to which ND permeates the work-product has not > been tested in court. Just because the creator intends for No-Derivatives to > be limited to the specific colours in this specific colour swatch in this > specific file format is no guarantee that a court will rule that way. > > Distribute it within LibO, and The Document Foundation, EV is at risk of > being on the wrong side of a very expensive lawsuit. Really? How so? freieFarbe e.V. is a non-profit organisation, and it would lose this status immediately if it started lawsuits over promoting open standards. > > Distribute it as a third party extension, and let users decide if the > benefits outweigh the legal risks. There are no legal risks. HLC is just a colour model. > > Issue # 2: Subsets and supersets. By using an ND license, this group of > colours is effectively excluded from being used as the basis for a colour > scheme --- any colour scheme. It doesn't matter if the resulting palette is > corporate branding, or a party theme. > > FWIW, I don't see the FreeColour as being the instigator of the lawsuits, > but rather, the estate and heirs of FreeColour. Neighbouring rights, greedy > heirs, sleazy lawyers, and targets with pockets deep enough to pay, but not > quite deep enough to rebuff paying the danegeld. You apparently have no clue. > > I am not a lawyer. That's quite obvious. I apologise if this sounds condescending, but the old maxim "si tacuisses, philosophus manisses" seems to be appropriate here.
I created an extension bundling the librecolour palette and submitted it to the extensions directory, currently awaiting review. Extension source is here: https://github.com/smehrbrodt/librecolour-extension Can we then mark this as closed?
The extension is cool, thanks Samuel! But before we put this to bed have a technical question for Christoph. Unfortunately, I've noticed there are considerable differences between the sRGB Hex values used in your .soc palette, and the sRGB Hex values indicated on the PDF of the freieFARBE HLCColors fan [1]. Each HLC color I checked, entering the CMYK value in LibreOffice's color picker for the HLC swatch returns the sRGB as indicated for the color on the PDF. Entering your sRGB returns different CMYK. Which are the correct sRGB that should go into a OpenOffice SOC palette? If it is the sRGB from the HLC colorfan, the new extension based on your SOC is not going to match the fans for process color use the way you'd hoped. =-ref-= [1] http://dtpstudio.de/cielab/downloads/hlcfaecher.pdf
(In reply to V Stuart Foote from comment #52) > > Unfortunately, I've noticed there are considerable differences between the > sRGB Hex values used in your .soc palette, and the sRGB Hex values indicated > on the PDF of the freieFARBE HLCColors fan [1]. > > =-ref-= > [1] http://dtpstudio.de/cielab/downloads/hlcfaecher.pdf I agree, it appears that none of the hex values in the pdf match the hex values in the .soc. For example, here is a line from the .soc: <draw:color draw:name="HLC 090 90 60" draw:color="#fde06b" /> The corresponding color on the pdf shows the following information: HLC 090 90 60 Lab 90 0 60 sRGB 253 225 107 * HEX #FDE16B CMYK 0 5 65 0 Notice how for the color name "HLC 090 90 60", the hex values do not match. Though they are very similar, when the colors are placed side by side, they are perceptibly different.
Created attachment 129558 [details] Comparison between hlcfaecher.pdf & LO Writer w/ librecolour.soc This is a screenshot with the hlcfaecher.pdf color swatch on the left, the corresponding color in LO from librecolour.soc in the the middle, and the color in LO using the hex value shown in the pdf, on the right. When the two different hex values are shown side by side in LO, they are not noticeably different on my monitor. Curious why the pdf was noticeably different, I used a color picker to determine the actual color value, which is shown overlaid on the pdf color swatch.
(In reply to Taylor Jenkins from comment #54) > Created attachment 129558 [details] > Comparison between hlcfaecher.pdf & LO Writer w/ librecolour.soc > > This is a screenshot with the hlcfaecher.pdf color swatch on the left, the > corresponding color in LO from librecolour.soc in the the middle, and the > color in LO using the hex value shown in the pdf, on the right. When the two > different hex values are shown side by side in LO, they are not noticeably > different on my monitor. Curious why the pdf was noticeably different, I > used a color picker to determine the actual color value, which is shown > overlaid on the pdf color swatch. Colour pickers aren't reliable. We are aware of minor differences between the sRGB/Hex values in the fans and the SOC files. That's a problem of the algorithms and colour management systems used for the conversion from CIELAB to sRGB. The colour fans have been produced with Photoshop on Windows, hence the values according to Adobe's native CMS. The converter we used to create the SOC files, however, was using littleCMS2, which is much more precise than Adobe's outdated CMS. In practice it doesn't matter much, though, because in RGB values, the deviation isn't huge, one or two digits in one or two channels at most, which is within the acceptable error margin, given the diversity of devices or output targets.
(In reply to Stephan Bergmann from comment #45) > (See the discussion at > <https://lists.freedesktop.org/archives/libreoffice/2016-November/076004. > html> "Allow extensions to provide color palettes" for a potential way of > providing this palette as a .oxt extension.) Hi Samuel, Thanks for your support! We might find another solution, but since you were at it, do you think you could create an Extension that includes the next version of the Open Colour Systems Collection 2.0, a huge collection of mostly commercial colour systems, i.e. 376 SOC palettes? OCSC 2.0 will probably be released during the next few days, and freieFarbe / freeColour would be glad if someone could volunteer to create an Extension with all those CC-licensed palettes. OCSC also has its own logo (SVG).
(In reply to Christoph Schäfer from comment #56) > We might find another solution, but since you were at it, do you think you > could create an Extension that includes the next version of the Open Colour > Systems Collection 2.0, a huge collection of mostly commercial colour > systems, i.e. 376 SOC palettes? Just a heads up re "376 SOC palettes": Look at the ways LO currently presents the set of all available color palettes to the user. A large set size will likely affect usability.
(In reply to Stephan Bergmann from comment #57) > (In reply to Christoph Schäfer from comment #56) > > Just a heads up re "376 SOC palettes": Look at the ways LO currently > presents the set of all available color palettes to the user. A large set > size will likely affect usability. I agree. An extension with this many palettes would need to offer the user the ability to selectively install only the palettes needed.
(In reply to Taylor Jenkins from comment #58) > (In reply to Stephan Bergmann from comment #57) > > (In reply to Christoph Schäfer from comment #56) > > > > Just a heads up re "376 SOC palettes": Look at the ways LO currently > > presents the set of all available color palettes to the user. A large set > > size will likely affect usability. > > I agree. An extension with this many palettes would need to offer the user > the ability to selectively install only the palettes needed. Yes, of course. Would it be possible to create an extension that would allow users to activate/deactivate a palette? Another option might be to split the collection into subsections like "wall paints", "car finishes", "foil colours", "national standards" etc.
FWIW, the previous version of OCSC is still available for download here: http://dtpstudio.de/downloads/OCSC_1_0.zip. It only comprises palettes as SBZ files, which can be loaded into Swatchbooker and Scribus 1.5.2. In v. 2.0 some duplicates have been removed, and ten new palettes were added. I'm only waiting for our busy chairman to finally upload OCSC 2.0 with ZIP archives comprising versions for GIMP, Krita, Inkscape etc. (GPL), Scribus 1.4.x (XML), LibreOffice (SOC), Adobe products (ASE), as well as a plain text version (CLF).
(In reply to Christoph Schäfer from comment #59) > Yes, of course. Would it be possible to create an extension that would allow > users to activate/deactivate a palette? No, there is no infrastructure in the current code to support that.
Created attachment 129704 [details] MPL-licenced HLC palette
Created attachment 129722 [details] an unpacked layout of the CIE HLC palette SOC @Christoph, Before we commit this HLC palette, would you consider adding the blank padding needed to keep the 36 Color wheel spokes (8 rows of Lightness by 8 columns of chroma) in their relative positions. Otherwise packing the SOC into our 12 column picker functionally breaks it. Can either run the 36 spokes of 8 rows down the left edge. Or can run the odd spokes 010 030 050... down left, and evens down right 020 040 060... with reversed order. That is the lowest chroma to the edge, and shift the two blocks by half so the padded space is reduced. Clip of the layout attached.
(In reply to V Stuart Foote from comment #63) > Created attachment 129722 [details] > an unpacked layout of the CIE HLC palette SOC > > @Christoph, > > Before we commit this HLC palette, would you consider adding the blank > padding needed to keep the 36 Color wheel spokes (8 rows of Lightness by 8 > columns of chroma) in their relative positions. > > Otherwise packing the SOC into our 12 column picker functionally breaks it. > > Can either run the 36 spokes of 8 rows down the left edge. Or can run the > odd spokes 010 030 050... down left, and evens down right 020 040 060... > with reversed order. That is the lowest chroma to the edge, and shift the > two blocks by half so the padded space is reduced. > > Clip of the layout attached. I'd be glad to do this -- if you tell me how. Remember that I'm unfamiliar with LibreOffice's internals and created the file using Swatchbooker as a converter.
The SOC file gets read in one color at a time as a 12 column row, so the 13th goes to column 1 of the 2nd row, the 25th to the 3rd row. The padding just inserts a place holder color, probably #fffffe or #000001, and a unique color name, e.g. HLC blank 1, HLC blank 2, HLC blank 3... I would do this with a calc sheet, one draw color name and color per cell, and then then export to CSV. A little clean up of the SOC adding XML stanzas and save as .SOC I can do it if you'd like.
(In reply to V Stuart Foote from comment #65) > The SOC file gets read in one color at a time as a 12 column row, so the > 13th goes to column 1 of the 2nd row, the 25th to the 3rd row. > > The padding just inserts a place holder color, probably #fffffe or #000001, > and a unique color name, e.g. HLC blank 1, HLC blank 2, HLC blank 3... > > I would do this with a calc sheet, one draw color name and color per cell, > and then then export to CSV. A little clean up of the SOC adding XML > stanzas and save as .SOC > > I can do it if you'd like. Yes, please do this. I'd be very grateful. Thanks in advance for your efforts!
(In reply to V Stuart Foote from comment #65) > I can do it if you'd like. Patch with freeecolour-hlc palette is pending at https://gerrit.libreoffice.org/#/c/32116/
heiko tietze committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=765826abcaa441d4d90ffbe75bc3c626c42e639b tdf#87538 New standard color palette, tdf#104052 Add LibreColour HLC palette 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.
Created attachment 129799 [details] the CIE HLC palette in charts by Hue spoke (In reply to Christoph Schäfer from comment #66) > Yes, please do this. I'd be very grateful. Thanks in advance for your > efforts! Attached is a suggested alternative layout in 12 columns with padding to present the CIE HLC sRGB palette in 36 charts by CIE Hue color wheel spokes. In essence the same layout as on the freieFarebe, e.V. color fan. To test, simply add the SOC palette to the share/palette directory and restart LibreOffice. If this layout is preferred, it can replace the traditional packed SOC version that was committed in master for 5.4.0 [1], and possibly be added for 5.3.1 if strongly preferred. @Christoph, I used sRGB values as you'd provided. But just to be sure, are we certain we do not want to instead use the sRGB values for each HLC swatch as listed on the color fan [2], so that we match the physical reference folks might use for their process printing? Stuart =-ref-= [1] https://cgit.freedesktop.org/libreoffice/core/commit/?id=765826abcaa441d4d90ffbe75bc3c626c42e639b [2] http://dtpstudio.de/cielab/downloads/hlcfaecher.pdf
(In reply to V Stuart Foote from comment #69) > ... it can replace the traditional packed SOC > version that was committed in master for 5.4.0 [1], and possibly be added > for 5.3.1 if strongly preferred. It is strongly preferred from my side. I tried to cherry pick for 5.3 but failed due to a merge conflict. No idea where this come from.
heiko tietze committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=89488baf09d2e7580041462b409f587ce43af214&h=libreoffice-5-3 tdf#87538 New standard color palette, tdf#104052 Add LibreColour HLC palette 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.