use the percentage at the gradient window for transparency and not for amount of blackness (I think this would make more sense) Although the overall transparency would be effected by this. So if the overall transparency is set to 0% and the gradient transparency (atm blackness) is set to 50% this would mean that the shape would be still transparent.
Created attachment 79162 [details] image showing the values are ment
Please provide detailed steps, including location of dialogs. It helps triage the bug a lot if you do: Steps: 1. 2. 3. 4. Observed: Expected: A lot of us know a lot about LibreOffice but we don't know everything so detailed steps help QA as well as devs look at problems. For this one in particular I am concerned about two things: a) people who use this feature are comfortable with the current setup b) any document saved currently with this setting enabled will see a different result if we change what occurs within the code.... Marking as NEEDINFO, once you provide steps and a clear explanation of what you observe and what you expect, mark as UNCONFIRMED. Thanks for helping us!
Created attachment 79272 [details] explanation1
As in the image explanation1 one can see, B and C looks similar (had no time to make them looking the same). So one could create the same image like in B (where the blackness value was set to 50%) without using the blackness value (like C in image explanation1). At the moment if you want to set the transparency of one colour for the gradient you can't do that. So by idea was instead of creating another Spinboxes one could use these spinboxes(for the "blackness) to set the transparency of the gradient colours. I know that images created using the "blackness" values would look different (specially when the shapes with gradients has other shapes underneath) but I think this feature wasn't used that much (my opinion (I never used it)) and one should think about that istead of creating extra spinboxes for the transparency.
Hello ilikebigbugs, *, I am still not sure, what you want to reach ... :( If you change the gradient like shown in your picture, you can still change to the Transparency tab and change the transparency there ... ;) I for myself would do it w/ LO Version: 4.1.0.1 Build ID: 1b3956717a60d6ac35b133d7b0a0f5eb55e9155 as well as with Version 4.0.4.2 (Build ID: 9e9821abd0ffdbc09cd8c52eaa574fa09eb08f2) ) under Debian Testing AMD64 ... ;) If you have something other in mind, please be as exactly in your description as possible ... ;) Sorry for the inconvenience Thomas.
I think this request does not make sense at the moment. As at the moment one only can set a gradient of two colors, one can set the transparency of the color in the "Transparency tab" (as you told). I was thinking of setting the transparency of every color of a gradient. So when the gradient would support more than two colors, there would be no possibility to set the transparency of each color in the "Transparency tab".
Hello ilikebigbugs, *, (In reply to comment #6) > I think this request does not make sense at the moment. does that mean, you want to close it? > As at the moment one only can set a gradient of two colors, one can set the > transparency of the color in the "Transparency tab" (as you told). OK > I was thinking of setting the transparency of every color of a gradient. > So when the gradient would support more than two colors, there would be no > possibility to set the transparency of each color in the "Transparency tab". But maybe it would be feature request than (if at all ... ;) I think, LO is not a fully featuredgraphics editor like the gimp or inkscape or the like. To fulfil your request would mean to enhance it as such and I am the opionion, we shouldn't. But maybe I am wrong here ... ;) Thanks for your reply Thomas.
> But maybe it would be feature request than (if at all ... ;) I think, LO is > not a fully featuredgraphics editor like the gimp or inkscape or the like. > To fulfil your request would mean to enhance it as such and I am the > opionion, we shouldn't. But maybe I am wrong here ... ;) That's also my problem. At the moment there is active development on the svg-import so maybe the multiple color gradient will be added in the future. (As the import of svg files with "multiple color gradient" already seams to work (in the latest snapshots of LO/AOO)) I leave it up to you guys what to do with this report. I have no problem when you close or set it to enhancement.
As indicated in the comments this bug appears to have suffered from a lack of clarity. The inclusion of the term "replace" in the title also suggests a major change, as transparency and opacity are both required for interoperability reasons. What follows is my understanding, based on comment #0, comment #4, and comment #6 of what this enhancement was asking for. This and the final response in comment #8 are my rationale for marking this bug as RESOLVED INVALID. A gradient is any change from one hue (e.g., red) to another (e.g., blue). LO only allows transparency against the entire gradient e.g., red @ 75% transparency to blue @ 75% transparency. This enhancement request appears to be asking to set independent transparency values for a gradient e.g., red @ 60% transparency to blue @ 30% transparency. Another way of thinking about this is to allow a separate gradient for the transparency e.g., 60% to 30% that applies to whatever hue is in use. Neither ODF or OOXML appear to cater for this type of definition from what I understand. A gradient for a rectangle has this type of style (styles.xml): <draw:gradient ... draw:start-color="#ff0000" draw:end-color="#0000ff" draw:start-intensity="100%" draw:end-intensity="100%" ... /> ... start / end colour and start / end intensity i.e., opacity. Transparency is then applied as direct formatting (content.xml) against this style: <style:style style:name="gr1" ... > <style:graphic-properties draw:fill="gradient" ... draw:opacity="50%" ... /> </style:style> ... <draw:rect draw:style-name="gr1" draw:text-style-name="P1" draw:layer="layout" svg:width="5cm" svg:height="5cm" svg:x="2cm" svg:y="2cm"> <text:p/> </draw:rect> This request would seem to be asking for transparency start / end attributes in the style e.g., draw:start-transparency and draw:end-transparency. This would be highly irregular as transparency is uniformly applied (both in ODF and OOXML). Only opacity offers separate start / end values. For interoperability reasons I feel changing this would cause problems.