Bug 155113 - WRITER: Can't define a character style for Regular font variant
Summary: WRITER: Can't define a character style for Regular font variant
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.5.2.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-Styles-Character
  Show dependency treegraph
 
Reported: 2023-05-01 17:35 UTC by ajlittoz
Modified: 2023-06-08 07:13 UTC (History)
3 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 ajlittoz 2023-05-01 17:35:21 UTC
LO 7.5.2.2, Fedora 38, Plasma desktop manager (Qt widgets)
This bug report is a follow-on of https://ask.libreoffice.org/t/character-style-to-unbold/91067

A paragraph style may configure its default font as bold or italic. To emphasize words, it is necessary to define a character style to revert to regular variant. For the character style to be "universal", font face and size are left untouched so that they remain in "transparent" state.

Regular is explicitly selected from the Style menu so that Writer notices we are forcing a parameter value.

However, it looks like Writer does not take into account the manual selection of Regular, which is equal to the initial value of the menu (although it was explicitly selected). As a consequence, the whole font tab is considered in "transparent state" and this style application has no effect.

This is not consistent with the management of other parameters where the parameter is considered "modified" as soon as some action is done on it, even if the final value is (apparently) the same as on entry.

The workaround I found is to configure the style in two steps: the first step arbitrarily selects a "Style" and saves; the second step selects Regular and saves. From now on, the Organizer tab displays Not xxx+normal where xxx was the arbitrary Style selected in first step.

No sample document attached as this is a problem related with style creation. Attaching a sample document would show success after the workaround procedure above.

I think this behaviour is a consequence of the change in handling bold and italic. Before this change, both attributes were manipulated through check boxes (therefore no "regular" check box nor selection). Now the "attributes" are handled with the Style drop-down menu in the Font tab.

And I wonder if requesting italics with Italic item (when default font is shown as Liberation Serif) will still be valid when the same variant is named Oblique in another font (like DejaVu Sans)
Comment 1 Buovjaga 2023-05-12 14:12:11 UTC
(In reply to ajlittoz from comment #0)
> I think this behaviour is a consequence of the change in handling bold and
> italic. Before this change, both attributes were manipulated through check
> boxes (therefore no "regular" check box nor selection). Now the "attributes"
> are handled with the Style drop-down menu in the Font tab.

Can you tell me more about this "change" that you refer to? I'm seeing basically the same UI in older versions like 5.2 and 3.5.
Comment 2 ajlittoz 2023-05-13 08:55:12 UTC
(In reply to Buovjaga from comment #1)
> (In reply to ajlittoz from comment #0)

> Can you tell me more about this "change" that you refer to? I'm seeing
> basically the same UI in older versions like 5.2 and 3.5.

I may have make a confusion with even older document applications where italic and bold where checkboxes. Nowadays most fonts provide a continuum of thickness (bold) and this can't be controlled by a simple checkbox. Also, typographically speaking, italics has nothing to do with a slant angle. It just means a "compatible" (with regard to regular) shape visually distinct from the main face but clearly identifiable as part of the family.

Anyway, a click on Regular should be sufficient to force the font variant like a click on any size forces this size.

IMHO what is dramatically missing in the style dialogs is a way to represent "transparent" state (inherited from the parent).
Comment 3 Heiko Tietze 2023-05-15 08:23:47 UTC
Closely related to bug 88559 "Display of inherited attributes from parent styles in Styles dialog" and 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)".

If we pick attributes from the current PS in the CS dialog the "emphasis PS" does show CS in italic- and you could define regular as the deviation.
Comment 4 Heiko Tietze 2023-05-26 07:01:37 UTC
(In reply to ajlittoz from comment #2)
> Anyway, a click on Regular should be sufficient to force the font variant
> like a click on any size forces this size.

What could "click on regular" be? To expand the dropdown list, to select it, or to change it (italic -> regular, w/o applying).

Pondered on bug 153623 over using attributes from the PS, which makes the weight Italic if you come from a paragraph with this setting. Not the best idea, though.

We could add "[Automatic]" (or "Inherited") to the lists, the same for spin edits, make the checkboxes partially checked, and add another item to radio button groups and similar controls. Makes it easy to set attributes back to the default, gives proper feedback, and allows any kind of attribute. A lot of benefit but also quite some work - given that your workaround is efficient.
Comment 5 Heiko Tietze 2023-06-08 07:13:15 UTC
We discussed the topic in the design meeting.

As commented on bug 153623 it depends on how you start the dialog. Per "New Style from Selection" you get the current PS attributes and could easily change italic to regular.

But as commented on bug 88559 we suggest to add an indicator for altered attributes and overload it so the icon/dot would be shown if you change some property- disabled/grayed out in that case. Clicking the icon/dot allows to make it sticky (or to remove it from the list modified attributes, see bug 89826).