Bug 110077 - Font name preview in dialog appears as black bar
Summary: Font name preview in dialog appears as black bar
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
5.1.0.3 release
Hardware: All All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:6.0.0 target:5.4.2
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Font-Preview
  Show dependency treegraph
 
Reported: 2017-07-29 15:26 UTC by Yousuf Philips (jay)
Modified: 2017-08-17 11:46 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot (41.14 KB, image/png)
2017-07-29 15:26 UTC, Yousuf Philips (jay)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) 2017-07-29 15:26:20 UTC
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
Comment 1 Telesto 2017-07-29 18:59:13 UTC
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).
Comment 2 V Stuart Foote 2017-07-30 05:47:10 UTC
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.
Comment 3 Aron Budea 2017-08-13 05:10:58 UTC
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
Comment 4 JoNi 2017-08-13 20:36:59 UTC
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...
Comment 5 Yousuf Philips (jay) 2017-08-14 01:13:14 UTC
(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+
Comment 6 Aron Budea 2017-08-14 04:32:19 UTC
(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"
Comment 7 V Stuart Foote 2017-08-14 07:16:05 UTC
(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
Comment 8 V Stuart Foote 2017-08-14 17:36:17 UTC
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?
Comment 9 Caolán McNamara 2017-08-15 09:40:28 UTC
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
Comment 10 Caolán McNamara 2017-08-15 09:50:05 UTC
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/
Comment 11 Commit Notification 2017-08-17 11:46:59 UTC
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.