Bug 142788 - LO should fully expose the character style implicit in every paragraph style
Summary: LO should fully expose the character style implicit in every paragraph style
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-06-11 09:12 UTC by Eyal Rozenberg
Modified: 2021-06-14 07:38 UTC (History)
2 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 Eyal Rozenberg 2021-06-11 09:12:55 UTC
In LO (and particularly Writer), a Paragraph style has an inherent default character style for that paragraph - as the Paragraph style contains all properties one would be able to set for a Character style. [1]

However:

1. The Paragraph style UI only allows modifying a subset of the properties of this character style. So, one can set the default font family and font size, but not the character/glyph width factor.
2. More generally, these inherent character styles are entirely _implicit_ - they not mentioned or listed as such anywhere. And the Paragraph style modification dialog does not make a strong distinction between the Paragraph-ish properties and the Character-ish properties.

It seems obvious to me all Character-style-properties must be accessible via the Paragraph style modification UI, somehow.

One way to do this would be to add more tabs; which may be a bit cumbersome, but seems doable.

Another way to do this would be using the Character style modification dialog as a sub-dialog of Paragraph style. This seems the "better-structured", perhaps more elegant, approach; but if this approach is chosen, it may be worthwhile to consider "recognizing" the existence of these inherent default character styles elsewhere, in the documentation and perhaps in the UI. 


 [1] : According to Mike Kasanagi on #libreoffice-dev@libera.chat, 2021-06-11
Comment 1 Heiko Tietze 2021-06-11 09:42:04 UTC
To my understanding, there is no _inherent_ CS. On the PS level you can define some attributes but not all. And actually it makes no sense to have (multiple) paragraphs with a different character position. What you want to do is set paragraph level attributes such as indentation, alignment etc. for many paragraphs and character attributes such as "emphasis" (italic), "code" (monospace) or whatever for a small portion within a paragraph.

