Created attachment 134975 [details]
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.
Build ID: f2d2093b2198bd4c65475a60329a5a6a7a8575f1
CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2;
Locale: en-US (en_US.UTF-8); Calc: group
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 22.214.171.124, but not in 126.96.36.199.
Bibisected to the commit below. Adding Cc: to Jochen Nitschke, please take a look.
author Jochen Nitschke <firstname.lastname@example.org> 2017-03-14 07:00:33 (GMT)
committer Noel Grandin <email@example.com> 2017-03-14 07:58:49 (GMT)
change SvxFrameDirectionItem base to SfxEnumItem
hit an assert in a debugutil build
> const SfxPoolItem &SfxItemPool::GetDefaultItem(sal_uInt16) const:
> Assertion `!"unknown which - don't ask me for defaults"' failed.
which can be traced back to
> 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 188.8.131.52, but not in 184.108.40.206.
I tested all these versions and set the version field accordingly.
(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 220.127.116.11, 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 18.104.22.168 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 22.214.171.124, 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?
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 126.96.36.199alpha1+ 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: 188.8.131.52.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
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":
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:
Affected users are encouraged to test the fix and report feedback.