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
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
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?
Hello Micahel, Could you please add a screenshot of the problem ?
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"
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
Created attachment 153933 [details] example
Hello Micahel Hartje, Could you please attach the original ODT file ?
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.
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% (!)
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.
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
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.
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.
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.
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.
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.
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!!
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.
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.
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.
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.