Bug 146663 - Applying paragraph styles resets Character direct formatting
Summary: Applying paragraph styles resets Character direct formatting
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.0.0.5 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Conditional-Formatting
  Show dependency treegraph
 
Reported: 2022-01-09 09:35 UTC by Telesto
Modified: 2024-05-03 03:16 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Bibisect log (2.94 KB, text/plain)
2022-01-10 09:32 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2022-01-09 09:35:52 UTC
Description:
DOCX: Applying paragraph styles resets some direct formatting 

Steps to Reproduce:
1. Open attachment 177406 [details] (bug 146660 also somewhat relevant here)
2. Save as DOCX
3. Sidebar -> Style Inspector
4. Select second line of text -> Notice Character Direct Formatting being set (not the case in the ODT)
5. CTRL+A text
6. Apply Text Body Indent

Actual Results:
Bold lost for second and third line

Expected Results:
Still present


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 1bb0e177124d5d6661b72df6c7d848fb23639652
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

Also in
Version: 6.4.0.0.alpha0+ (x64)
Build ID: c56bf1479cc71d1a2b0639f6383e90c1f7e3655b
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: CL

and in
Version: 6.0.6.0.0+
Build ID: c30963b8b4bbbe42a24b97aafa161eff9d7ccdd4
CPU threads: 4; OS: Windows 6.3; UI render: default; 
Locale: nl-NL (nl_NL); Calc: CL

and in
Version: 5.2.5.0.0+
Build ID: a4d4fbeb623013f6377b30711ceedb38ea4b49f8
CPU Threads: 4; OS Version: Windows 6.2; UI Render: GL; 
TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-2, Time: 2016-12-24_14:43:55
Locale: nl-NL (nl_NL); Calc: CL

and in
Versie: 5.0.0.1 
Build ID: 9a0b23dd0ab9652e0965484934309f2d49a7758e
Locale: nl-NL (nl_NL)

not with
Versie: 4.4.7.2 
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Locale: nl_NL
Comment 1 Mike Kaganski 2022-01-09 10:58:27 UTC
I would assume it was some convenience change, trying to detect that some character DF spans the whole paragraph, and treat it as it's paragraph DF ... but yes, bibisect could answer.
Comment 2 Telesto 2022-01-10 09:32:40 UTC
Created attachment 177423 [details]
Bibisect log

Losing Character DF when applying Paragraph Style, bisected to:

    commit 3c0805e1f4f4d14e92c7e655d59c87de5c207e48
    Author:     Miklos Vajna <vmiklos@collabora.co.uk>
    AuthorDate: Thu May 14 11:34:33 2015 +0200
    Commit:     Miklos Vajna <vmiklos@collabora.co.uk>
    CommitDate: Thu May 14 11:39:16 2015 +0200
    
        tdf#86639 SwEditShell: when setting para style, reset char attrs if needed
    
        The old internal RTF filter used to call SwTxtNode::SetAttr() without
        setting SetAttrMode::NOFORMATATTR, so character attributes which cover
        the whole node got converted to paragraph attributes.  The new UNO
        filter goes through SwXText::insertTextPortion(), which sets
        SetAttrMode::NOFORMATATTR, so this doesn't happen. The result of this is
        that when the UI sets a new paragraph style on the text node, then such
        character attributes are no longer removed.
    
        Given that in RTF you can't really have character properties on a
        paragraph, going back to the document model produced by the old internal
        filter doesn't sound like the good direction -- not to mention that
        changing SwXText::insertTextPortion() this way would be an implicit API
        change.
    
        Fix the problem by tweaking SwEditShell::SetTxtFmtColl() instead, so
        that it removes these full-text-node character attributes, too. The
        logic in SwTxtNode::RstTxtAttr() can be extended later if necessary to
        delete more attributes, but to be on the safe side, just handle the bare
        minimum necessary to fix the problem for now.
    
        Change-Id: I5faa3226fc0f9c18e005da185fe0830d8c393256

