Bug 127316 - FILESAVE: DOC/X automatic sized subscript exported as huge number
Summary: FILESAVE: DOC/X automatic sized subscript exported as huge number
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.3.0.4 release
Hardware: All All
: medium normal
Assignee: Justin L
URL:
Whiteboard: target:6.4.0 target:6.3.3 target:6.5....
Keywords: bibisected, bisected, regression
Depends on:
Blocks: DOCX-Character
  Show dependency treegraph
 
Reported: 2019-09-03 17:27 UTC by Michael Hartje
Modified: 2019-12-03 16:55 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
lower character adds page break in interpretation of DOCX (4.22 KB, application/wps-office.docx)
2019-09-03 17:27 UTC, Michael Hartje
Details
screen shot of 2 open files :.ODT (original) and .DOCX (page 1) side by side (11.51 KB, image/png)
2019-09-05 16:33 UTC, Michael Hartje
Details
example (8.72 KB, application/vnd.oasis.opendocument.text)
2019-09-05 17:46 UTC, Dieter
Details
original ODT-file which destroys the page layout after 1 character set low line (8.54 KB, application/vnd.oasis.opendocument.text)
2019-09-26 10:03 UTC, Michael Hartje
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Hartje 2019-09-03 17:27:30 UTC
Created attachment 153846 [details]
lower character adds page break in interpretation of DOCX

make a file with some text.
make one character "lower" in text

save to DOCX

open the DOCX

At the the former "lower" character there is a new page break inserted
The text on next page is missing the "lower" character

--> is this a misinterpretation?
Error occurs in windows and linux platforms libreoffice 
Error occurs in word 2018
Comment 1 m.a.riosv 2019-09-03 19:36:06 UTC
I can't repro:
Version: 6.3.1.2 (x64)
Build ID: b79626edf0065ac373bd1df5c28bd630b4424273
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: es-ES (es_ES); UI-Language: en-US Calc: CL
Comment 2 raal 2019-09-03 21:23:25 UTC
I can no confirm in Version: 6.4.0.0.alpha0+
Build ID: 41cd3e8e817c8c33a13608e62eeb06ce2c6977e4
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 

Is 'lower'  character property lowercase?
Comment 3 Xisco Faulí 2019-09-05 09:29:13 UTC
Hello Micahel,
Could you please add a screenshot of the problem ?
Comment 4 Michael Hartje 2019-09-05 16:33:11 UTC
Created attachment 153928 [details]
screen shot of 2 open files :.ODT (original) and .DOCX (page 1) side by side

Thanks to all comments,

I attach a screen shot with 2 open files in libreoffice side by side

Right: the orginal .ODT file with text reopened
Left: the Text save to .DOCX and reopened (see my first attachment to the bug report)

As you may notice in the ODT (right) is a line starting with
sfasd where the 2. "s" is lowered to sfa_s_d

My analysis:
In the DOCX file this line is interpreted as following:

1. page break
2. show text of this line without "s" followed by a huge line distance
3. the rest of the text is displayed on page 3

Hypothesis:
the lower character is interpreted not only to set lower 30% with character size of 70% (as in .ODT shown) but as very huge "set lower" which is much more than a page length. so the lowered "s" could not be displayed on page 2.

hopefully this explains it better than the first error report with the attached "DOCX"
Comment 5 Dieter 2019-09-05 17:45:48 UTC
I can't reproduce.

1. I created odt-file from your attachemnt in original bug report.
2. I changed character 's' to superscript (see attachment).
3. I saved as docx
4. I reopened file => no page break

Tested with

Version: 6.4.0.0.alpha0+ (x64)
Build ID: 01837a85004a6f891a09c0a63ed7eff75d634827
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-09-01_00:07:05
Locale: en-GB (de_DE); UI-Language: en-US
Calc: threaded

and also with

Version: 6.2.5.2 (x64)
Build-ID: 1ec314fa52f458adc18c4f025c545a4e8b22c159
CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: threaded
Comment 6 Dieter 2019-09-05 17:46:53 UTC
Created attachment 153933 [details]
example
Comment 7 Xisco Faulí 2019-09-26 08:21:02 UTC
Hello Micahel Hartje,
Could you please attach the original ODT file ?
Comment 8 Michael Hartje 2019-09-26 10:03:08 UTC
Created attachment 154532 [details]
original ODT-file which destroys the page layout after 1 character set low line

