Bug 127712 - Flag for whether choosing a style clears direct formatting
Summary: Flag for whether choosing a style clears direct formatting
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-23 09:36 UTC by Eyal Rozenberg
Modified: 2023-10-02 07:59 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 2019-09-23 09:36:33 UTC
Some styles (character/paragraph) are such that, when you set them, you almost-certainly want not to apply any direct formatting. But - if you select some text and set a style for it, the direct formatting remains, over the styled text.

While the above is reasonable default behavior, it should be possible to indicate whether the user is expecting a reversion to no-direct-formatting.
Comment 1 Eyal Rozenberg 2019-09-23 12:28:55 UTC
Examples: When you change the paragraph style from Body Text or Default Style to, say, Heading 1, Heading 2 etc. - you probably want to drop the direct formatting.
Comment 2 Heiko Tietze 2019-09-25 08:23:12 UTC
And what if you apply "MyFancyHeadingStyle"? Thing is, we have a) to comply with the format, b) take care about round trips with alien formats, and c) consider user customizations. So this clearly wont fix.

Currently in discussion is bug 38194 (and related): proper feedback when the user has done direct formatting.
Comment 3 Eyal Rozenberg 2019-09-25 08:37:52 UTC
(In reply to Heiko Tietze from comment #2)
> And what if you apply "MyFancyHeadingStyle"?

This bug is strictly about when you've formatted directly, not applied a style. Applying a style express stronger intent.

> b) take care about round trips with alien formats
> and c) consider user customizations. 

I'm not sure what you mean. Can you elaborate?

Also, if you ask a question, please extend me the courtesy of letting me try to respond before closing a bug.
Comment 4 Heiko Tietze 2019-09-25 08:47:31 UTC
The hierarchy that defines the actual appearance is paragraph style, character style 1..n, direct formatting. Your proposal is about overriding a direct formatting when the user applies a certain style, and you want to do it for just some styles like headings.

My objection was that heading is not defined by a clear attribute and you may have user defined styles that behave like this. So the realization of your proposal would be a manual flag aka checkbox whether this paragraph style turns the usual logic upside down (but only when applied, otherwise it has to be stored with the document and respected by all programs that use ODF). Sounds very complicated.
Comment 5 Eyal Rozenberg 2019-09-25 09:15:13 UTC
(In reply to Heiko Tietze from comment #4)
> The hierarchy that defines the actual appearance is paragraph style,
> character style 1..n, direct formatting. Your proposal is about overriding a
> direct formatting when the user applies a certain style, and you want to do
> it for just some styles like headings.

I'm not proposing overriding the logic, just clearing direct formatting, once - As though you've applied "Clear direct formatting" when changing styles.

After you've changed styles, you can still format directly just like before. This is why this bug is not really related to 38194, which increases the visibility of "persistent style state", so to speak.

The checkbox would say something like: "Clear direct formatting when applying this style".
Comment 6 Heiko Tietze 2019-09-25 09:45:26 UTC
(In reply to Eyal Rozenberg from comment #5)
> "Clear direct formatting when applying this style".

Yes, that's the right implementation from the UI POV. But I still disagree with it as you have many ways to apply a style and it would be not clear what style has the flag and kills your direct formatting. It solves one minor problem (ctrl+m is just a keypress away) and introduces a much bigger (no feedback when ctrl+m is executed automatically). That's why I still vote for NAB.
Comment 7 Eyal Rozenberg 2019-09-26 20:57:37 UTC
(In reply to Heiko Tietze from comment #6)
> I still disagree
> with it as you have many ways to apply a style and it would be not clear
> what style has the flag and kills your direct formatting. 

If no style provided by Libreoffice has this as a default - then you only get this behavior if you specifically asked for it.

> It solves one minor problem (ctrl+m is just a keypress away) 

Ah, but it's just pressing Ctrl+m - it's selecting the entire paragraph and pressing Ctrl+m. And the change may be subtle, e.g. change in vertical space above/before the paragraph.
Comment 8 Eike Rathke 2019-09-27 13:50:10 UTC
To make things more complicated, simply clearing all direct formatting isn't what you want. You certainly do not want to clear all direct formatting like Ctrl+M when applying cascaded hierarchical styles styles, but only the formattings that will be set by the to be applied style hierarchy.
Comment 9 Eyal Rozenberg 2019-09-27 20:08:30 UTC
(In reply to Eike Rathke from comment #8)
> To make things more complicated, simply clearing all direct formatting isn't
> what you want. You certainly do not want to clear all direct formatting like
> Ctrl+M when applying cascaded hierarchical styles styles,

What do you mean by "cascaded hierarchical styles" ? I'm just a applying a paragraph style to a paragraph, that's all. Ok, styles are hierarchical and cascaded in a sense, i.e. each style is based on some other style except for the Default Style, but I don't think that matters here.

> but only the
> formattings that will be set by the to be applied style hierarchy.

Why? No. I want all direct formatting of that paragraph to vanish. Wipe the slate clear. At most I'm willing to accept applications of Character Style.
Comment 10 QA Administrators 2021-10-01 03:51:12 UTC Comment hidden (obsolete)
Comment 11 Eyal Rozenberg 2021-10-01 06:53:53 UTC
This is still an issue.
Comment 12 QA Administrators 2023-10-02 03:15:35 UTC Comment hidden (obsolete)
Comment 13 Eyal Rozenberg 2023-10-02 07:59:16 UTC
Still an issue with:

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: f8e591ab9182e0a61c4ae5b8f77b166fcaeaa877
CPU threads: 4; OS: Linux 6.4; UI render: default; VCL: gtk3
Locale: he-IL (en_IL); UI: en-US