Writer does not let one specify transparency levels for full-color backgrounds (table cells, text background, text highlighting) This is unfortunate, since text colors are usually too strong for large areas (and force to change the text color from black to white for legibility). But one needs to coordinate backgrounds and text to get a pretty document, and the easiest way to do so is just to apply some transparency level to text colors when used as backgrounds. It is not convenient to open a separate app all the time to compute lighter colors.
Sounds fair. NEW.
Adding needsUXEval keyword to start discussing how can be implemented. I support the idea and suggest some hasty considered ideas: - Is transparency technically possible for all other fill commands beside shapes and paragraphs according to the odf specification? (@Regina) - Transparency slider (only for solid fill) with percent combo box in all color picker widgets as it's implemented in the Area content panel of the Sidebar's properties tab. | | O Custom Color | |---------------------------| | Transparency | | --------|------- 50 % + - | ----------------------------- - In places where transparency commands are already available (like the Area content panel in the Sidebar) this slider in the widget should be disabled to not duplicate existing neat and more user-friendly arranged(*) commands. - Adding a Transparency tab in the Character dialog (for Highlighting) and Table Properties dialog (for background filling) as it's done in the Paragraph dialog today. - The Transparency tab in the Paragraph dialog needs some love and should copy the arrangement of the commands as it exists in the Gradient sub-tab of the Area tab. *) The transparency slider in the color picker widget is a 'auxiliary construction' for me as it demands two actions from the user in the same dialog which closes itself: 1. User opens the widget and clicks at a color. 2. Use opens the widget again and adjusts the transparency slider.
(In reply to Thomas Lendo from comment #2) > - Is transparency technically possible for all other fill commands beside > shapes and paragraphs according to the odf specification? (@Regina) > There exists fo:background-color for characters, paragraphs, text sections, frames, page bodies, headers, footers, tables, table rows and tables. The background-color is a solid RGB-color or total transparent. RGBA color is not allowed. LibreOffice had implemented filling with gradient, hatch and transparency in some places, violating ODF, see bug 103602 and bug 94768. There is ongoing discussion how to extend the standard; only for page backgrounds it is solved in the meantime. Transparency is currently not possible in ODF in a way you want to provide it in the UI. (In reply to Nicolas Mailhot from comment #0) > It is not convenient to open a separate app all the time to compute lighter > colors. You can use the color palette "HTML", which has a lot of pale colors. Or you use the "pick" tool from the Color tab of the dialogs. There you can easily reduce the saturation. For a character background click on "Custom Color". First click on "Hue" and set the color, then click on "Saturation" and make it pale. I doubt, that you need transparency. Transparency makes only sense, if you have something, which should show through it.
According to Regina's explanation, RGBA (RGB color space with an alpha/transparency channel) isn't allowed in ODF today and also not in the upcoming version 1.3. A change of the ODF specification will need several years. Since we already violate the specification, we should avoid to violate it again and we should developers point to other issues that can be described in ODF. I'll close this bug as WONTFIX. But if it's possible in ODF, we should reopen the bug.