Created attachment 127028 [details] screenshot So the gradient tab of the area dialog has a field labelled 'border' which according to the help is to 'Enter the amount by which you want to adjust the area of the endpoint color on the gradient. The endpoint color is the color that is selected in the To box'. ODF has this feature in the draw:border attribute, which is why it must be labelled like this, but users wont be able to understand it, so i'd like to get input on what we can use instead. From what i can visually see, this value sets where along the gradient fill path the start/from color will begin transitioning to the end/to color. So maybe 'Transition point' would be good.
"Transition point" sounds good to me (not making it clearer to the user, though). Any objection from the l10n team, Sophie, or documentation, Olivier? If not I guess you can patch yourself :-).
Just checked Indesign (https://helpx.adobe.com/indesign/using/gradients.html) who call it 'midpoint', maybe it's more easy to understand than 'transition'? I'm not sure but both are ok for me anyway :) - thanks for your work Jay! Sophie
Or just "Offset" like GIMP.
(In reply to Yousuf Philips (jay) from comment #0) > Created attachment 127028 [details] > screenshot (...) > From what i can visually see, this value sets where along the gradient fill > path the start/from color will begin transitioning to the end/to color. So > maybe 'Transition point' would be good. Measured by color picker in a figure with a gradient applied, the border is the line where the transition starts. Before the border line, the color is constant. So maybe "Transition start line", "transition begin line" "start of (color) transition"
Dear Yousuf Philips (jay) (retired), To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Yousuf Philips (jay) (retired), To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
There is still no new wording.
*** Bug 143282 has been marked as a duplicate of this bug. ***
We discussed the topic in the design meeting. "Border" could become "Distance to edge". But we don't see much issue for Start/End value (or rather no advantage of changing this label). Rather some tooltips would help users. Border/distance: "Defines the distance to the edge of the area where the gradient of the transparency starts. The border area itself will take the transparency from the edges of the gradient." Start/end value: "Percent of transparency at which the gradient starts/ends" This is an easyhack. "Border" in gradient tab of the area style at cui/uiconfig/ui/gradientpage.ui and for the transparency tab it should be cui/uiconfig/ui/transparencytabpage.ui
(In reply to Heiko Tietze from comment #10) > We discussed the topic in the design meeting. > > "Border" could become "Distance to edge". Not specific enough, "Border" always refers to "Start". But we don't see much issue for > Start/End value (or rather no advantage of changing this label). Rather some > tooltips would help users. Only 'Start' is relevant. > > Border/distance: "Defines the distance to the edge of the area where the > gradient of the transparency starts. The border area itself will take the > transparency from the edges of the gradient." ... from the start of the gradient. For color gradient it would be "take the color from the start of the gradient"
(In reply to Regina Henschel from comment #11) > Not specific enough, "Border" always refers to "Start". Since border can be a frame occupying some space the term distance is sound more clear. > Only 'Start' is relevant. Don't get this. > For color gradient it would be "take the color from the start of the > gradient" Yes, we must be careful with the transparency vs area UIs.
(In reply to Regina Henschel from comment #11) > Only 'Start' is relevant. *If* I understand it correctly, you imply that border always gets the transparency value of "start". No, that is wrong; the value of border's transparency is one of the outermost part of the gradient - and that depends on the gradient kind.
(In reply to Mike Kaganski from comment #13) > (In reply to Regina Henschel from comment #11) > > Only 'Start' is relevant. > > *If* I understand it correctly, you imply that border always gets the > transparency value of "start". No, that is wrong; the value of border's > transparency is one of the outermost part of the gradient - and that depends > on the gradient kind. You are right. I forgot that "axial" is the other way round and uses the end color/transparency. But the problem remains, that "distance to edge" does not say in case of "linear" which edge is used.
(In reply to Regina Henschel from comment #14) > But the problem remains, that "distance to edge" does not say in case of > "linear" which edge is used. In theory, yes. But OTOH "Linear" gradient may be considered to only have two edges - at orthogonal directions to the axis (line) of the *linear* gradient. OTOH, I would love to have terminology/wording improved; just I'm bad in creating UI strings :)
FTR: as I mentioned on the call, my vision of improving the situation would be not creating a better wording (easier to implement, but harder to come with a short and correct and clear wording), but creation of: 1. Tooltips appearing on hover - allow to include more information; 2. Dynamically changing preview with some indication of affected area appearing on hover/activation of a relevant control (be it a shadow, or some arrow(s)...)
(In reply to Mike Kaganski from comment #16) > FTR: as I mentioned on the call, my vision of improving the situation would > be not creating a better wording (easier to implement, but harder to come > with a short and correct and clear wording), but creation of: > > 1. Tooltips appearing on hover - allow to include more information; Can the tooltip depend on the chosen gradient type? > 2. Dynamically changing preview with some indication of affected area > appearing on hover/activation of a relevant control (be it a shadow, or some > arrow(s)...) A more informative preview would be good. In the transparency page is lot of space for additional parts, but the color gradient page is glutted.
(In reply to Regina Henschel from comment #17) > Can the tooltip depend on the chosen gradient type? Yes. https://opengrok.libreoffice.org/xref/core/sw/source/ui/fmtui/tmpdlg.cxx?r=2633d5f9#82 shows setting both normal tooltip (set_tooltip_text), and extended tooltip (set_accessible_description) at runtime.
Considering the past comments, I'd like to add the following, "Border" in this case means the point from the initial color when the final color is applied, this is valid in linear and other types. So, some suggestions from Olivier, back in 2017, still applies, just without "line" word, I believe. "Transition start" or "Transition begin" would be great ideas to start.
I think midpoint is the best replace I assign task to my self and I'm going to change it
Ali_Abdollahian committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5e7663b792ee1d56838d7a5082e5c29867f839f2 tdf#101731 Rename gradient border label to midpoint It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Apologies for reopening, but I think the choice of "midpoint" is incorrect, based on a misunderstanding and makes the situation worse. The InDesign "midpoint" mentioned in comment 2 is where both colours are at 50%, whereas the setting we are talking about here (at least for linear gradients) is where the transition starts leaving the 100% "From" colour. (Meaning everything before that is 100% the From colour.) Furthermore, the label was not changed for the Transparency tab. In my opinion, something like "Transition start" would be a lot more accurate and informative, and follow-up commits could add the customised tooltips for each gradient (e.g. differentiating if it relates to the "from" or "to" colours) + any necessary documentation fixes that are required.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/660b7ed484efcac1e5b841e0b04f3c9628578448 Resolves tdf#101731 - Rename Border/Midpoint It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Adolfo Jayme Barrientos committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/19d11c7d7f6bccc9bc10ab599721dc7c8e69646b Revert "tdf#101731 Rename gradient border label to midpoint" It will be available in 7.5.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The name is now "Transition start" in both Area dialog > Gradient tab and Transparency tab: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2eefb695c0bfd00abd22e17e64ab2a1692fe2af4 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Name was already "Border" in: OpenOffice.org 3.3.0 OOO330m20 (Build:9567) Thanks Heiko!
Stéphane Guillou committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/08418f863745757cc8074db7addf4812170dc21b tdf#101731: change "Border" to "Transition start" in gradient settings