Created attachment 134975 [details] screenshot Steps: 1. Open Impress 2. Format > Character 3. Font name appears in font preview as black bar 4. Changing the font name in the list doesnt solve the issue either Regression as this worked correctly in 5.0. Version: 6.0.0.0.alpha0+ Build ID: f2d2093b2198bd4c65475a60329a5a6a7a8575f1 CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; Locale: en-US (en_US.UTF-8); Calc: group
Repro with: Version: 5.4.0.2 Build ID: 2b906d450a44f2bbe506dcd22c51b3fa11dc65fd CPU threads: 4; OS: Windows 6.2; UI render: default; Locale: nl-NL (nl_NL); Calc: CL The issue is more or less resolved when changing the highlighting color from black to grey (or any other color except White) in the highlighting tab (in Format > Character).
But isn't the highlight color "no fill" by default? Setting a Black highlight color with "Automatic" font color (default is black) would have to be intentional by a user.
Not sure where the version in the version field was coming from, because it's fine in 5.3.0.3, but not in 5.4.0.3. Bibisected to the commit below. Adding Cc: to Jochen Nitschke, please take a look. https://cgit.freedesktop.org/libreoffice/core/commit/?id=250995d2b8d8ad544110d3daeb2f61089bff0aa5 author Jochen Nitschke <j.nitschke+logerrit@ok.de> 2017-03-14 07:00:33 (GMT) committer Noel Grandin <noel.grandin@collabora.co.uk> 2017-03-14 07:58:49 (GMT) change SvxFrameDirectionItem base to SfxEnumItem
hit an assert in a debugutil build > core/svl/source/items/itempool.cxx:816: > const SfxPoolItem &SfxItemPool::GetDefaultItem(sal_uInt16) const: > Assertion `!"unknown which - don't ask me for defaults"' failed. which can be traced back to core/svx/source/dialog/fntctrl.cxx:1047 > const SvxBrushItem& rBrush = static_cast<const SvxBrushItem&>( rSet.Get( nWhich ) ); nWhich has the value SID_ATTR_BRUSH_CHAR = 10591 I got no idea how my patch could affect this part of the code. apart from being SfxPoolItem, SvxFrameDirectionItem and SvxBrushItem got nothing in common. The patch does not touch whichIDs, so a SvxFrameDirectionItem can't land on a SvxBrushItem slot in a pool. either the bibisect is wrong or the assert is completely unrelated. But SvxBrushItem holds a background color. maybe I missed something...
(In reply to Aron Budea from comment #3) > Not sure where the version in the version field was coming from, because > it's fine in 5.3.0.3, but not in 5.4.0.3. I tested all these versions and set the version field accordingly. Version: 5.1.6.2 Version: 5.2.7.2 Version: 5.3.5.0.0+
(In reply to Yousuf Philips (jay) from comment #5) > I tested all these versions and set the version field accordingly. And indeed, in Windows I can repro with 5.1.6.2, too. Somehow I couldn't in Linux, where I did the bibisecting. (In reply to JoNi from comment #4) > either the bibisect is wrong or the assert is completely unrelated. > But SvxBrushItem holds a background color. So it turns out the bibisect results are wrong (I don't know what exactly was going on, though). The assert's been reported separately in bug 103945, btw. In Windows I can repro with 5.1.6.2 just like Jay, and there it starts in the range of repo bibisect-win32-5.1. Here's another bibisect attempt. The results look more promising this time, what is strange, though is that the bug does not appear in 5.1.0.3, while the commit was already there... could it possibly depend on other factors as well? Adding Cc: to Katarina Behrens. Katarina, do you think the following commit could be relevant? https://cgit.freedesktop.org/libreoffice/core/commit/?id=ecc7308efa973fd1f1985ff9a0a0f01414b73f2b author Katarina Behrens <Katarina.Behrens@cib.de> 2015-10-30 15:13:27 (GMT) committer Katarina Behrens <Katarina.Behrens@cib.de> 2015-11-02 12:36:03 (GMT) "tdf#88276: New text background tab in char formatting dialog"
(In reply to Aron Budea from comment #6) So with on hand builds of 5.1.0.0alpha1+ this went in between 2015-10-21 and 2015-11-07--coinciding with introduction of a "Background" tab to the Character dialog. It affects all builds through current master, but easy STR with Draw of resetting profile default then opening a new canvas, then Format -> Character. The "Highlighting" tab is picking up a color assignment. Unfortunately it would match the font color, seems like it should default to "no fill". But, looks like Caolán has just refactored the SvxBackgroundColorItem with https://gerrit.libreoffice.org/41029
On Windows 10 Ent 64-bit en-US with Version: 6.0.0.0.alpha0+ (x64) Build ID: ec2abbca3d9befc4192452555a9433d267a47d58 CPU threads: 8; OS: Windows 6.19; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-08-14_11:11:24 Locale: en-US (en_US); Calc: CL This appears fixed now by https://cgit.freedesktop.org/libreoffice/core/commit/?id=6284804c2ccb3ad8bb6e1c1dac8d622f66b8c07d The Highlighting tab is defaulting to "No Fill" as one would expect. @Caolán, anything else to be done? A candidate for backport to 5.4?
because impress/draw doesn't have the SvxBrush char back, when its not set then the default one is taken, and the ultimate default is black. The apps that really have it set a final default of no-fill
with my new one the state of SID_ATTR_CHAR_BACK_COLOR is checked for the impress/draw case so its unset state is detected and an unset bBrushItemSet state is correctly propogated. With the conversion to from a SvxBrush for the set case done in the dialog. Yeah, so backported for 5-4 as https://gerrit.libreoffice.org/#/c/41168/
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a407285747c65894bc858c4aa722a24e57caca31&h=libreoffice-5-4 Resolves: tdf#110077 move the SvxBackgroundColorItem<->SvxBrushItem conversion It will be available in 5.4.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.