https://cgit.freedesktop.org/libreoffice/core/commit/?id=3c0805e1f4f4d14e92c7e655d59c87de5c207e4
Comment 3 Mike Kaganski 2022-01-10 10:22:36 UTC
> regression

Sigh. A regression is something that works *worse* than before. Not every change is a regression.

So what we have here? There is a UI convention established since early suite days, that setting character attributes to a whole paragraph sets them to paragraph. We have an artificially constructed case, that employs the external format (or filter) deficiency, that *paragraph properties* are exported/imported as character properties. So the truth is: the property that you inspect is *originally* paragraph property, and only end up as whole-paragraph text portion because of some deficiency. And we have a code explicitly created to handle such special case as paragraph properties, which is consistent with the mentioned UI convention, consistent with the observed deficiency, and thus IMO completely OK. So what is the actual *problem* (i.e., something that prevents you from making your job done) here, that was possible before the "regression"?

I thank you for the bibisect, but I really can't see how it is reasonable to mark things this "automated" way.
Comment 4 Telesto 2022-01-10 11:35:57 UTC
> Sigh. A regression is something that works *worse* than before. 
In my perception it's 'worse', in the sense of Character DF getting removed by applying Paragraph Style. But obviously it depends on what counts as a regression. Developer point of view surely different from user point of view..

> Not every change is a regression.
True


> So what we have here? There is a UI convention established since early suite
> days, that setting character attributes to a whole paragraph sets them to
> paragraph. 

> We have an artificially constructed case, that employs the
> external format (or filter) deficiency, that *paragraph properties* are
> exported/imported as character properties. So the truth is: the property
> that you inspect is *originally* paragraph property, and only end up as
> whole-paragraph text portion because of some deficiency. And we have a code
> explicitly created to handle such special case as paragraph properties,
> which is consistent with the mentioned UI convention, consistent with the
> observed deficiency, and thus IMO completely OK. So what is the actual
> *problem* (i.e., something that prevents you from making your job done)
> here, that was possible before the "regression"?

It's working unexpected; from user perspective. With code knowledge you're surely capable of explaining why it happens. 

> I thank you for the bibisect, but I really can't see how it is reasonable to
> mark things this "automated" way.

The "regression" part is based on the observation prior post. It did function (why/how/what) required in depth knowledge. And well 'regression' tag can be removed if that's the annoyance...

---
FWIW: bug 146660 comment 10 steps 1-3 have the same problem source. So DOCX is only different way for exposing the problem. The behaviour is a contrary to what a user expects (how it's formatted accordantly to the Style Inspector)

A bug report obviously focus on cases where it doesn't work out as expected. No clue about the extend - how common - the problem actually is.
Comment 5 Jean-Baptiste Faure 2022-05-14 17:31:34 UTC
For me there is no bug there: 
- paragraph direct formatting (lines 2 and 3) -> reset if new paragraph style applied
- character direct formatting (word ipsum in first line) -> kept if new paragraph style applied.

Best regards. JBF
Comment 6 Jean-Baptiste Faure 2022-05-14 17:33:37 UTC
(In reply to Jean-Baptiste Faure from comment #5)
> For me there is no bug there: 
> - paragraph direct formatting (lines 2 and 3) -> reset if new paragraph
> style applied
> - character direct formatting (word ipsum in first line) -> kept if new
> paragraph style applied.
> 
> Best regards. JBF

Forgot to add that the observed behavior has nothing to do with docx, it is observed when applying paragraph style on the odt.

Version: 7.3.4.0.0+ / LibreOffice Community
Build ID: f668663d63d5b0f37d4727b54585c3b67ab92162
CPU threads: 8; OS: Linux 5.13; UI render: default; VCL: gtk3
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Ubuntu_20.04_x86-64
Calc: threaded

Best regards. JBF
Comment 7 Dieter 2023-10-04 07:37:29 UTC Comment hidden (obsolete)
Comment 8 Dieter 2023-10-04 07:48:26 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2024-04-02 03:12:09 UTC Comment hidden (obsolete)
Comment 10 QA Administrators 2024-05-03 03:16:58 UTC
Dear Telesto,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp