Bug 61618 - : Word file import field conversion
Summary: : Word file import field conversion
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
(earliest affected) release
Hardware: All All
: high major
Assignee: Not Assigned
Whiteboard: BSA
Keywords: dataLoss, filter:doc
Depends on:
Blocks: DOC-Fields
  Show dependency treegraph
Reported: 2013-02-28 14:33 UTC by John
Modified: 2019-04-05 22:04 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Attached word file illustrates this fields use (24.00 KB, application/msword)
2013-02-28 14:33 UTC, John

Note You need to log in before you can comment on or make changes to this bug.
Description John 2013-02-28 14:33:27 UTC
Created attachment 75696 [details]
Attached word file illustrates this fields use

In Word insert field {eq \o(\s\up2(+),\s\up2(_))} to create a plus above underscore character.
Import to writer, and the field is replaced with a blank.

Would it be possible to insert character 177 from Tahoma ± 

Alternately insert a warning mark when un-recognised word fields have been replaced, so the document can be readily searched as I am sure there will be other such cases.

Operating System: Windows 7
Version: release
Comment 1 Joel Madero 2013-02-28 17:59:06 UTC
Thank you for reporting this issue! I have been able to confirm the issue on:
Platform: Bodhi Linux 2.2 x64

+ + + + + + + + + + + + + + + + + + + + + + + ++ + + + + + + + + + + + + + +

As I've been able to confirm this problem on an earlier release I am changing the version number as version is the earliest version that we can confirm the bug, we use comments to say that the bug exists in newer versions as well.

Marking as:

New (confirmed)
MAJOR - loss of data
High - Loss of data default is a high priority, I think incorporating the character(s) is a better plan than giving a warning so hopefully that can get done.

+ + + + + + + + + + + + + + + + + + + + + + + ++ + + + + + + + + + + + + + +

LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link:

There are also other ways to get involved including with marketing, UX, documentation, and of course developing -  http://www.libreoffice.org/get-help/mailing-lists/. 

Lastly, good bug reports help tremendously in making the process go smoother, please visit WIKI to see examples of great bug reports.
Comment 2 QA Administrators 2015-02-19 15:33:44 UTC Comment hidden (obsolete)
Comment 3 John 2015-03-04 15:13:11 UTC
Bug repeated in V4.4.1 (Vista x32)

Slight change in behaviour as LO now shows the parts of the field code which are not yet understood. Although this could now be observed on a document review it doesn’t fix the underlying problem of not being able to parse the {eq} field code.
Comment 4 tommy27 2016-04-16 07:27:47 UTC Comment hidden (obsolete)
Comment 5 Zenaan Harkness 2016-08-30 03:49:55 UTC
filtersAndStorage component seems more appropriate.

Confirming this bug not solved - first line of example file now appears as follows:
Accuracy	\s\up2(+) 0.6%

LO5.2.0.4, Debian.
Comment 6 QA Administrators 2017-09-01 11:18:09 UTC Comment hidden (obsolete)
Comment 7 Thomas Lendo 2018-11-11 19:10:10 UTC
Still reproducible as in comment 5.

Build ID: afbfe42e63cdba1a18c292d7eb4875009b0f19c0
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: de-DE (de_DE.UTF-8); UI-Language: en-US
Calc: threaded
from today
Comment 8 Phil Krylov 2019-04-03 17:30:58 UTC
Actually there are two separate problems here. One issue is that the EQ fields have no corresponding functionality in LO (except specific usages for Ruby/Combined characters). Another issue is that the information in unsupported field is lost while roundtripping the formats.

The behaviour I am actually observing is:

1) When a EQ field can be parsed as a Combined Characters field or as Ruby styles applied to its content, it is carefully imported as such.
2) When a EQ field contains \o and optionally \ad switch (only) but cannot be parsed as a proper Combined Characters field, it is replaced by an Input field and the arguments are kept within that input field, formatting is lost.
3) When a EQ field contains \o and another backslash-escaped switch (\s \al \ac \ar) it is lost on import.

I think, a proper solution (before LO includes any functional replacement for EQ \o) could be:

1) Store EQ fields which cannot be parsed properly, in the same format as field types which are not handled at all: between fieldmarks of type ODF_UNHANDLED. This way they can be seen in the UI, can be processed programmatically and can survive saving back to Word formats. This part requires a patch I am going to post soon.

2) When these EQs stop being lost, one only has to install TexMaths extension and write a small macro converting \o() structures to LaTeX invocations using nested \makebox to achieve overlapping.