The described error occurs still in Version 6.3.1.2 (windows) -- save my ODT to DOCX (2007 365) and reopen this DOCX. Find an additional page break in the 4th line at the low line character.
Comment 9 Dieter 2019-09-26 10:13:21 UTC
I confirm this with

Version: 6.3.2.2 (x64)
Build-ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c
CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: threaded

Explanation: Subscript position has been changed to 13.999% (!)
Comment 10 Justin L 2019-09-26 12:44:52 UTC
bisected to LO 6.4 commit 32262b0a537207832d7d126d8427d8949b9e821d and backported to 6.3. Originally the limit was 101, now it is ~14000.
Author: László Németh
Date:   Wed May 29 16:36:41 2019 +0200
    bug 120412 char formatting UI: clean-up DFLT_ESC_AUTO
    
    Default auto values must be outside of the new
    enlarged range of the superscript/subscript percent values.
    
    Note: the raising limit was modified to 13999 from 14400,
    because the RTF unit test tdf112208_hangingIndent.rtf
    lost its hanging from the bigger value.
Comment 11 Justin L 2019-09-26 18:12:16 UTC
https://gerrit.libreoffice.org/79628 tdf#127316 docxexport: use default escapement for AUTO

https://gerrit.libreoffice.org/79651 tdf#127316 ww8export: use default escapement for AUTO
Comment 12 Commit Notification 2019-09-26 18:24:31 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/89f0107b8de21bbb22e850847348ab40cce24644

tdf#127316 docxexport: use default escapement for AUTO

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 13 Commit Notification 2019-09-27 04:15:39 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/9b96f644c554f1b10a380dd3f9a04a405b948411

tdf#127316 ww8export: use default escapement for AUTO

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 14 Commit Notification 2019-09-27 05:51:53 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

https://git.libreoffice.org/core/commit/b00313c982ca3cf92abac9e2e0f5cdf7efc1456f

tdf#127316 docxexport: use default escapement for AUTO

It will be available in 6.3.3.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 15 Commit Notification 2019-09-27 08:53:42 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

https://git.libreoffice.org/core/commit/c932203b1f46b52ae1fa4e56de9fe1a6b6cb49a1

tdf#127316 ww8export: use default escapement for AUTO

It will be available in 6.3.3.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 16 Justin L 2019-09-27 09:52:03 UTC
RTF format looked OK to me. It already used a different formula which looks better, but doesn't round-trip well with .doc/x.
P.S. I think RTF's superscript formula is probably correct, but the subscript formula might need tweaking based on bug 80194.

This is a bit of a tricky area. MSWord has a very specific measurement of up or down and adjusts the font size, while LO wants to use a "percentage" of the font size and just display the font differently from its original font size. Well, of course on export we must reduce the fontsize for Word, and then have no choice but to import as a smaller font - and thus our adjustment percentage changes.

Perhaps on import we could just drop the font size attribute IF after conversion it is approximately equal to the surrounding text - but that would be rather tricky to accomplish.

All of that suggests that "automatic" and "default" are probably best considered to be synonymous.
Comment 17 Xisco Faulí 2019-09-30 11:39:55 UTC
Verified in

Version: 6.4.0.0.alpha0+
Build ID: 49a634425f0d433541f8309f2575c8bdfd67afbe
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

@Justin Luth, thanks for fixing this issue!!
Comment 18 Commit Notification 2019-11-25 08:09:16 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/d6e2d624a124454fa4ac80cb30a924571a609101

tdf#127316 ooxml/ww8export: DFLT_ESC_*_AUTO - use better formulas

It will be available in 6.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 19 Commit Notification 2019-11-26 09:15:05 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/0f149f685b9dc8fd7e53a677ce9557148be9be2a

tdf#127316 ooxml/ww8export: DFLT_ESC_*_AUTO - use better formulas

It will be available in 6.4.0.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 20 Commit Notification 2019-11-27 09:06:58 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/2fcc04722d72dbadf8d3decd7a5014ec39b93d27

partial revert tdf#127316 for rtfexport: restore ++nProp

It will be available in 6.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 21 Commit Notification 2019-12-03 16:55:25 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/0e2ab91c06eb42f6583989bd37a7537b9114b02f

partial revert tdf#127316 for rtfexport: restore ++nProp

It will be available in 6.4.0.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.