Bug 147960 - FILEOPEN DOCX: Relative sub/superscript font size is forgotten in saved MS Word versions - for paragraph styles
Summary: FILEOPEN DOCX: Relative sub/superscript font size is forgotten in saved MS Wo...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.4.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 147971 148502 (view as bug list)
Depends on:
Blocks: DOCX-Paragraph
  Show dependency treegraph
 
Reported: 2022-03-13 12:32 UTC by joebros
Modified: 2023-11-04 17:00 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
All the text become subscript (18.46 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2022-03-13 12:34 UTC, joebros
Details

Note You need to log in before you can comment on or make changes to this bug.
Description joebros 2022-03-13 12:32:44 UTC
Description:
The text in document become subscript (small text) automatically in libreoffice but not in microsoft word. 

Steps to Reproduce:
1.select all using ctrl+A and select subscript tools at ribbon
2.
3.

Actual Results:
All the text become normal text again

Expected Results:
The text should not being subscript


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.3.1.3 (x64) / LibreOffice Community
Build ID: a69ca51ded25f3eefd52d7bf9a5fad8c90b87951
CPU threads: 12; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win
Locale: en-MY (en_MY); UI: en-US
Calc: CL
Comment 1 joebros 2022-03-13 12:34:27 UTC
Created attachment 178858 [details]
All the text become subscript
Comment 2 joebros 2022-03-14 12:16:17 UTC
I think i made a mistake regarding reproduce:

1. open the file, all the text become subscript instead of normal text
Comment 3 Telesto 2022-03-26 16:45:35 UTC
Repro
Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 3ccc4c123f5e78e0204d11abeab2d1a74278ca3e
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 Jumbo

and in
Versie: 6.4.0.2 (x86)
Build ID: 08d19fecdc7a2298d051e19cfdb7c35544855fc3
CPU-threads: 4; Besturingssysteem: Windows 6.3 Build 9600; UI-render: GL; VCL: win; 
Locale: nl-NL (nl_NL); UI-taal: nl-NL
Calc: CL

Ok with
Version: 6.1.6.3
Build ID: 5896ab1714085361c45cf540f76f60673dd96a72
CPU threads: 4; OS: Windows 6.3; UI render: default; 
Locale: nl-NL (nl_NL); Calc: CL
Comment 4 raal 2022-03-26 23:08:09 UTC
This seems to have begun at the below commit.
Adding Cc: to Justin Luth; Could you possibly take a look at this one?
Thanks
bibisect-linux-64-6.4$ 8134ea9f6e5d91cb938c1a8b297ef2da750a7633 is the first bad commit
commit 8134ea9f6e5d91cb938c1a8b297ef2da750a7633
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Wed Nov 6 12:30:27 2019 +0100

    source d71cf6390a89ea6a4fab724e3a7996f28ca33661

https://git.libreoffice.org/core/+/d71cf6390a89ea6a4fab724e3a7996f28ca33661
  tdf#99602 writerfilter: import subscript into character style
Comment 5 Justin L 2022-04-01 07:10:33 UTC
quite honestly, I think I would flag this as NOTABUG.

The default paragraph style clearly specifies that EVERYTHING should be subscripted.
<w:style w:type="paragraph" w:default="1" w:styleId="Normal">
  <w:name w:val="Normal"/>
  <w:rPr>
    <w:position w:val="-1"/>
  </w:rPr>
</w:style>

Perhaps Microsoft just ignores any position settings in paragraph styles? After all, setting superscript or subscript on an entire paragraph doesn't make much sense (although in theory if MOST of the characters should be subscripted, it might be easier to just set specific characters to normal). A similar concept was ignored with commit 861ca1f5030f2f6b7fbdc3bb3ded3d11130673ed for the overall docDefaults...

But there really is no reason to make an exception to the normal working of styles just "because it wouldn't normally make sense" for a user to do something silly like set everything to subscript.

The best fix is to fix the document itself. (In the Normal paragraph style, change Font - Character Spacing - Position to normal.) 

NOTE: As documented in the bug fix and the bug report, we treat ANY subscript as default in styles because doing anything else would be virtually impossible. So that also exaggerates the impact of this specific example document.

NOTABUG. If you disagree, please provide the documentation on why the specified positioning should be ignored.
Comment 6 Dieter 2022-04-11 08:12:40 UTC
*** Bug 147971 has been marked as a duplicate of this bug. ***
Comment 7 Dieter 2022-04-11 08:27:28 UTC
If you have a look in style in MS Word, it has subscript of 0,5pt (only had a look in German UI). If you changes this to normal, text in MS Word also changes. So I think text is subscripted in MS Word and in LO Writer. But I don't know, why LO changes font size to 58% so this might be the bug.

So I changed bug summary

Justin, what do you think?

=> UNCONFIRMED
Comment 8 Justin L 2022-04-11 08:40:29 UTC
(In reply to Dieter from comment #7)
> I don't know, why LO changes font size to 58% so this might be the bug.

From comment 5
NOTE: As documented in the bug fix and the bug report, we treat ANY subscript as default in styles because doing anything else would be virtually impossible. So that also exaggerates the impact of this specific example document.
Comment 9 Telesto 2022-04-11 08:41:23 UTC
*** Bug 148502 has been marked as a duplicate of this bug. ***
Comment 10 Dieter 2022-04-11 09:32:30 UTC
(In reply to Justin L from comment #8)
> From comment 5
> NOTE: As documented in the bug fix and the bug report, we treat ANY
> subscript as default in styles because doing anything else would be
> virtually impossible. So that also exaggerates the impact of this specific
> example document.

My comment was about relatvie font size (MS Word 100% / LO Worter 58%) and I couldn't see any informations about it in your comment 5 or in documentation of bug fix.
Comment 11 Justin L 2022-04-11 10:10:05 UTC
(In reply to Dieter from comment #10)
> My comment was about relative font size (MS Word 100% / LO Writer 58%)
The position and size are tied together to form a superscript, and thus automatic/default mode affects both. "Automatic" superscript/subscript font size is 58%.
Comment 12 Dieter 2022-04-12 06:16:27 UTC
(In reply to Justin L from comment #11)
> The position and size are tied together to form a superscript, and thus
> automatic/default mode affects both. "Automatic" superscript/subscript font
> size is 58%.

So question is, if Writer should always use "automatic" or font size from document.
Comment 13 Justin L 2022-04-12 06:24:20 UTC
(In reply to Dieter from comment #12)
> So question is, if Writer should always use "automatic" or font size from
> document.
...doing anything else would be virtually impossible.
Comment 14 Dieter 2022-04-13 06:13:52 UTC
(In reply to Justin L from comment #13)
> ...doing anything else would be virtually impossible.

I can't assess this. But if you're right we should close report as WONTFIX.
Comment 15 Jean-Baptiste Faure 2022-05-16 17:19:44 UTC
Closing as NotABug as suggested in comment #5.

Best regards. JBF
Comment 16 Wolfram 2023-02-27 19:48:35 UTC
147960: disagree with NOTABUG . Whenever a sub- or superscript is written EITHER in doc, docx, or odt, and the file is saved as a doc or docx file the sub- or superscript information is lost in the doc/docx file. Why is it not saved - somewhere?
But one can alternately work in the open docx file or odt file (while saving the workfile with that docx or odt name) and the super- and sub-scripts propagate correctly throughout the work. When saving in ODT all super/subscript info is saved correctly, but lost when saving & closing in docx. Again - why is it lost?
Comment 17 Justin L 2023-02-27 20:07:59 UTC
(In reply to Wolfram from comment #16)
> Again - why is it lost?
The answer to this question is in comment 4's patch. https://gerrit.libreoffice.org/c/core/+/80219/

This is also a great code pointer for the volunteer who considers this important.
Comment 18 Justin L 2023-08-21 12:33:40 UTC
fixed in 7.6 by commit 85f0a5d7bc54dfba75e8d6dd9c905bc1ac31d927
Author: Miklos Vajna on Tue Jun 13 15:02:20 2023 +0200
    DOCX filter: improve handling of negative <w:position> in paragraph styles