Bug 43219 - FILEOPEN: Captions numbers from MSWord .doc not shown (Shown if resaved as DOCX in MSO)
Summary: FILEOPEN: Captions numbers from MSWord .doc not shown (Shown if resaved as DO...
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: low normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: DOC
  Show dependency treegraph
 
Reported: 2011-11-24 02:16 UTC by Viktor Mileikovskyi
Modified: 2023-05-25 00:47 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
This file created by MS Office 2003 with numbered formulas (18.50 KB, application/msword)
2011-11-24 02:16 UTC, Viktor Mileikovskyi
Details
The file compared in MSO LO (94.15 KB, image/jpeg)
2019-09-13 12:33 UTC, Timur
Details
The file resaved as DOCX in MSO (18.23 KB, application/zip)
2019-09-13 12:35 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Viktor Mileikovskyi 2011-11-24 02:16:27 UTC
Created attachment 53829 [details]
This file created by MS Office 2003 with numbered formulas

Problem description: 
I try to open .doc document created by MS Word 2003 (such as attached).
This document contains formulas in tables with captions created by next steps:
By Insert->Reference->Caption we created new label named "(" with numeric value and ")" after it.
This caption inserted after the table with formula
And finally this caption cut-pasted to right cell of the table.
Next formulas created by copy-pasting first formula table.
When I try now to open this document in LibreOffice 3.4.4 or 3.4.3 (Windows or Linux versions) all links and captions converted to (0) .
Rightclick - Fields shows: (sorry for poor translation from Ukrainian)
Field type: Numbering range
Choice (or Selection): (
Format: Arabic (1 2 3)
Name: Unaccessible
Value: (+1
Level: None
Separator: Unaccessible

If I create any document with LibreOffice and save it to .doc there are no problems!
But I can not keep formula numbering in MS Word .doc documents opened by LibreOffice 3.4.3 and 3.4.4.
Possible reason is:
In genuine LO documents (.odt or .doc)
Rightclick -> Fields shows:
...
Value: Text+1
...
Is it a problem with MSWord's "(+1" ???
And how to fix or workaround?

Steps to reproduce:
1. Open attached document in LibreOffice (possible, OOo)

Current behavior:
Formula numbers (0), (0)

Expected behavior:
Formula numbers (1), (2)

Platform (if different from the browser): 
Intel Dual-Core T2330 1,6GHz 533MHZ FSB 1MB L2 Cache
Intel GL960 Express 
2GB RAM
Ubuntu 11.04 x86_64
Browser: Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0
Comment 1 tester8 2012-01-11 13:36:45 UTC
Reproduced with

LOdev 3.5.0beta2 
4ca392c-760cc4d-f39cf3d-1b2857e-60db978
Ubuntu 10.04.3 x86
Linux 2.6.32-37-generic Russian UI
Comment 2 A (Andy) 2013-05-04 08:36:41 UTC
reproducible with LO 4.0.2.2 (Win7 Home, 64bit)

Steps Done:

1. Open the attached document in WRITER
Result: Formula numbers ( 0), ( 0)

2. Open the attached document in WORD 2007
Result: Formula numbers ( 1), ( 2)


To Check the Field Data:
Double left mouse click on the figures "0" in the table or right mouse click on the figures "0" in the table and go to FIELDS.
Comment 3 QA Administrators 2015-03-04 02:19:31 UTC Comment hidden (obsolete)
Comment 4 Viktor Mileikovskyi 2015-03-06 13:53:30 UTC Comment hidden (obsolete)
Comment 5 tommy27 2016-04-16 07:26:23 UTC Comment hidden (obsolete)
Comment 6 Xisco Faulí 2017-09-21 21:54:28 UTC
Still reproducible in

Version: 6.0.0.0.alpha0+
Build ID: 86f256596c8566e80993e1cf6035bc3534b6f816
CPU threads: 4; OS: Linux 4.10; UI render: GL; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Comment 7 Roman Kuznetsov 2018-09-10 21:17:41 UTC
still repro in 6.1.1.1 on Windows 10
Comment 8 QA Administrators 2019-09-11 04:38:09 UTC Comment hidden (obsolete)
Comment 9 Timur 2019-09-13 12:33:06 UTC
Created attachment 154155 [details]
The file compared in MSO LO

No captions (and no zeros that used to be) from DOC in LO 6.4+. 
Note: LO opens numbers right from DOCX if resaved in MSO.
Comment 10 Timur 2019-09-13 12:35:02 UTC
Created attachment 154156 [details]
The file resaved as DOCX in MSO

Just for reference. The file resaved as DOCX in MSO
Comment 11 Xisco Faulí 2019-10-28 17:58:04 UTC
before https://cgit.freedesktop.org/libreoffice/core/commit/?id=d32bed7af67b08037e063c4b85aaa46c55ff7781 the caption numbers were displayed as (0), after the commit, they are displayed as ()
@Stephan, I thought you might be interested in this issue...
Comment 12 Stephan Bergmann 2019-10-29 12:39:32 UTC

(In reply to Viktor Mileikovskyi from comment #0)
> Created attachment 53829 [details]
> This file created by MS Office 2003 with numbered formulas
> 
> Problem description: 
> I try to open .doc document created by MS Word 2003 (such as attached).
> This document contains formulas in tables with captions created by next
> steps:
> By Insert->Reference->Caption we created new label named "(" with numeric
> value and ")" after it.

The attached Example.doc contains "SEQ ( \* ARABIC", which appears to violate the MS-DOC spec.  <http://interoperability.blob.core.windows.net/files/MS-DOC/[MS-DOC].pdf> 2.9.90 "flt" references [ECMA-376], and <http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%201st%20edition%20Part%204%20(PDF).zip> contains "Office Open XML Part 4 - Markup Language Reference.pdf", which, in 2.16.5.63 "SEQ", specifies the syntax

  SEQ identifier [ field-argument ] [ switches ]

and the requirement that "identifier shall start with a Latin letter and shall consist of no more than 40 Latin letters, Arabic digits, and underscores."  An identifier of "(" does not meet that requirement.

It appears to be a bug in MS Office 2003 that it allows the user to chose "(" as a name there.  It is not clear to me whether and how best to cater for such documents in LO.
Comment 13 QA Administrators 2021-10-30 04:36:57 UTC Comment hidden (obsolete, spam)
Comment 14 Justin L 2023-05-25 00:47:32 UTC
I don't see any reason to keep this bug report around. Stephan indicated that it seems to be an illegal field sequence. We only support a small subset of legitimate fields at this point, so supporting illegitimate fields is out of the question.