Bug 136433 - Font in character style should 'inherited' font/fontsize etc if it's defined by paragraph style (instead of showing a 'random' font/font size)
Summary: Font in character style should 'inherited' font/fontsize etc if it's defined ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.1.0.0.alpha0+
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-Styles-Character
  Show dependency treegraph
 
Reported: 2020-09-03 12:42 UTC by Telesto
Modified: 2023-05-15 11:06 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-09-03 12:42:55 UTC
Description:
Character Styles is misleading showing a font name (while it's actually inherited)

Steps to Reproduce:
1. Open Writer
2. Sidebar -> Styles -> Paragraph Style -> Right click default page style -> Modify
3. Font tab -> set font to Linux Biolinum G
4. Press OK
5. Type some text.. select a part of it
6. Sidebar -> Styles -> Character style -> Apply Strong Emphasis
7. Observe the font still being Linux Biolinum G (expected)
8. Right Click Strong Emphasis & click Modify
9. Font tab -> Notice the font being "Liberation Serif"

Actual Results:
CS style shows "Liberation Serif"

Expected Results:
An indicator that's inherited.. not a random font which isn't applied at all


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.1.0.0.alpha0+ (x64)
Build ID: 1e0cfd5662d95cea84e80e4fe10d52c3b1101ae6
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 1 Kevin Suo 2020-09-18 00:49:03 UTC
I notice this bug everyday. It semns never worked.
Comment 2 Heiko Tietze 2020-09-18 12:09:35 UTC
Yes, this enhancement would make it more clear. However, the CS is first of all a style independently from the actual PS. You can, for example, also edit a CS that is not yet applied. That's also why CS has no WYSIWYG font when preview is on (unlike PS). So it's likely a WF: CS has no hierarchy, and no parent until it is used.
Comment 3 Mike Kaganski 2020-09-18 12:12:28 UTC
We definitely need a way to mark inherited values in style dialogs.
Comment 4 Telesto 2020-09-18 12:15:27 UTC
(In reply to Heiko Tietze from comment #2)
> Yes, this enhancement would make it more clear. However, the CS is first of
> all a style independently from the actual PS. You can, for example, also
> edit a CS that is not yet applied. That's also why CS has no WYSIWYG font
> when preview is on (unlike PS). So it's likely a WF: CS has no hierarchy,
> and no parent until it is used.

Which would mean a new (place holder 'font') called inherited ;-). They CS style obviously not show any 'font'; as which font it is depends on PS. Except if the CS style defines a specific font (overriding the PS).

Currently CS style look show up as if they are overriding PS styles, which isn't the case.
Comment 5 Telesto 2020-09-18 12:21:59 UTC
Some hols of course try for nearly every setting.. And I'm gonna point to may bad idea (bug 135878) again.. (for a direction)... 

And already a warning in advance.. they way this is solved ... will probably requests as solution the DF toolbar too (bug 135878).
Comment 6 Regina Henschel 2020-09-18 12:37:23 UTC
What is meant by "initialize" in the subject? Currently we have "use the default character settings in the paragraph style, if neither the character style itself nor any of the parents of the character style has set the property".
Comment 7 Mike Kaganski 2022-12-16 07:03:42 UTC Comment hidden (obsolete)
Comment 8 Seán Ó Séaghdha 2022-12-16 07:10:45 UTC Comment hidden (off-topic)