Created attachment 108617 [details] a simple illustration (screenshot) if you have a comment inserted in the document, and if you want to change the font color, the button from the toolbar does NOT work ... so, you have to go: menu/format/character ... and then you can change the color ... NOTE #1: it's of minor annoyance, I didn't even realize so far that you can actually change the font color in the notes ... but now that I know, I'd be happy to use this and I guess other people might think like that too .) cause it's a nice way to emphasize some part of the note... NOTE #2: highlighting could be considered to made active too :)
Repro -> NEW enhancement. Win 7 64-bit Version: 4.4.0.0.alpha2+ Build ID: b021b5983c62e266b82d9f0c5c6d8d8900553827 TinderBox: Win-x86@39, Branch:master, Time: 2014-11-12_01:10:08 Ubuntu 14.10 64-bit Version: 4.4.0.0.alpha2+ Build ID: 5bff4b016c4b44f4123e0e6a4fd4c0c4dc0cfa2d TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2014-11-13_00:14:29
I confirm it with LO 5.3.2. Personally I think it's a bug and not an enhancement, because if you use the sitebar, you can customise "Font Colour" as well as "Highlight Colour". => changed description of th bug to be more precise => changed to minor bug, because a workaround exists
Tested 6.0 and font color in the toolbar does work. Highlight color is disabled in toolbar and enabled in sidebar, so its likely using a different uno command. Maxim: thoughts? Version: 6.0.0.0.alpha1+ Build ID: 43d6b11a5c1dda0cc2c1e06c768eece25051a56c CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; Locale: en-US (en_US.UTF-8); Calc: group
I wonder if font attributes are allowed in comments. Regina?
Comments are <office:annotation> elements. Allowed content is <text:list> and <text:p> and the meta data <dc:creator>, <dc:date> and <meta:date-string>. So from file format there would be no problem to use all styling that are possible for lists and paragraphs. Comments are handled as callout shapes internally (AFAIK), so all restrictions known for them (e.g. bug 96706) hold here too.
Dear peter josvai, 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
*** Bug 139748 has been marked as a duplicate of this bug. ***
Not totally getting what the hold-up here is.. menu/format/character does work. Makes sense to add character to the right click context menu of a comment, IMHO. And working toolbar button might help too.. Biggest issue is DOCX ex and/or importer not handling highlighting inside comment box.. So it will vanish. Obviously not great either.. but no reason for the current state, IMHO.
(In reply to Telesto from comment #8) > Not totally getting what the hold-up here is.. > menu/format/character does work. > > Makes sense to add character to the right click context menu of a comment, > IMHO. > And working toolbar button might help too.. > > > Biggest issue is DOCX ex and/or importer not handling highlighting inside > comment box.. So it will vanish. Obviously not great either.. but no reason > for the current state, IMHO. I tested it on my version of Writer now (7.0.4.2 x64), and the bug remains. Like others said, font color in the toolbar work; highlight color is disabled in toolbar and enabled in sidebar. Really the function of importing the highlighted comments from DOCX is not working, I tested it here too. What did you mean by it will vanish?
(In reply to Lucas from comment #9) I might have misunderstood. I read you're bug as : highlight color is disabled in toolbar and enabled in sidebar. If you where talking about DOCX/DOC import (and export) then you're right. It doesn't function. Kind of created bug 139759 for that.. but if you're attached having you're own report.. I'm happy to revive that one
(In reply to Telesto from comment #10) > (In reply to Lucas from comment #9) > I might have misunderstood. > > I read you're bug as : highlight color is disabled in toolbar and enabled in > sidebar. If you where talking about DOCX/DOC import (and export) then you're > right. It doesn't function. Kind of created bug 139759 for that.. but if > you're attached having you're own report.. I'm happy to revive that one Chill, man, I'm not attached. We're in this together :) Hope the bug can be fixed!
(In reply to Lucas from comment #11) > Chill, man, I'm not attached. We're in this together :) > Hope the bug can be fixed! I have nicely asked developer team called NISZ. The do quite some nice work on DOCX lately.. it should be pretty simple/ quick to solve... with the right expertise.. we will see. I'm adding you to the CC list of the new created bug.. This way you will be informed if things are moving..
Hmm - I wonder how it is being disabled. It is NOT via rSet.disableItem.
The sidebar is basically being replaced by a different set of options when switching to comments. (Some paragraph stuff disappears, and the Character Highlighting Color visibly changes position when moving between body text and comment.) Comments also disable other paragraph items like numbering on the toolbar. There are two Character Highlighting Color objects: .uno:BackColor (works with comments) and .uno:CharBackColor (works with body text). Likely there is no (easy) solution for the disabled toolbar button.
(In reply to Justin L from comment #14) > There are two Character Highlighting Color objects: .uno:BackColor (works > with comments) and .uno:CharBackColor (works with body text). I got this completely backwards: .uno:BackColor is enabled with body text. It is associated with SvxBrushItem and SID_ATTR_BRUSH_CHAR. .uno:CharBackColor is enabled with comments / textboxes / draw-stuff and associated with SvxColorItem and SID_ATTR_CHAR_BACK_COLOR. I changed EVERY reference of .uno:CharBackColor to .uno:BackColor and that STILL did not "fix" the toolbar disabling when in a comment/textbox. HELP!
(In reply to Justin L from comment #15) Just to rule something out: The comment box is capable of rendering Character Highlighting. Inspired by bug 93789
(In reply to Justin L from comment #15) > .uno:BackColor is enabled with body text. It is associated with SvxBrushItem > and SID_ATTR_BRUSH_CHAR. That's not 100% accurate either. From sw/sdi/swriter.sdi: SvxColorItem BackColor SID_ATTR_CHAR_COLOR_BACKGROUND but in the code this is typically changed to SvxBrushItem and associated with Writer's RES_CHRATR_BACKGROUND. > .uno:CharBackColor is enabled with comments / textboxes / draw-stuff and > associated with SvxColorItem and SID_ATTR_CHAR_BACK_COLOR. SvxColorItem CharBackColor SID_ATTR_CHAR_BACK_COLOR which in the code is keep as a ColorItem and pretty much is exclusively associated with editeng's EE_CHAR_BKGCOLOR. In sw UNO, PROP_NAME_CHAR_BACK_COLOR maps to RES_CHRATR_BACKGROUND.
Exploratory proposal at http://gerrit.libreoffice.org/c/core/+/137334 (In reply to Justin L from comment #15) > Nothing "fixed" the toolbar disabling when in a comment/textbox. HELP! The key to this is defining CharBackColor in the .sdi files.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e93b7f6a5c5f9ee86546d95d7fe70ecc26b71b91 NFC related tdf#85592: simplify SID_ATTR_CHAR_COLOR_BACKGROUND_EXT 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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ba8eb90925aa31be4029b5486a6f5dcd2e9573fd [API CHANGE] related tdf#85592: drop duplicate use of .uno:CharBackgroundExt 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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/be3d34b5d6b97c3eb12ab3f84ce2da2ef965a928 [API CHANGE] tdf#85592: deprecate .uno:BackColor, use .uno:CharBackColor 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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/70d9e7eadb1069b5e7a1909c671b9348b740cca1 tdf#85592 android: .uno:BackColor deprecated, use .uno:CharBackColor 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.
Documented API CHANGE in 7.6 release notes.
Font color works, but not character highlighting Tested with Version: 7.5.0.2 (X86_64) / LibreOffice Community Build ID: c0dd1bc3f1a385d110b88e26ece634da94921f58 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded
(In reply to Dieter from comment #24) > Font color works, but not character highlighting > Version: 7.5.0.2 (X86_64) / LibreOffice Community It only works in 7.6, where it was documented in the release notes.
(In reply to Justin L from comment #25) > It only works in 7.6, where it was documented in the release notes. I only looked at information in "Whiteboard". But you're right, fixed in Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1c638b7ac46d8077994c8483e6becc4a33efd12b CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (de_DE); UI: en-GB Calc: CL threaded Thank you, Justin!