The semi-transparent text feature [1] has the control on the Font Effects dialog page [2]. The control allows entries from 0 to 100%, but for 100%, the result is that the text is not transparent, and re-opening the dialog after setting 100% gives 0%. Having transparency of 100% could be useful, e.g. for the text that needs to be invisible, but occupy space. This is different both from making its color white (which would make the text visible on non-white text, esp. gradients/bitmaps/etc.), and from making it hidden (which makes the text not occupy space, with following data moving up when printing). However, if there is a reason to disallow 100% transparency, then the control needs to be adjusted to not allow entry of 100%. [1] https://wiki.documentfoundation.org/ReleaseNotes/7.0#Writer [2] https://help.libreoffice.org/7.2/en-US/text/shared/01/05020200.html?DbPAR=WRITER#hd_id0123200902243377
(In reply to Mike Kaganski from comment #0) > [2] By the way, the help page says: > The value 100% means entirely transparent So it seems that at least help authors assumed that 100% is possible :)
confirm in Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: ac80ec817eb07c77a51bc0729985a473c734182e CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: threaded
Just check what Word does, the intention is that the behavior is consistent with Word.
Created attachment 174530 [details] Some transparency in text Word behaves as expected for transparency 100%. The attachment has "psu" in the first paragraph set to 100% transparency, which is blank in Word, and is not transparent in Writer.
Thanks, that would be indeed nice to fix.
Issue reproduced in: Version: 7.0.6.2 Build ID: 144abb84a525d8e30c9dbbefa69cbbf2d8d4ae3b CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Version: 7.5.0.1 (X86_64) / LibreOffice Community Build ID: 77cd3d7ad4445740a0c6cf977992dafd8ebad8df CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded and a master build from today: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8ae84bb5566e12df64236a116b9d1889d6f5f052 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
Trying to understand a bit alpha and transparency (the "T" that we encounter in Color definition), I read in include/tools/color.hxx that T = 255 - alpha Full transparency means T=255 so alpha = 0 I'm not sure but this location seems a good start: https://opengrok.libreoffice.org/xref/core/cui/source/tabpages/chardlg.cxx?r=52ba1fea#1548 Noticing "&& aColor != COL_AUTO" in 2 conditions, I searched about COL_AUTO definition and found 2 constants for a same color: 447 inline constexpr ::Color COL_TRANSPARENT ( ColorTransparency, 0xFF, 0xFF, 0xFF, 0xFF ); 448 inline constexpr ::Color COL_AUTO ( ColorTransparency, 0xFF, 0xFF, 0xFF, 0xFF ); See https://opengrok.libreoffice.org/xref/core/include/tools/color.hxx?r=925c05ee#456 what's the point? Reading include/tools/color.hxx, why to put: 169 /** Is the color transparent? 170 */ 171 bool IsTransparent() const 172 { 173 return GetAlpha() != 255; 174 } instead of: 169 /** Is the color transparent? 170 */ 171 bool IsTransparent() const 172 { 173 return T != 0; 174 } https://opengrok.libreoffice.org/xref/core/include/tools/color.hxx?r=925c05ee#169 Is it because we prefer thinking with alpha notion instead of transparency notion? Noel: considering all the work you did about transparency, put you in cc if you've got some opinion here. Of course don't hesitate to uncc yourself if not interested.
(In reply to Julien Nabet from comment #7) > Trying to understand a bit alpha and transparency (the "T" that we encounter > in Color definition), I read in include/tools/color.hxx that T = 255 - alpha > > So there are a couple of different issues at play here. (1) The old libreoffice code mostly worked in terms of transparency, but modern graphics APIs all use alpha, so we have been slowly moving things to use alpha, so that less conversion is necessary. > 448 inline constexpr ::Color COL_AUTO > ( ColorTransparency, 0xFF, 0xFF, 0xFF, 0xFF ); > (2) Some parts of the system unfortunately use a magic color (COL_AUTO) to mean "pick the correct color magically", which is very unfortunate, because sometimes a valid color is confused as COL_AUTO.
(In reply to Noel Grandin from comment #8) > (In reply to Julien Nabet from comment #7) > > Trying to understand a bit alpha and transparency (the "T" that we encounter > > in Color definition), I read in include/tools/color.hxx that T = 255 - alpha > > > > > > So there are a couple of different issues at play here. > > (1) The old libreoffice code mostly worked in terms of transparency, but > modern graphics APIs all use alpha, so we have been slowly moving things to > use alpha, > so that less conversion is necessary. Ok so transparency will be for the UI (so users are not lost) but internally we want to deal with alpha. > > > 448 inline constexpr ::Color COL_AUTO > > ( ColorTransparency, 0xFF, 0xFF, 0xFF, 0xFF ); > > > > (2) Some parts of the system unfortunately use a magic color (COL_AUTO) to > mean "pick the correct color magically", which is very unfortunate, because > sometimes a valid color is confused as COL_AUTO. Ok but COL_AUTO is equal to COL_TRANSPARENT and both are white + fully transparent. Is there some plan to get rid of one of them or we need to keep them both? Also when typing some text, I suppose white + fully transparent is equivalent to white + fully opaque in non dark mode but, in dark mode, I expect they differ. The first one would give text in black (and so we can't see it), the second one some text in white text. If it's the case and if we need both constants unchanged, perhaps we'd need 2 other constants: COL_AUTO_DARK_MODE COL_TRANSPARENT_DARK_MODE both defined with: ( ColorTransparency, 0xFF, 0x00, 0x00, 0x00 );