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)
Version:
(earliest affected)
4.0.0.3 release
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: dataLoss, filter:doc
Depends on:
Blocks: DOC-Fields
  Show dependency tree / graph
 
Reported: 2013-02-28 14:33 UTC by John
Modified: 2024-02-18 03:12 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Attachments
Attached word file illustrates this fields use (24.00 KB, application/msword)
2013-02-28 14:33 UTC, John 		Details
View All Add an attachment (proposed patch, testcase, etc.)

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: 4.0.0.3 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:
Version 3.6.4.3 
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:
https://wiki.documentfoundation.org/QA/BugTriage

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.

Version: 6.2.0.0.alpha1+
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.
Comment 9 QA Administrators 2021-04-05 03:53:45 UTC Comment hidden (obsolete)
Comment 10 QA Administrators 2024-02-18 03:12:43 UTC 
Dear John,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug