When documents are created in other applications that permit a user to select colors with any rgb value, when these documents are opened in LibO, its hard to deal with them in the Area, Colors, Line and Gradient tabs. I opened attachment 83059 [details] in impress for bug 84205 and the frustration of dealing with custom colors is quite apparent. In its master slide, there is a parallelogram with the color RGB[85,85,85] but if you open the area properties dialog, in the area tab, you will see the color isnt listed in the color list but the color is shown in the color preview box. Then switching to the colors tab, you have the option to add the color to your color list, which of course i wouldnt want to do as i'm not using this color outside of this document. But if you switch back to the area tab, the color black is selected and is shown in the preview. In slide 1, you have 3 thin orange lines, which if you open the line properties dialog, the orange color is listed in the color drop down, but it has no label and there isnt a means to modify this custom color as there is no color tab. Also on slide 1, there is a gradient rectangle with colors from #dddcd0 to #262626, and when you open area properties, the area tab has tango green preselected. Then switching to the gradients tab, the from and to drop downs have the color in them with no labels and there is no means to modify these custom colors or even know what their RGB values are. So to solve this problem, the first thing that needs to be done is that all custom colors in a document have to be temporarily added to the color list with their RGB, and also possibly their hex value, as their label. Also custom gradients will need to be added temporarily to the gradient list. With these to fixes, the color or gradient in will be listed in the Area tab. The second step needs to be a means of adding a custom color temporarily to the color list by means of a color picker, and this facility being available next to drop down color lists found in the Area, Gradient and Line tabs. I'm setting this to critical-high as colors are a core functionality and there isnt a way around this issue.
Jay, *, Sorry, but this is an import filter interoperability issue for (admittedly needed) better handling Microsoft color mappings, gradients and word art on import to corresponding LibreOffice ODF format. The issue is not a problem with native LibreOffice color handling, it is not a bug--rather an enhancement--and is certainly not critical as there are no substantive issues when creating original content in LibreOffice ODF. The original document attachment 83059 [details] is a MS Office 2007 generated .pptx in ECMA-376 XML, not even OfficeOpen XML, and frankly there are more substantive issues with its import filter layout result than loss of color mapping of bug 84205 during round trip. Believe there can be similar issues of dealing with color mappings inside SVG, EMF+, WMF, EPS, any of the numerous raster formats, or even other functional ODF generators--but those also are handled with filters--both import or export. As you suggest, the structure of import filters to handle custom color mappings for document elements probably should be improved. How to do that is better left to a motivated developer. Stuart
Created attachment 108042 [details] sample file (In reply to V Stuart Foote from comment #1) > Jay, *, Hi Stuart, > Sorry, but this is an import filter interoperability issue for (admittedly > needed) better handling Microsoft color mappings, gradients and word art on > import to corresponding LibreOffice ODF format. I do agree with you that this needs to be fixed within the import filter, but disagree that this is not an interoperability issue. > The issue is not a problem with native LibreOffice color handling, it is not > a bug--rather an enhancement--and is certainly not critical as there are no > substantive issues when creating original content in LibreOffice ODF. No this problem will arise just within LibO, like if a user created a custom color/gradient in a ODF file and sent it to another LibO user who didnt have that custom color/gradient on his/her system. In the Area dialog's color or gradient tab, there isnt any easy means of change the custom color/gradient, as can be tested in the sample file. This is a problem of LibO restricting users from being able to create/modify custom colors from color related dialog tabs and drop down lists. With the introduction of a new color picker in bug 37480, i'm hoping the custom color picker dialog code might be possible to reused in such situations.
Created attachment 108044 [details] attachement ODT rendered on LO4331 Jay, *, Not sure where you were going with the attachment 108042 [details] .ODT. It Opens without issue in LO 4331 writer. And its draw:gradient "style" value of "Some @#$% gradient" renders correctly and structure seems to match the thumbnail.png for the document you created. Although the gradient is not being rendered in the thumbnail preview--Kendy? <draw:gradient draw:name="Some_20_@#$%_20_Gradient" draw:display-name="Some @#$% Gradient" draw:style="linear" draw:start-color="#663332" draw:end-color="#968751" draw:start-intensity="100%" draw:end-intensity="100%" draw:angle="600" draw:border="0%"/> As I said, Color is not too much of an issue for native LibreOffice ODF component documents. On going work on the color pickers may cause some ripples as we normalize the pallets and GUI--especially where there are enum list definitions of color. For interoperability with MSO and other ODF generators, color charts and styles that have to pass through import/export filters to other external formats will likely always remain an issue. Stuart
> > <draw:gradient draw:name="Some_20_@#$%_20_Gradient" draw:display-name="Some > @#$% Gradient" draw:style="linear" draw:start-color="#663332" > draw:end-color="#968751" draw:start-intensity="100%" > draw:end-intensity="100%" draw:angle="600" draw:border="0%"/> > Meant to include that the start and end colors in the styles.xml are easily changed by directly editing the colors hex value in the XML--outside the edit session. Or by picking an existing gradient style while editing.
Created attachment 108048 [details] Area dialog gradient tool So it would be a nice enhancement if the area dialog gradient tool gave direct hex colors for each--named colors & gradients are nice, but direct colors would be more effective for interoperability.
(In reply to V Stuart Foote from comment #3) > Jay, *, Stuart, > Not sure where you were going with the attachment 108042 [details] .ODT. It > Opens without issue in LO 4331 writer. Yes it does open correctly as it was created with LibO. > And its draw:gradient "style" value of "Some @#$% gradient" renders > correctly and structure seems to match the thumbnail.png for the document > you created. Although the gradient is not being rendered in the thumbnail > preview--Kendy? Yes it does render correctly. Filed the start center thumbnail bug when i was doing my previous reply (bug 85181). :D > As I said, Color is not too much of an issue for native LibreOffice ODF > component documents. On going work on the color pickers may cause some > ripples as we normalize the pallets and GUI--especially where there are enum > list definitions of color. I provided a native LibO ODF document with custom colors/gradients and its not easy to modify these custom colors with LibO. This was to illustrate that this isnt an interoperability issue. That main issue of this bug is that LibO cant handle custom colors properly.
As suggested in comment 2, this does also affect LibreOffice originated documents. In ODF documents, details of the start and end color of any fill gradient are not revealed to the Area dialog color GUI. Details are only fully exposed as stanzas in the styles.xml for the ODF document as draw:start-color= and draw:end-color= with corresponding start and end intensity settings. In the GUI, the Area dialog currently contains a gradient tab which exposes the gradient configuration recorded in the styles.xml--but important details of the gradient's style can not be efficiently manipulated in the existing GUI. The GUI does not expose the "display-name=" field of the Style as editable text. And the colors are rendered as nameless/valueless color swatches. It would be a very useful enhancement to configure the new color picker GUI to open and manipulate the color values across all tabs of the Area dialog. And on save, to write those details back to the styles.xml of the ODF document. Colors not on the pallet in use would render as custom colors on the color picker (either with color Hex value, or named equivalent where matched) and be recorded by Hex value back to the styles.xml for portability of the document. And guess it would make sense to record the custom gradient and colors into the user profile either in registrymodifications.xcu or more likely with the other pallets in LibreOffice/4/user/config Additionally being able to expose and adjust Area style colors with the new color picker would help with the import/export filtering and improve interoperability with other ODF and graphics programs.
*** Bug 100416 has been marked as a duplicate of this bug. ***
This is being fixed in bug 94551.
Unfortunately Rishabh didnt get to replacing the old color drop down list with the color picker widget during GSoC.
*** Bug 91158 has been marked as a duplicate of this bug. ***
With the new color dialog you will get the hex values at the solid colors. And the document colors are also listed properly, at least in Writer. So if there is an issue I would report it in a new ticket.