Download it now!
Bug 120412 - FILEOPEN DOCX Raised text created with Word becomes normal when the document is opened in Writer
Summary: FILEOPEN DOCX Raised text created with Word becomes normal when the document ...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:6.3.0 target:6.4.0 target:7.0.0
Keywords: filter:docx
: 122049 (view as bug list)
Depends on:
Blocks: Character-Dialog DOCX-Character
  Show dependency treegraph
 
Reported: 2018-10-08 13:38 UTC by NISZ LibreOffice Team
Modified: 2020-06-11 18:44 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file from Word with 100pt character raise (19.66 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-10-08 13:38 UTC, NISZ LibreOffice Team
Details
Screenshot of the document opened in Word and Writer side by side (389.85 KB, image/png)
2018-10-08 13:40 UTC, NISZ LibreOffice Team
Details

Note You need to log in before you can comment on or make changes to this bug.
Description NISZ LibreOffice Team 2018-10-08 13:38:26 UTC
Created attachment 145469 [details]
Example file from Word with 100pt character raise

Imported Raised text in DOCX documents created with Microsoft Word 2010 becomes normal when the document is opened in LibreOffice Writer 6.0.4.0.0+.

Steps to reproduce:

    1. Create a new document in Microsoft Word.
    2. Type “text1 text2”.
    3. Select “text2”.
    4. Press Ctrl+Shift+F
    5. Select Special tab.
    6. Select the Raised option next the position category.
    7. Set 100 pt the measure of position.
    8. Click on OK button.
    9. Save the file as DOCX
    10. Open the same file in LibreOffice Writer 
    11. Compare the original file opened in Word and Writer

Actual results:
Raised text when the document is opened in LibreOffice Writer 6.0.4.0.0+.
Expected results:
Raised text should have the same style as the original file when the document is opened in Microsoft Word 2010

LibreOffice details:
Verzió: 6.1.0.3
Build az.: efb621ed25068d70781dc026f7e9c5187a4decd1
CPU szálak: 4; OS: Windows 6.3; Felületmegjelenítés: alapértelmezett; 
Területi beállítások: hu-HU (hu_HU); Calc: group threaded
Comment 1 NISZ LibreOffice Team 2018-10-08 13:40:12 UTC
Created attachment 145470 [details]
Screenshot of the document opened in Word and Writer side by side

Also the exported versions are pictured. LO does not save that setting, since it does not exist in Writer in the first place.
Comment 2 Dieter 2018-10-08 13:56:25 UTC
I confirm it with

Version: 6.2.0.0.alpha0+ (x64)
Build ID: 48cfa0b00b22f11ade53aec79b2fdddad253e1bd
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-10-03_02:01:42
Locale: en-US (de_DE); Calc: CL

Perhaps this occurs because you can't choose 100pt if you want to raise the characters (only 100%)
Comment 3 Gabor Kelemen 2018-10-08 14:36:36 UTC
(In reply to Dieter Praas from comment #2)
> Perhaps this occurs because you can't choose 100pt if you want to raise the
> characters (only 100%)

Yes, this is why we set it to Enhancement priority. We don't exactly have the same feature here.

(Also: this is my teams new common account, please be nice to them ;) )
Comment 4 Dieter 2018-10-08 15:35:35 UTC
(In reply to Gabor Kelemen from comment #3)
> (In reply to Dieter Praas from comment #2)
> > Perhaps this occurs because you can't choose 100pt if you want to raise the
> > characters (only 100%)
> 
> Yes, this is why we set it to Enhancement priority. We don't exactly have
> the same feature here.

Would be more clear, if there is a bug summary like "Character-Dialog: Allow pt for raise/lower setting"
Comment 5 Xisco Faulí 2018-10-15 13:35:31 UTC
Also reproduced in

Version: 5.2.0.0.alpha0+
Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53
Threads 4; Ver: 4.10; Render: default; 

Version: 4.3.0.0.alpha1+
Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e

Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)

in

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4

text1 is slightly below text2 but not as much as in MSO Word
Comment 6 Dieter 2018-12-12 21:11:30 UTC
*** Bug 122049 has been marked as a duplicate of this bug. ***
Comment 7 Commit Notification 2019-05-29 12:32:22 UTC
Jozsef Szakacs committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/bdfb3edb981ff04f1f3f6dc1ef335e37a0980245%5E%21

tdf#120412 DOCX filter: fix missing superscript

It will be available in 6.3.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 8 Commit Notification 2019-05-29 12:32:31 UTC
László Németh committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/868d9212a1b4cce7faa3eabc047ab7f312c613de%5E%21

tdf#120412 character formatting UI: allow >100% raising

It will be available in 6.3.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 9 László Németh 2019-05-29 12:38:20 UTC
Test: the test document in the first patch imported correctly, and the character formatting dialog shows 110% superscript text position.

Note: UI of MSO contains 1584 pt limitation, but OOXML has no such limitation, and MSO can load greater value, too. (Its character formatting dialog window shows a warning message after opening the text position page.) OpenDocument hasn't got limitation, see the commit messages:

===================================================
tdf#120412 DOCX filter: fix missing superscript

by editeng support of large superscript raising.

Maximal raising of superscript text is 1584 pt in MSO,
while LibreOffice didn't import the values greater
than 100% of the current font height. Using the maximal
percent value of the default 11 pt font, the limit
is 14400% now, fixing most of the import problems.
Greater raisings will be limited to 14400% during the
DOCX import.

Note: the standard doesn't limit the bigger percent
values, see "20.374 style:text-position" and
"18.3.23 percent" in OpenDocument 1.2.

===================================================
tdf#120412 character formatting UI: allow >100% raising

in superscript/subscript text positions instead of
changing the greater values (eg. imported from DOCX)
to 100% by accident, simply using the character
formatting window.
Comment 10 Commit Notification 2019-06-03 14:13:37 UTC
László Németh committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/32262b0a537207832d7d126d8427d8949b9e821d%5E%21

tdf#120412 char formatting UI: clean-up DFLT_ESC_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 11 Commit Notification 2019-06-05 09:33:00 UTC
László Németh committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

https://git.libreoffice.org/core/+/39e5b45f53ad5c3634450b123e809b3057617806%5E%21

tdf#120412 char formatting UI: clean-up DFLT_ESC_AUTO

It will be available in 6.3.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 12 Dieter 2019-07-12 07:28:31 UTC
VERIFIED FIXED in

Version: 6.4.0.0.alpha0+ (x64)
Build ID: 2f2f4767089512c34514896bc37823f9310e9dd4
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-07-10_02:13:57
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded

additional information: Value is 909%, since LO doesn't seem to have pt für raise/ lower value.
Comment 13 Commit Notification 2019-11-06 18:33:32 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/4b2752755609a4132417e57ca52bfc773c9ef897

tdf#120412 better unit test

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-11-18 08:26:21 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/227100ff4e5560c09c5a822052fc5ada541b8cc5

related tdf#120412 ww8import: allow > 100% escapement, fix calculation

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 15 Commit Notification 2019-11-19 16:20:12 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/3c341fd0eb43f4412499459207b51ae9a8b532a6

related tdf#120412 ww8import: allow > 100% escapement, fix calculation

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 16 Commit Notification 2019-11-28 16:29:45 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/4e7e0a29836f0c28471a2f5c605976453f6d29ae

NFC tdf#120412 cleanup: use DFLT_ESC_* more

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 17 Commit Notification 2020-02-18 06:46:47 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1e8c16d0487e366c31fb07a7503687eab92f0dcc

NFC tdf#120412 cleanup2: use DFLT_ESC_* more

It will be available in 7.0.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 18 László Németh 2020-06-11 11:00:43 UTC
Comment by Phil Krylov from https://gerrit.libreoffice.org/c/core/+/73166
(commit 32262b0a537207832d7d126d8427d8949b9e821d [tdf#120412 char formatting UI: clean-up DFLT_ESC_AUTO])

> It seems to me that this change broke all UNO scripts in the wild that have been using 101 and -101 magic numbers for setting automatic escapement.
Comment 19 László Németh 2020-06-11 11:19:35 UTC
(In reply to László Németh from comment #18)
> Comment by Phil Krylov from https://gerrit.libreoffice.org/c/core/+/73166
> (commit 32262b0a537207832d7d126d8427d8949b9e821d [tdf#120412 char formatting
> UI: clean-up DFLT_ESC_AUTO])
> 
> > It seems to me that this change broke all UNO scripts in the wild that have been using 101 and -101 magic numbers for setting automatic escapement.

Likely the new magic numbers are 14000 and -14000, but maybe if the scripts check greater than 100/lower than -101 they still work correctly without modification.
The problem is that these numbers are really magical, i.e. they are not part of the UNO API. If you could give more information about recent usage of this number, maybe we can plan an API extension, i.e. adding an IsAutoEscapement() or something similar in the future.
Comment 20 Phil Krylov 2020-06-11 18:44:38 UTC
(In reply to László Németh from comment #19)

The scripts I know of do not check the number. They _set_ CharEscapement of a text portion or a character style to 101 or -101 to get automatic super/subscript escapement, e.g.: https://forum.openoffice.org/en/forum/viewtopic.php?p=425333#p425333 . There is also https://extensions.libreoffice.org/en/extensions/show/alternative-dialog-find-replace-for-writer which uses the constants as well. The best solution IMHO would be to export the constant to UNO or otherwise provide a way to set automatic super/subscript escapement _and_ to check if it's set to automatic. Probably there is no way to magically fix the behaviour for the old scripts.