=> WF
Comment 2 Mike Kaganski 2021-06-11 09:46:29 UTC
(In reply to Heiko Tietze from comment #1)
> To my understanding, there is no _inherent_ CS. On the PS level you can
> define some attributes but not all.

It might be simply terminological inconsistency. As I understand the request, there is *some* specific paragraph style property (related to character properties) that is unavailable in paragraph style dialog; and that would be indeed useful to add. However, the task is better split to specific (sets of) properties - e.g., grouped by respective character style's tabs; possibly with a common meta if needed.
Comment 3 Eyal Rozenberg 2021-06-11 10:15:30 UTC
(In reply to Heiko Tietze from comment #1)
> To my understanding, there is no _inherent_ CS.

If a PS contains, in particular, all properties of a CS (and I'm not talking about what's exposed in the UI), then I define that as an inherent character style.

> On the PS level you can
> define some attributes but not all. And actually it makes no sense to have
> (multiple) paragraphs with a different character position.

If it makes enough sense for PS'es to have that property internally, then it makes sense to have it externally.

To me it makes perfect sense for multiple paragraphs to have:

* Different spacing than other kinds of paragraphs.
* Wider characters than other kinds of paragraphs.
* The same angle of rotation

etc.


>  What you want to
> do is set paragraph level attributes such as indentation, alignment etc. for
> many paragraphs and character attributes such as "emphasis" (italic), "code"
> (monospace) or whatever for a small portion within a paragraph.

You're describing the typical use case for CS'es. But most of the properties are also relevant for setting a default for a PS. And this is, after all, allowed for many such properties already. I would say that it's not useful to limit those arbitrarily (especially not with different limits in the dialog and in what's modifiable in principle).
Comment 4 Eyal Rozenberg 2021-06-11 10:58:49 UTC
(In reply to Mike Kaganski from comment #2)
> As I understand the
> request, there is *some* specific paragraph style property (related to
> character properties) that is unavailable in paragraph style dialog; and
> that would be indeed useful to add. However, the task is better split to
> specific (sets of) properties - e.g., grouped by respective character
> style's tabs; possibly with a common meta if needed.

I actually mean _all_. Why? Because the properties I want to change in a Paragraph style are not the ones you might want to change. I may want access to character width, but I also think that something like underlining or italicizing should absolutely _not_ be used by default in a paragraph, and reserved only for character styles. And believe me - those two properties are heavily abused in practice (especially in Hebrew for which Italicization should not even be possible  at all for typographic and historical reasons; but never mind that).

That's why I wrote I don't think it's a good idea to try and choose the "correct" subset of Character style properties editable in Paragraph styles, and instead allow for _all_ of them to be edited. This has the benefit of allowing the use of the same UI as for Character styles - making it easier to remember what's-to-be-found-where.
Comment 5 Mike Kaganski 2021-06-11 11:20:28 UTC
(In reply to Eyal Rozenberg from comment #4)
> I actually mean _all_. Why?

It doesn't matter why. It's OK to want to have them all. What matters is how to file bugs; and a bug like "I want them all" is not very useful, because it's difficult to track status - was *all* exposed?

Hence I proposed to change it to:

1. A meta with the stated end goal: "All properties need to be exposed".
2. Sub-bugs: "I see this property not exposed"; "I see that set of properties not exposed", "This tab present in character properties is missing", etc. That is meant by "some" in my comment, not "only a subset should be exposed in the end".
Comment 6 Eyal Rozenberg 2021-06-11 15:07:48 UTC
(In reply to Mike Kaganski from comment #5)

I filed the bug this way to allow for the discussion of the qualitative vs quantitative change: Is it "expose more properties", where finally all are exposed, or is it "expose the inherent character style explicitly", which results in, at least, a different approach to the UI changes, and possibly deeper things.

"Deeper" could mean, among other things:

* Option to show these currently-implicit styles in the list of Character styles (using the names of their associated Paragraph Styles, and possibly with some indication of their nature, e.g. grayed-out or in parentheses)

* Ability to inherit the Character style from a Character style _other_ than the parent Paragraph style's inherent character style.

* Easier UI for expressing "Don't make any changes to the parent Paragraph style's  default Character style".

* Maybe even something with expression in the saved ODT (not sure what, I'm clueless about the format).
Comment 7 Mike Kaganski 2021-06-11 15:11:06 UTC
(In reply to Eyal Rozenberg from comment #6)

Then Heiko is right. There is *no* character styles in paragraph styles. Paragraph styles simply define both character-specific and paragraph-specific properties, while character styles define only character-specific properties. It is basic architecture of ODF, and is not something to change, at least without re-designing architecture of the format and application.
Comment 8 Mike Kaganski 2021-06-11 15:28:18 UTC
Note also the fundamental difference between paragraph styles and character styles WRT their *completeness*. A character style *may not define* any of its properties, even considering inheritance. This is fundamentally different from paragraph style; this allows a character style to be partial, and only override part of properties, falling back to *context-dependent* set of the other properties of the affected run; it may come from another character style applied to a greater range at a "nested" layer (not inheritance!), or it might be paragraph-defined defaults.

To the contrary, a paragraph *always* defines *all* of its properties, be it character-related or paragraph-related - if not directly in itself, then in inheritance tree (and thus *default paragraph* may almost be considered the full set of defaults used in the document). So the set of properties in paragraph style related to character settings may not be even in theory considered "implied character style".
Comment 9 Mike Kaganski 2021-06-11 15:32:44 UTC
(In reply to Mike Kaganski from comment #8)
> A character style *may not define* any of its properties

I mean, it is *allowed to leave any property undefined*, of course (sorry for unclear/wrong wording).
Comment 10 Eyal Rozenberg 2021-06-11 15:54:06 UTC
(In reply to Mike Kaganski from comment #7)
> Then Heiko is right. There is *no* character styles in paragraph styles.
> Paragraph styles simply define both character-specific and
> paragraph-specific properties, while character styles define only
> character-specific properties. 

So, like I told Heiko, that literally means there's an implicit Character style within each Paragraph style... sans the name the "formal recognition". After all, what is the definition of a Character style if not its set of properties, plus its name/identifier?

> It is basic architecture of ODF, and is not
> something to change, at least without re-designing architecture of the
> format and application.

Ok, that just means that there are implicit PS-default CS'es in the ODF format as well. You are right that "recognizing" them in ODF is much more big of a deal than "recognizing" them in the UI.

> *completeness*

Actually I'd say it's more the opposite of what you conclude. That is, it's true that for a PS, all character properties are defined directly or via inheritance. But when a character property is defined via the PS inheritance tree - that is the case of the implicit character style having that property undefined. And like with every CS - when you apply it, whatever is undefined becomes defined using PS inheritance.
Comment 11 Mike Kaganski 2021-06-11 16:01:42 UTC
(In reply to Eyal Rozenberg from comment #10)

When you have a paragraph style, you have every property defined (not necessarily set in this style, but completely defined). This is completely different for character style. This is basic difference; what you consider "similarity" is a detail, which is important for inheritance, but is fundamentally different when using (applying) related styles. You need to consider that; and *use* of styles is no less important (I'd say the least) than defining. Trying to unify here would be *most* confusing, not even telling about confusion of seeing same-named styles coming from both paragraphs and character styles in one list.

See also current GSoC project of making both character and paragraph styles to show in different lists *on a single sidebar panel* - implementing this confusing proposal would produce even greater confusion to users.

I totally support WF in current form. I suggest to close it, and *if still desired*, follow suggestion from comment2 and comment 5.
Comment 12 Eyal Rozenberg 2021-06-11 18:58:00 UTC
(In reply to Mike Kaganski from comment #11)
> When you have a paragraph style, you have every property defined (not
> necessarily set in this style, but completely defined). This is completely
> different for character style. 

That does not contradict what I said.

> Trying to unify here

I didn't suggest a unification of Character and Paragraph styles. I suggest a distinction between the Character Style aspect of a Paragraph style, and the rest of the Paragraph style properties + the inheritance from the parent style.


> See also current GSoC project of making both character and paragraph styles
> to show in different lists *on a single sidebar panel* - implementing this
> confusing proposal would produce even greater confusion to users.

Implementing this proposal would have no immediate effect on the Style pane; only on the UI for setting Character properties of Paragraph styles. But even regardless of this fact: Suggesting to users that a Paragraph style contains an implicit Character style is already the case in MS Word. Have a look at the style sidebar there:

https://winfix.net/wp-content/uploads/2020/02/02_clicking_options_on_styles_pane.png

The PS icon for some paragraph styles _contains_ the icon for a Character style (an 'a' letter), plus elements alluding at paragraphs (multiple lines and a ΒΆ pilcrow). IIANM, the distinction between when the Character properties are completely inherited, or whether there really is a "non-empty"/"non-trivial" inherent character style modifying the inherited properties.
Comment 13 Heiko Tietze 2021-06-14 07:38:29 UTC
(In reply to Mike Kaganski from comment #11)
> I totally support WF in current form. I suggest to close it, and *if still
> desired*, follow suggestion from comment 2 and comment 5.

Thanks for the discussion, Eyal & Mike.