Bug 42346 - FILESAVE: Cross-references to certain numbered items (object, graphic, table) turn to plain text on export to .doc or .docx (works OK for headings and bookmarks)
Summary: FILESAVE: Cross-references to certain numbered items (object, graphic, table)...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: high major
Assignee: Tamás Zolnai
URL:
Whiteboard: interoperability BSA target:6.0.0
Keywords: filter:doc, filter:docx
: 47252 62216 84637 96117 99398 99624 100671 106584 (view as bug list)
Depends on:
Blocks: DOCX DOC Fields-Cross-Reference
  Show dependency treegraph
 
Reported: 2011-10-28 08:13 UTC by Clive van Hilten
Modified: 2020-05-20 07:49 UTC (History)
22 users (show)

See Also:
Crash report or crash signature:


Attachments
cross-reference test (10.05 KB, application/vnd.oasis.opendocument.text)
2012-05-07 02:33 UTC, Josef
Details
LibreOffice cross-reference breaks when exporting to Word 2000 (13.55 KB, application/vnd.oasis.opendocument.text)
2012-05-25 07:59 UTC, Josef
Details
result when saving to word format (14.00 KB, application/msword)
2012-05-25 08:09 UTC, Josef
Details
first attachment, edited by msWord 2007 and saved as docx (15.79 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2012-05-29 08:05 UTC, sasha.libreoffice
Details
first attachment, edited by msWord 2007 and saved as doc (31.50 KB, application/msword)
2012-05-29 08:06 UTC, sasha.libreoffice
Details
Odt file with "Figure caption" (59.21 KB, application/vnd.oasis.opendocument.text)
2015-08-09 15:15 UTC, deligeo
Details
Corresponding docx file with captions working. (91.41 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2015-08-09 15:16 UTC, deligeo
Details
Corresponding doc file exported using Libreoffice 5.0.0.5 (104.00 KB, application/msword)
2015-08-09 15:23 UTC, deligeo
Details
Isolated xml snippets of how LO and MSWord save a Figure caption and a cross-reference in docx (1.21 KB, text/plain)
2017-03-20 11:59 UTC, deligeo
Details
docx created using LO in ubuntu with bookmark to an illustration number. (38.11 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2017-03-20 14:16 UTC, deligeo
Details
ODT sample file with number hierachy (1.1, 1.2, ... 2.1, 2.2, ...) (226.65 KB, application/vnd.oasis.opendocument.text)
2017-11-06 13:09 UTC, Lars Jødal
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Clive van Hilten 2011-10-28 08:13:59 UTC
Problem description: Inserting a cross-reference to a numbered paragraph in a .doc file appears to work, but the cross-reference does not appear when the file is saved and subsequently reopened.

Steps to reproduce:
1. Create a new file and insert a number of numbered paragraphs
2. Insert one or more cross-references to the numbered paragraphs using Insert -> Cross-reference
3. Save the file as a .doc file, close and reopen it - the cross-references will not appear. 

If you perform steps 1 and 2 above in a new file and save it file in .odt format, it works perfectly. The issue seems therefore to be with LibreOffice's implementation of the .doc format in this particular area.

Current behavior: cross-references are lost

Expected behavior: cross-references should persist

Platform (if different from the browser): Ubuntu 10.04 (Lucid Lynx)
              
Browser: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.106 Safari/535.2
Comment 1 Clive van Hilten 2011-11-01 09:42:52 UTC
Note that the hyperlink remains active, but the text of the cross-reference disappears.
Comment 2 sasha.libreoffice 2012-04-18 22:33:11 UTC
Thanks for bugreport
in 3.3.4 and 3.5.2 on Fedora 64 bit not reproducible for me

Please, verify if in last version of LibreOffice still reproducible

Please, attach odt that demonstrates this problem when saved to doc
Comment 3 Josef 2012-05-07 02:29:45 UTC
Correction: when saving a file with a cross-reference, the cross references turn into plain text, but are no longer real links. This means, after saving the document in .doc or .docx the cross-references are broken.

I am having trouble to upload an example, but it is easy to reproduce:

Open an new .odt document.
Add a table.
Add a caption to the table.
Insert a cross reference to the caption of the table.
Save the file as .odt
Save the file as MS-Word document (.doc)
now close Openoffice and open the .doc file: the cross-reference no longer has a grey background - it is plain text now!
For comparison, the cross-reference works properly in the saved .odt file.

The same happens with cross-references to figures as well.

I marked this with importance "high" and "major", since it is really a show-stopper when trying to exchange any larger document with MS-Office users. Any larger document has at least tenth of cross-references and there is no way to export them properly. Since we cannot force our customers to use Libreoffice, we had to switch back to using MS-Word because of this bug.

Tested on Ubuntu 10.04, Debian stable, Windows(In reply to comment #2)
> Thanks for bugreport
> in 3.3.4 and 3.5.2 on Fedora 64 bit not reproducible for me
> 
> Please, verify if in last version of LibreOffice still reproducible
> 
> Please, attach odt that demonstrates this problem when saved to doc

(In reply to comment #2)
> Thanks for bugreport
> in 3.3.4 and 3.5.2 on Fedora 64 bit not reproducible for me
> 
> Please, verify if in last version of LibreOffice still reproducible
> 
> Please, attach odt that demonstrates this problem when saved to doc
Comment 4 Josef 2012-05-07 02:33:56 UTC
Created attachment 61119 [details]
cross-reference test

the attached file shows the behavior: save the file in MS-Word format (.doc or .docx): the reference "Table 1" is just plain text in the MS-Word document, no longer a link (e.g. if you insert another table above this one, the reference remains "Table 1"  instead of becoming "Table 2".
Comment 5 sasha.libreoffice 2012-05-07 05:40:57 UTC
Thanks for attachment.
Please, attach doc file with working reference, produced by Word.
(for developers can see how it should be inside of doc)
Comment 6 Josef 2012-05-25 07:59:42 UTC
Created attachment 62099 [details]
LibreOffice cross-reference breaks when exporting to Word 2000
Comment 7 Josef 2012-05-25 08:04:31 UTC
in the file "caption-by-word.odt" you can see the difference. The cross-reference created by Word works fine, even after re-export to Word format. The cross-reference created by LibreOffice becomes plain text.
Comment 8 Josef 2012-05-25 08:09:53 UTC
Created attachment 62101 [details]
result when saving to word format

I added the resulting .doc file, which is produced by LibreOffice

For completeness, this is what I used:

MS-Word 2007 on Microsoft Windows XP
LibreOffice 3.5.3.2 on Ubuntu 10.04
Comment 9 sasha.libreoffice 2012-05-29 08:05:26 UTC
Created attachment 62229 [details]
first attachment, edited by msWord 2007 and saved as docx
Comment 10 sasha.libreoffice 2012-05-29 08:06:15 UTC
Created attachment 62230 [details]
first attachment, edited by msWord 2007 and saved as doc
Comment 11 sasha.libreoffice 2012-05-29 08:15:02 UTC
Thanks for attachments. I also done some experiments: added caption to table using msWord, before table. And then added link to this table at the end of document.
Word added field: type "Ref", option "Link to paragraph".
IMHO Word (and doc format) understands only bookmarks in this situation. And links to bookmarks. And no advanced Writer fields. Therefore table number and link to it should be translated to bookmark and link to it when we save document to doc format.
Comment 12 Josef 2013-03-04 10:45:30 UTC
Changed the summary of this bug, to better reflect the issue: links to figures or tables turn into plain text on export to .doc or .docx

Changed the Version to unspecified, since nothing seems to happen, even though we had several new issues.

I can only emphasize, that this Bug is the main reason for not being able to work cooperatively with people using MS-Word, which is the reason why I need to keep MS-Word around.

Any serious technical document will use cross-references to figures and tables. Where I don't need to cooperate with MS-Word users, I use LaTeX. Without fixing this bug. LibreOffice is just a Word Reader for me, as I can't use it collaborativle with others, who use MS-Word (and I really can't convince my customers and business partners to use LibreOffce).
Comment 13 Nick 2013-03-25 11:22:22 UTC
I can also confirm that this bug is a showstopper for me.
Having to ditch LibreOffice and go back to Word. Shame.
Comment 14 Cor Nouws 2013-08-01 15:27:03 UTC
*** Bug 62216 has been marked as a duplicate of this bug. ***
Comment 15 Jan Janikovic 2014-01-08 23:16:59 UTC
As of 4.1.4.2 version the cross-references in a document saved as doc and docx will be converted as follows after re-opening:
doc: Cross-reference will be broken. If the cross-reference points to the number of the numbered list, the cross reference will not update its value when referenced-to list item number is changed
docx: Cross-reference will be converted to the field text.

Easiest way to reproduce:
-------------------------
1. Open a new document in LibreOffice
2. Type "fn" (without quotes) and press F3 - creates a numbered formula
3. Press Enter
4. Type "fn" and press F3 and press enter
5. Choose Insert->Cross-reference, In the field "Type" choose "Text, in the field "Selection" choose (2), in the field "Insert reference to" choose Numbering. (This will create a cross reference to the second formula
6. Save document as doc, or docx
7. Reopen document

If the document was saved as "doc", the cross reference number will not change to "3" in case you enter a formula between the two formulas already in the document

If the document was saved as "docx" the cross-reference shows just "Text"
-----------------------------------------------------------------------

I agree with the statements above. This is a use-stopper for technical documentation in the group if group uses mainly Word => Please consider increasing bug importance
Comment 16 Jan Janikovic 2014-01-08 23:18:53 UTC
Forgot to state OS: Windows XP and Windows 7
Comment 17 Cor Nouws 2014-01-09 00:05:07 UTC
just a quick note: did some extensive testing recently. References to numbered objects (tables, formuleas, images) are broken after saving as (maybe one exception - should check) But cross references to headings, bookmarks work fine.
(Sorry, details missing atm)
Comment 18 wahrschein 2014-10-27 16:21:38 UTC
I'm working on OS X and as well cross-references as hyperlinks disappear after the document is closed. This occurs in text documents as well as in presentations, no matter in which format the document is saved.
To reproduce just enter any cross-reference into a text document or a hyperlink into a presentation, save and close is, open it again and check the cross-reference or hyperlink. The cross-reference will have turned to plain text, the hyperlink will be dead.
Comment 19 sasha.libreoffice 2014-10-29 10:11:21 UTC
Thanks for additional testing.
Sorry, but "version" is version of LO where bug appears. Not a current version. If bug disappears we just close bugreport. And "hardware" is list of all platforms where bug reproducible. Not a specific one.
Changing back to "unspecified" (very ancient bug) and "All".
Comment 20 deligeo 2014-11-06 12:31:50 UTC
Bug still exists in 4.3 branch.
Please see: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=84637
Comment 21 V Stuart Foote 2014-11-06 15:24:27 UTC
*** Bug 84637 has been marked as a duplicate of this bug. ***
Comment 22 V Stuart Foote 2014-11-06 15:38:15 UTC
Not to discount the frustration of incompatabilities with export filtering to MS OOXML or earlier binary formats, but the more important question for folks should be how well does MSOffice 2013, 2010 2007 handle the cross references in our native ODF 1.2 compliant document formats.

Office 2013/Office 365 handles most facets of ODF complaint documents correctly--and so MS users are not bound to MS OOXML formats.
Comment 23 Jean-Sébastien Gosselin 2014-11-06 17:01:24 UTC
Following V Stuart Foote last post, here is my little contribution to testing.

Opening the "cross-reference.odt" document that is provided with this bug report with MS Office 2007 in Windows 7 did the following:

Upon opening the .odt document, a message appeared stating:
"The file cross-reference.odt cannot be opened because there are problems with the content".

and

"Word found unreadable content in cross-reference.odt. Do you want to recover the contents of this document? If you trust the source of this document, click Yes."

Upon clicking yes, the document opens and the cross-references are converted to text, but correctly (which is not the case the other way around as I highlighted in Bug 84637). I've tested it with a new document produced with LO Version: 4.3.3.2 and the same behaviour occurs.

For my part, this is exactly what I wanted. Of course, keeping the interactive fields would have been better, but well, I can live with that. I always keep a main branch of my document saved in .odt anyway. So I thank you M. Foote for giving me the idea to use MS Office to convert my .odt into .docx. Never thought of doing that XD.

Best Regards
Comment 24 Björn Michaelsen 2014-11-28 09:45:21 UTC Comment hidden (obsolete)
Comment 25 tommy27 2014-12-07 18:45:28 UTC
please retest with 4.3.4.1 or 4.4.0.0 beta
if bug is still present please move this from mab4.2 list to mab4.3 list since 4.2.x reached the end of life
Comment 26 Jean-Sébastien Gosselin 2014-12-07 20:27:57 UTC
Tested in LO Version: 4.3.4.1 from the ppa in Ubuntu 14.04,

Cross-reference to Number range variables (Figures, Table, Illustration, etc.) are still converted to text when saved in docx format, and most annoyingly, are not converted to text correctly as I described in Bug 84637.
Comment 27 Jean-Sébastien Gosselin 2014-12-07 20:39:37 UTC
Is there a way in LO to convert cross-references to text intentionally?

In MS Office, I can simply :

(1) ctrl-a
(2) ctrl-shift-F9

But I haven't found a way to do this in LO yet. Thanks.
Comment 28 Ambrose Li 2015-01-14 09:48:51 UTC
The bug is still present in 4.3.5.2.

Not only does the cross reference turn into plain text, a phantom space is inserted before the reference, and the numbering disappears. For example, a live reference for “Figure 1” will turn into “ Figure”.
Comment 29 mace 2015-02-28 12:32:31 UTC
Still present in 4.4.1.2 on Ubuntu.

Start libreoffice.
Insert any image.
Insert Caption for image.
Insert Cross-reference (category and number for me).
Safe as .docx.
Close
Open with LO or MS Word2010.
--> Numbering in Caption and in Crossreference disappeared.
No problem when saving as .doc

This bug is high priority for me. It is really embarrasing when I send files to my boss who is running MS Word.
Comment 30 Tomislav Nakic-Alfirevic 2015-03-16 09:40:39 UTC
The original problem description fits what I see perfectly: "Inserting a cross-reference to a numbered paragraph in a .doc file appears to work, but the cross-reference does not appear when the file is saved and subsequently reopened." (additional behaviour described by Clive van Hilten also observed, 100% repeatable)

I am using Version: 4.2.6.3 Build ID: 420m0(Build:3) on Ubuntu 14.04.

I'm afraid these are the kinds of issues which prevent use of LO in a hybrid (MS/LO) environment, especially when they go unresolved for 3.5 years.
Comment 31 Tomislav Nakic-Alfirevic 2015-03-16 11:46:31 UTC
(In reply to Tomislav Nakic-Alfirevic from comment #30)

> I'm afraid these are the kinds of issues which prevent use of LO in a hybrid
> (MS/LO) environment, especially when they go unresolved for 3.5 years.

One workaround that I've found is to use .docx instead of .doc: the references remain intact after closing and reopening the document.
Comment 32 andis.lazdins 2015-03-16 12:07:37 UTC
Unfortunately the proposed workaround is valid (if it really works) for very simple documents, because in the most case to me saving to docx format results in non-readable or considerably damaged document if I try to open it in Word 2007. However, I don't think export to docx results in retained cross-references. For me, the difference between cross references exported from 4.3.6 to doc in docx is text values of cross references in doc file and no values at all in docx file.

I can agree with comment above, that this issue is one of the worst in libreoffice interactions with word formats and considering, how much time it take in word (which have the same interface and functionality for cross-references since Word 6, I guess) to restore all cross-references, it is really painful issue.
Comment 33 V Stuart Foote 2015-03-16 12:24:44 UTC
Again, yes the fidelity of export filters to MSO and OOOXML formats remains an issue.  However, please consider comment 22

Why are you not working in/exchanging native ODF 1.2 LibreOffice documents?

Microsoft offers the non-standards compliant formats in their applications, and LibreOffice/TDF/Oasis does not control their specifications.
Comment 34 andis.lazdins 2015-03-16 12:42:19 UTC
(In reply to V Stuart Foote from comment #33)

> Why are you not working in/exchanging native ODF 1.2 LibreOffice documents?

Unfortunately ODF is not dominating in the market and therefore the Libreoffice developers should consider exporting to other formats as a priority. Generally, if I'm sending something as .doc and not .pdf, it is supposed for further editing, most probably with Microsoft Word and, most probably, by a person which don't know and don't want to know anything about Libreoffice, but want to have working cross-references besides other functionality...
Comment 35 V Stuart Foote 2015-03-16 13:18:08 UTC
(In reply to andis.lazdins from comment #34)
> ... Generally, if I'm sending something as .doc and not .pdf, it is
> supposed for further editing, most probably with Microsoft Word and, most
> probably, by a person which don't know and don't want to know anything about
> Libreoffice, but want to have working cross-references besides other
> functionality...

And, again, why not send as native OASIS ODF 1.2? Rather than depending on export filters to a proprietary MSO binary format, or a marginally functional OOXML specification?

Office 365 Word, and Word 2013 handle ODF 1.2 reasonably well. At least as well as LibreOffice documents exported to MSO .doc or OOXML .docx--of course for specific uses like cross reference footnoting and YMMV.

ODF 1.2, or emerging 1.3, will likely never be perfect, especially as Microsoft screws their own users on format consistency inter-release, but it is functional for exchange. And as noted, if collaborative editing is not needed--exchange of filter exported PDF is often sufficient.
Comment 36 andis.lazdins 2015-03-16 13:54:56 UTC
(In reply to V Stuart Foote from comment #35)
> 
> And, again, why not send as native OASIS ODF 1.2? 

Short answer - I don't want to loose my job and I want to use Libreoffice :)

Good luck and patience to developers!
Comment 37 Jean-Sébastien Gosselin 2015-03-16 14:21:09 UTC
(In reply to andis.lazdins from comment #36)
> (In reply to V Stuart Foote from comment #35)
> > 
> > And, again, why not send as native OASIS ODF 1.2? 
> 
> Short answer - I don't want to loose my job and I want to use Libreoffice :)
> 
> Good luck and patience to developers!

I'm in the same situation. My bosses kindly allow me to work in LO, but they expect a working .doc or .docx document at the end of the day.

That being said, I understand the position of LO developers. It feels to me that they are better working in improving features for the current ODT format than trying to achieve perfect compatibility with a proprietary format that is continually in development and for which thay have no control at all. Handling the "hybrid environment" problem on the MS Word side seems a more efficient approach, since .odt is an open format, but .doc is not. 

Sad but True, maybe the use of LO is not adequate for all situation in all context.
Comment 38 andis.lazdins 2015-07-12 10:42:27 UTC
Hello!

Is there any plans to solve this problem? It is really BIG issue. I found that sometimes numbering of cross-references survive on export from odt to doc, but nothing - on export from odt to docx. To have export of cross references feature at least in export to doc would be excellent. Surviving of some of numberings demonstrates, that technically it doesn't requires new solution. 

Libreoffice cross-reference function is much more advanced and more convenient to use than the same function in word (I think word has the same interface and implementation of cross-references since 1997). I'm sure many people will be happy if they will not have to recreate cross-references after exporting their documents.
Comment 39 V Stuart Foote 2015-07-12 19:40:27 UTC
Work around as in comment 23--exchange ODF 1.2 and ask user (or yourself) to open in MS Word and complete conversion there.

While work remains to be done on OOXML/MS Doc export filters, the fidelity of a MS Office conversion from ODF 1.2 should be fairly high as LibreOffice has an obligation to generate standards compliant ODF 1.2, less so in export filter creation of OOXML or MS binary formats.
Comment 40 deligeo 2015-08-09 15:05:28 UTC
Testing under LibreOffice 5.0.0.5 under Ubuntu 14.04 the issue is still reproducible.
As was done in https://bugs.documentfoundation.org/show_bug.cgi?id=59886 I will change this to Critical as it leads to loss of information when converting to docx format. (Same order of importance as in bug mentioned, however very different response).
The proposed ODF intermediate export is not really a solution.
Comment 41 deligeo 2015-08-09 15:15:28 UTC
Created attachment 117785 [details]
Odt file with "Figure caption"
Comment 42 deligeo 2015-08-09 15:16:15 UTC
Created attachment 117786 [details]
Corresponding docx file with captions working.
Comment 43 deligeo 2015-08-09 15:22:05 UTC
I have spoken too soon, apologies for Post #40.
Testing in MS Word, it appears the captions are there (and in Libreoffice 5.0.0.5) It is the formatting that is messed up leading to the caption being partially hidden.
Export in doc and docx both work when tested in Libreoffice 5.0.0.5 and MSWord 2002. The formatting is a different issue.
Correcting my own mistake setting this bug to resolved.
Please test further and re-open if you still see the problem.
Comment 44 deligeo 2015-08-09 15:23:24 UTC
Created attachment 117787 [details]
Corresponding doc file exported using Libreoffice 5.0.0.5
Comment 45 Timur 2015-11-30 10:31:50 UTC
The issue doesn't seem solved, and it's not about saving captions, it's about preserving cross-references. 
Please don't close if you are not sure. Even then, it wouldn't be Fixed, it would be WFM.
Comment 46 andis.lazdins 2015-11-30 10:44:06 UTC
In 5.0.3.2 the problem is still there, cross-references are converted to plain text on conversion to doc and their disappears on conversion to docx. Sorry for repeating, but it is HUGE problem. In our institute we are spending a lot of work hours to regenerate cross-references after conversion and we have to keep working versions of Word which is another tricky thing in Linux environment.
Comment 47 tommy27 2015-11-30 10:44:18 UTC
this is an already long and old report which is getting hard to follow

what about writing a new report about the residual issues with a summary of the relevant posts and start over from there?
Comment 48 andis.lazdins 2015-11-30 10:52:01 UTC
Just tried with 5.1.0.0.beta1-buildfix1. The same result - cross-references transforms into plain text or disappears.
Comment 49 andis.lazdins 2015-11-30 10:58:07 UTC
I would say that there are no residual issues - the problem is there since first reported in 2011 and before that in OOo, with no changes, improvements, or partial solutions.
Comment 50 tommy27 2015-11-30 11:12:15 UTC
(In reply to andis.lazdins from comment #49)
> I would say that there are no residual issues - the problem is there since
> first reported in 2011 and before that in OOo, with no changes,
> improvements, or partial solutions.

OK, comment 43 was misleading in that sense.

however I think that a summary would be appreciated.
Comment 51 Cor Nouws 2015-11-30 12:08:49 UTC
(In reply to tommy27 from comment #47)
> this is an already long and old report which is getting hard to follow


People should read the summary before posting maybe  :)
There is a clear distinction between references that are retained, and references that are not.
Comment 52 tommy27 2015-11-30 12:50:54 UTC
@Cor
I don't understand if that was sarcasm or whatever...
I've already seen many long bug reports with a summary post which is inserted in the title... see Bug 58358

this helps people to not get lost in very long discussions, expecially in those bugs where the status has been changed many times so you see comment telling it's fixed and other telling is still there...

a summary is needed to semplify things
Comment 53 Cor Nouws 2015-11-30 13:05:54 UTC
(In reply to tommy27 from comment #52)
> @Cor
> I don't understand if that was sarcasm or whatever...

Was not meant as such. More that I see chaotic postings that could be simpler if people do read. (And I'm not saying that I do not make the same mistake now and then too ;) )
Comment 54 Joel Madero 2015-12-01 01:03:47 UTC
Why was this bug set back to NEW with absolutely no comment? It was closed months ago....also 40+ comments makes it incredibly hard to follow...new bug report likely a good idea
Comment 55 V Stuart Foote 2015-12-01 01:33:09 UTC
(In reply to Joel Madero from comment #54)
> Why was this bug set back to NEW with absolutely no comment? It was closed
> months ago....also 40+ comments makes it incredibly hard to follow...new bug
> report likely a good idea

Umm, please see comment 45
Comment 56 Rolf Bartstra 2015-12-03 15:39:59 UTC
*** Bug 96117 has been marked as a duplicate of this bug. ***
Comment 57 wilbert.opdedijk 2015-12-16 11:10:40 UTC
if i download a fileand open it. allof the images doesn't load even with odt
its very frustrating because i can do my homework right now

the image number does appear but the image does'nt
Comment 58 Cor Nouws 2015-12-16 11:21:10 UTC
Hi WIlbert,

(In reply to wilbert.opdedijk from comment #57)
> if i download a fileand open it. allof the images doesn't load even with odt
> its very frustrating because i can do my homework right now
> 
> the image number does appear but the image does'nt

Sorry to read that you're having trouble Wilbert. Your issue does not look related to this bugreport. So it better to either start with users support 
We have great community support:
  http://www.libreoffice.org/get-help/community-support/
Or you file a new bug (search for duplicates).
Thanks - Cor
Comment 59 andis.lazdins 2016-03-08 15:16:01 UTC
The problem is still there in 5.1.1.3, Ubuntu 14.04 32 bit. It's really annoying considering that the bug report recently passed 4 years anniversity.
Comment 60 Joel Madero 2016-03-09 02:20:58 UTC
(In reply to andis.lazdins from comment #59)
> The problem is still there in 5.1.1.3, Ubuntu 14.04 32 bit. It's really
> annoying considering that the bug report recently passed 4 years anniversity.

As always patches welcome....options never change:
1) Fix it yourself;
2) Find someone to fix it;
3) Pay for a fix;
4) Wait for a *volunteer* to *choose* to fix it
Comment 61 Joel Madero 2016-03-09 02:22:50 UTC
Looking at the history - there's zero reason why this should be critical. Changing back to Normal

Normal: Can prevent high quality work
Comment 62 andis.lazdins 2016-03-09 06:46:16 UTC
(In reply to Joel Madero from comment #60)

Our company is sending annual private donations to libreoffice, which is equal to buying of new Microsoft office licences every year. To my understanding it should be enough, at least to receive different attitude. We would be happy for option to address donations to solve specific problems. We are users (for more than 10 years of star / open / libreoffice) and we are not dealing with development of the program. We are very happy with functionality and simplicity of the Writer software, but we are living in a world where we should exchange documents with organizations dealing only with Microsoft office and we have to compete with others using Microsoft office and not having our problems of compatibility. 

> 
> As always patches welcome....options never change:
> 1) Fix it yourself;
> 2) Find someone to fix it;
> 3) Pay for a fix;
> 4) Wait for a *volunteer* to *choose* to fix it
Comment 63 andis.lazdins 2016-03-09 06:59:19 UTC
(In reply to Joel Madero from comment #61)
> Looking at the history - there's zero reason why this should be critical.
> Changing back to Normal
> 
> Normal: Can prevent high quality work

Can you look on this issue from a user point of view? To maintain compatibility with Microsoft office we need to have copies of Microsoft office on every computer and we have to spend time to replace broken references in Word. There might be about a hundred of cross-references in average document and unfortunately there is no efficient workaround. Respectively, for our team this is the most critical problem with Writer.
Comment 64 Nick 2016-03-09 11:07:07 UTC
(In reply to Joel Madero from comment #61)
> Looking at the history - there's zero reason why this should be critical.
> Changing back to Normal
> 
> Normal: Can prevent high quality work

I cannot use LibreOffice because of this bug as it makes document interchange with people who use MS Office too difficult. I don't think people in a similar situation are a corner case of trying to do something particularly unusual.
Comment 65 Cor Nouws 2016-04-19 16:36:51 UTC
*** Bug 99398 has been marked as a duplicate of this bug. ***
Comment 66 andis.lazdins 2016-04-20 04:50:32 UTC
Hope that another bug report will provide more motivation to solve this terrible issue.
Comment 67 kc.okane 2016-04-20 16:06:50 UTC
Interoperability with MS is not desirable, it is mandatory. 

Discovering the hundreds of table and figure references were reduced to gibberish when stored in DOCX format - the format required for submission - was not good. 

I did discover a workaround: upload the ODT file to Google Docs and then download it as DOCX. There are some issues with merged cells in tables but easily fixed. 

It appears that Google takes interoperability seriously.
Comment 68 V Stuart Foote 2016-04-20 17:13:47 UTC
(In reply to kc.okane from comment #67)
> Interoperability with MS is not desirable, it is mandatory. 
> 

No, our mandatory format is Oasis ODF 1.2 -- OOXML is secondary.

> Discovering the hundreds of table and figure references were reduced to
> gibberish when stored in DOCX format - the format required for submission -
> was not good. 
> 
> I did discover a workaround: upload the ODT file to Google Docs and then
> download it as DOCX. There are some issues with merged cells in tables but
> easily fixed. 
> 

Meaning that as the LibreOffice generated ODF 1.2 .odt is standards compliant, Google is able to filter convert it to OOXML.  Meaning we've done our mandatory part. Of course it would be nice if our OOXML filters were equally effective.

> It appears that Google takes interoperability seriously.

Sure they do ;-)
Comment 69 andis.lazdins 2016-04-20 19:14:30 UTC
(In reply to kc.okane from comment #67)
> 
> I did discover a workaround: upload the ODT file to Google Docs and then
> download it as DOCX. There are some issues with merged cells in tables but
> easily fixed. 
> 

Unfortunately there are some other compatibility issues with google docs and it is possible to have destroyed file in the output. My colleges are using google doc to export files to docx to be sure that the file can be opened by recipients
Comment 70 Terrence Enger 2016-05-04 15:58:42 UTC
*** Bug 99624 has been marked as a duplicate of this bug. ***
Comment 71 Lars Jødal 2016-06-29 08:57:57 UTC
This is an attempt of summarizing a very long discussion.

Background: Items like illustrations, tables etc. can be numbered automatically by insertion of a number field. This happens automatically when inserting a figure legend. The number field can then be referenced in the text, providing both a link to the referenced object, and ensuring that the numbers change if the number of the original object changes, e.g. because a new illustration was added earlier in the document.

The problem: While the references works fine within LibreOffice and the .odt format, the cross-references are lost or garbled if the document is saved in .doc or .docx format. This loss of data is not seen until the .doc or .docx file is re-opened (in either LO or in MS Word).
As described in comment #15 (and in compliance with my own experiments), the behaviour depends on which format was used:

a) Saved from LO as .doc: The reference turns into plain text, i.e., it is lost as a reference and will also no longer be updated if the number of the original item changes.

b) Saved from LO as .docx: The reference number turns into the field text, e.g. "Illustration 4" may become "Illustration Illustration".

Possible work-around: Comment #67 indicates that Google Docs can be used to work around this problem (I have not tested this myself).


Part of the discussion has been about the importance of this bug and how come it can persist for years without being fixed (the original posting is from 2011, and the bug persists by 2016 and LO version 5.1.3.2). However, I would like to take a different angle.

As a user, I have a very high regard of the people who have developed and maintains LO, and makes it available for free. Thanks! I have little or no knowledge of the details of the .doc and .docx formats, but I guess this is a complicated problem - otherwise it would probably have been fixed a long time ago.

As a user, I am among the people who consider this a very problemtic bug, which hinders my use of LO when working together with people who prefer MS Word. Comment #37 describes some of the reasons why the .odt format cannot always be used in exchange with other people. Like it or not, MS Word and their formats have the advantage of majority - at least for now. Put another way: Saying "I have a problem with your format, so you should use my format" will not win many friends or convince people that LO is a good product. (Yes, in effect MS Office is saying the same - does that win friends among anybody reading this posting?)

So, as a user, I hope very much that some volunteer(s) will invest time and creativity in nailing down and solving this annoying and problematic bug! Hopefull addition: Comment #4 to comment #11 contains examples to work with and at least one technical observation...

Still hoping - regards to everybody dedicating time to maintaining LO,
Lars J
Comment 72 Cor Nouws 2016-08-05 22:00:22 UTC
*** Bug 100671 has been marked as a duplicate of this bug. ***
Comment 73 andis.lazdins 2017-01-19 07:34:49 UTC
"Celebrating" another anniversary of this "forever new" bug I would like to ask if somebody has found any applicable workaround for maintaining cross-references when exporting to doc and docx?
I don't know how time consuming is elaboration of the solution or at least workaround, which can be used with existing and new documents, but if it is reasonable I can support financially development of the solution, if there are any volunteers.
Comment 74 john 2017-03-09 23:42:11 UTC
In LibreOffice 5.2.5.1, I have found that instead of plain text, some references get converted to nonsense ("Eq. 1" --> "Eq. Text", literally the word 'Text' appears in Word) or else disappear completely ("Figure 1" --> " Figure", number disappears, space inserted before the word 'Figure'.

With many documents required to be distributed in Word format in various contexts it is CRITICAL that files exported from LibreOffice not lose content! This is a high priority bug, in my view.
Comment 75 andis.lazdins 2017-03-10 05:27:47 UTC
(In reply to john from comment #74)
> 
> With many documents required to be distributed in Word format in various
> contexts it is CRITICAL that files exported from LibreOffice not lose
> content! This is a high priority bug, in my view.

Completely agree! Our company has some funding possibilities if there are volunteers ready elaborate a solution. We are wasting enormous amount of time and we have to keep a copy of Word to be able to collaborate with our contractors because of this really critical bug.
Comment 76 andis.lazdins 2017-03-10 05:30:01 UTC Comment hidden (obsolete)
Comment 77 deligeo 2017-03-20 11:59:58 UTC
Created attachment 132025 [details]
Isolated xml snippets of how LO and MSWord save a Figure caption and a cross-reference in docx

To help isolate this issue: 4 xml snippets from 2 docx files that show how MS Word and LO treat a Figure caption numbering and how they cross-reference to it. It appears LO does not save enough information for a functional reference.
Comment 78 deligeo 2017-03-20 12:19:01 UTC
As can be seen in the previous attachment, LO in fact does not add a bookmark when creating a numbered entry which is exactly what MSWord does.
Then when cross referencing MSWord refers to that bookmark. (LO does not as there is no bookmark to refer to)

Using the information I gathered, I propose the following workaround (a hack) which appears to work.

- Insert any numbered item as normal. (example:  Figure 1:...)
- Select the Text including the auto-numbering and insert a bookmark. Do not use any spaces or non text characters in the bookmark name.(Naming example 'Fig1' not 'Fig 1')
- When you need to cross-reference this go to Insert cross-reference select bookmarks and select the newly created bookmark.

This will create a structure in the docx file similar to what MSWord would do for a cross-reference.
Saving as doc or docx from LO 5.3 now preserves the cross-referencing without issues.
This method is by now means a solution as it is cumbersome and non automatic but it at least provides a working document with Cross references working as expected.
Comment 79 andis.lazdins 2017-03-20 13:19:42 UTC
(In reply to deligeo from comment #78)
>  
> - Insert any numbered item as normal. (example:  Figure 1:...)
> - Select the Text including the auto-numbering and insert a bookmark. Do not
> use any spaces or non text characters in the bookmark name.(Naming example
> 'Fig1' not 'Fig 1')
> -
This solution works fine. I prefer to write title of reference, when I adding bookmarks, because numbering is changing and later it becomes really confusing to find right bookmark. For me it's ok to use spaces in bookmark name. Word recognize them as references.

> 
> > Saving as doc or docx from LO 5.3 now preserves the cross-referencing
> without issues.

It doesn't work for me. Just tried with Libeoffice 5.3.2.1. All cross-references are destroyed on save as docx. Instead of cross-reference to "Table 1" I got "Table" without number or "Table Table". It is exactly the same as before.

Thank you a lot for workaround! I realized that people using Word are doing something similar when they need number before reference type (like 1 Table, it is normal order in Latvian language), which is (or was) not possible in Word since ancient times. It is actually one great benefit of Libreoffice.
Comment 80 andis.lazdins 2017-03-20 13:29:42 UTC
(In reply to andis.lazdins from comment #79)
> (In reply to deligeo from comment #78)

> This solution works fine. I prefer to write title of reference, when I
> adding bookmarks, because numbering is changing and later it becomes really
> confusing to find right bookmark. For me it's ok to use spaces in bookmark
> name. Word recognize them as references.
> 
Indeed, spaces are not allowed in bookmarks. It works converted once to word, but are broken if file is opened one more time in Libreoffice.

I found also that cross-references created in Word persists, when opened in Libreoffice. They are converted to bookmarks and remains during following editions. It would be great to do something similar for exporting to Word, especially because it is already implemented for import.
Comment 81 deligeo 2017-03-20 13:50:30 UTC
(In reply to andis.lazdins from comment #79)

> 
> It doesn't work for me. Just tried with Libeoffice 5.3.2.1. All
> cross-references are destroyed on save as docx. Instead of cross-reference
> to "Table 1" I got "Table" without number or "Table Table". It is exactly
> the same as before.

Try including one more character after the auto-numbering.
I use Figure 1: as the auto-numbering schema.
when I bookmark Figure 1 (without the : ) It does ot work.
But when I use "Figure 1:" as the text to bookmark.
The cross-reference initially includes the : which is ugly. But upon saving and reopening the : goes away and all is well.
I can upload a docx example if needed.
Comment 82 andis.lazdins 2017-03-20 13:57:09 UTC
(In reply to deligeo from comment #81)
> 
> Try including one more character after the auto-numbering.
> I use Figure 1: as the auto-numbering schema.
> when I bookmark Figure 1 (without the : ) It does ot work.
> But when I use "Figure 1:" as the text to bookmark.
> The cross-reference initially includes the : which is ugly. But upon saving
> and reopening the : goes away and all is well.
> I can upload a docx example if needed.

Bookmark method works for me both in LO 5.2.x and 5.3.x.

I understood from the comment, that 5.3.x is able to export to docx ordinary cross-references, which unfortunately is not a case.

Sample file would be great
Comment 83 deligeo 2017-03-20 14:16:17 UTC
Created attachment 132026 [details]
docx created using LO in ubuntu with bookmark to an illustration number.

As requested a docx created using LO in ubuntu with the bookmark method described above. It works in Word and numbers get updated to point to the correct figure when another illustration is added before the existing one.
Comment 84 andis.lazdins 2017-08-03 04:56:49 UTC
The problem still persist in 5.3.4.2 Ubuntu Linux 64 bit. In docx format cross-references are completely broken on export and in doc format they are converted to text. It is interesting that cross-references still persist in doc file if it is opened in LibreOffice and they can be updated, but still all cross-references appears as text when opened in Word.
The workaround to convert cross-references to bookmarks is working, however it requires addditional work and it is not convenient in case of many cross-references and changing document structure.
Comment 85 Commit Notification 2017-11-04 18:11:26 UTC
Tamás Zolnai committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=98bc7215935f1eb2e0dc6f1db826d8e729430c13

tdf#42346: DOCX export of cross-references to objects

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 86 andis.lazdins 2017-11-04 19:34:09 UTC
(In reply to Commit Notification from comment #85)
> Tamás Zolnai committed a patch related to this issue.

> 
> It will be available in 6.0.0.
> 

Excellent news, will check it!!!
Comment 87 Lars Jødal 2017-11-06 13:09:48 UTC
Created attachment 137569 [details]
ODT sample file with number hierachy (1.1, 1.2, ... 2.1, 2.2, ...)
Comment 88 Lars Jødal 2017-11-06 13:26:29 UTC
(In reply to Commit Notification from comment #85)
> Tamás Zolnai committed a patch related to this issue.
> It has been pushed to "master":
> 
> http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=98bc7215935f1eb2e0dc6f1db826d8e729430c13
> 
> tdf#42346: DOCX export of cross-references to objects
> 
> It will be available in 6.0.0.
> 
> The patch should be included in the daily builds available at
> http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
> information about daily builds can be found at:
> http://wiki.documentfoundation.org/Testing_Daily_Builds
> 
> Affected users are encouraged to test the fix and report feedback.

Thanks for this patch, which comes a very long way on solving this long-standing issue! I have tested it a bit, including numbering with hierarchy (see attachment 137569 [details]). Basically I find:

DOCX format: 
- Cross-references are now retained as cross-references. (Yes!!!)
- Text formatting like bold text is copied to the cross-reference (unlike LO, where the cross-reference takes the format of the destination text).
- If number hierarchies are used, then the cross-reference correctly shows the hierarchy (1.1, 1.2, 2.1, 2.2), but unfortunately the original figures and tables are numbered consecutively (1, 2, 3, 4).

DOC format: As before, cross-references are saved as text, i.e. the cross-references are lost as references.

In summary, the DOCX format appears to work for standard numbering, but partly fails for hierarchy numbering. DOC format still loses cross-formatting (which may be acceptable as long as DOCX is an option).
Comment 89 Tamás Zolnai 2017-11-06 14:00:29 UTC
> - If number hierarchies are used, then the cross-reference correctly shows
> the hierarchy (1.1, 1.2, 2.1, 2.2), but unfortunately the original figures
> and tables are numbered consecutively (1, 2, 3, 4).

Thanks for the testing! It would be good to find out whether this kind of numbering is allowed in MSO Word. I had a quick look, but I can't see an option like that. We can't export more what MSO support. Also might be a good idea to create a new bug report for this issue, since it seems it's not about the cross-references, but the numbering field.
Comment 90 andis.lazdins 2017-11-07 06:04:45 UTC
Export to docx works fine like described in previous comment. Export to doc still results in plain text in the cross-reference. For our team it is enough to have at least docx version working.

Excellent job. I hope it will be implemented in 5.3 and 5.4 versions.

Captions including chapter number with ability to select between Heading 1, 2, 3, ... is possible in Microsoft word. For me export of Captions and cross-references containing chapter number to docx format works fine now.

I have English language both in Word and Libreoffice, respectively heading is called Heading in both programs. There are compatibility issues if Latvian language is set in one of computers and different Word versions are used. This might be the reason for the problem mentioned in previous comment, however I'm not sure.
Comment 91 Lars Jødal 2017-11-08 07:33:44 UTC
(In reply to Tamás Zolnai from comment #89)
> > - If number hierarchies are used, then the cross-reference correctly shows
> > the hierarchy (1.1, 1.2, 2.1, 2.2), but unfortunately the original figures
> > and tables are numbered consecutively (1, 2, 3, 4).
> 
> Thanks for the testing! It would be good to find out whether this kind of
> numbering is allowed in MSO Word. I had a quick look, but I can't see an
> option like that. We can't export more what MSO support. Also might be a
> good idea to create a new bug report for this issue, since it seems it's not
> about the cross-references, but the numbering field.

Agreed, this appears to be one of the cases where LO Writer has greater flexibility than MSO Word, which puts limits on what can be exported. 

I have tested the behaviour more thoroughly in MSO Word (both 2013 and 2016) and in LO Writer (current version 5.4.2.2 and in the master build). Interestingly, it appears that the hierarchy numbering partly survives the docx format, although not for long. Read on below.


MSO Word (2013 and 2016): 

When the docx file is opened, the hierarchial numbering (1.1, 1.2, 2.1, 2.2) is shown (in 2013 partly depending on whether the method of opening is double-click, or File -> Open in already running Word).

However (for both 2013 and 2016): If the file is printed, then cross-references become 1, 2, 3, 4, i.e. losing the hierarchy information, but establishing consistency in the printed file. (This is probably due to a refreshing of fields before printing.)

I have failed to find a way to "naturally" make MSO Word continue the numbering (to add another figure or table), but copy-paste allows me to add a new number, and cut-and-paste to change the order of figures and tables. In both cases, the numbering is consistently after using File -> Print (whether actually printing or not). In all cases, the distinction between figure numbering and table numbering is retained.


LO Writer 5.4.2.2: 

Figure numbers are sequential (1, 2, 3, 4) as both numbers and cross-references. New figure numbers can be inserted in standard way.

Table numbers are hierarchial (1.1, 2.1) as both numbers and cross-references, i.e. the hierarchy survived the export to docx. However, my attempts to insert a new table number results in just a blank field.


LO Writer 6.0.0.0.alpha+ master build (2017-11-06):

Both figures and table numbers are sequential (1, 2, 3, 4). For both figures and tables, a new number can be inserted in standard way.


In summary: The hierarchical numbering does not lastingly survive the docx format, even though in some of the combinations it does appear so at first. At least after field update (File -> Print in MSO Word), the numbering is consistent.

Apart from the very small issue of text formatting (see comment 88, second point), I have found no problems if a standard sequential numbering system (1, 2, 3, ...) is used.
Comment 92 Commit Notification 2017-11-09 16:23:38 UTC
Tamás Zolnai committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=cbaa72d6e963847a4b98526430cd928bc7928fdd

tdf#42346: DOC export of cross-references to objects

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 93 Lars Jødal 2017-11-11 16:38:28 UTC
*** Bug 47252 has been marked as a duplicate of this bug. ***
Comment 94 andis.lazdins 2017-11-11 17:02:59 UTC
(In reply to Commit Notification from comment #92)
>

Hi!

For me the provided solution works perfectly, both with doc and docx files. Heading number is also appearing in caption after export and in the insert caption dialogue in Word, if I'm trying to insert another caption.

I would say it's time for great celebration!
Comment 95 andis.lazdins 2017-11-11 17:04:17 UTC
(In reply to andis.lazdins from comment #94)
> (In reply to Commit Notification from comment #92)

> 
> For me the provided solution works perfectly, both with doc and docx files.
> Heading number is also appearing in caption after export and in the insert
> caption dialogue in Word, if I'm trying to insert another caption.


Ubuntu 16.04 64 bit
Comment 96 Tamás Zolnai 2017-11-12 00:56:42 UTC
> In summary: The hierarchical numbering does not lastingly survive the docx
> format, even though in some of the combinations it does appear so at first.
> At least after field update (File -> Print in MSO Word), the numbering is
> consistent.

I created a new bug for that, to make it easier to handle this separate case (bug 113776). I can reproduce this issue too. The numbering field which is used to generate numbers inside the objects' captions is not saved properly into MSO formats in this special case.
LibreOffice saves both the static text and the numbering field into MSO format, that's why the document looks good before updating the field.
Comment 97 Lars Jødal 2017-11-13 07:45:04 UTC
(In reply to Tamás Zolnai from comment #96)
> > In summary: The hierarchical numbering does not lastingly survive the docx
> > format, even though in some of the combinations it does appear so at first.
> > At least after field update (File -> Print in MSO Word), the numbering is
> > consistent.
> 
> I created a new bug for that, to make it easier to handle this separate case
> (bug 113776). I can reproduce this issue too. The numbering field which is
> used to generate numbers inside the objects' captions is not saved properly
> into MSO formats in this special case.
> LibreOffice saves both the static text and the numbering field into MSO
> format, that's why the document looks good before updating the field.

Good way to go. The new bug report narrows focus to the issues left.

If everybody can agree that the major issue is now solved and tested, why not push the patch to the upcoming version 5.4.4 rather than wait to 6.0? This is a bug fix, not a design change.

According to the release plan, https://wiki.documentfoundation.org/ReleasePlan, version 5.4.4 freezes by the end of this month (week 48) and will be published near Christmas (week 51). I am aware that version 6.0.0 is scheduled for publishing just 6 weeks later (week 5, 2018), which can be waited out. However, for people hesitant to use "fresh" rather than "still" version of LO, waiting time will be longer - and that group of users may be larger for a major version change than from e.g. 5.3 to 5.4.

Just my thoughts. In any case, thanks for the fix (even if I belong to the minority where the new bug report is still relevant)!
Comment 98 andis.lazdins 2017-11-13 08:06:43 UTC
(In reply to Lars Jødal from comment #97)

> 
> If everybody can agree that the major issue is now solved and tested, why
> not push the patch to the upcoming version 5.4.4 rather than wait to 6.0?
> This is a bug fix, not a design change.
> 
> 
> Just my thoughts. In any case, thanks for the fix (even if I belong to the
> minority where the new bug report is still relevant)!

I completely agree! I suppose the most of users are using stable versions which are recommended for production, respectively, currently 5.3.5+. Next will be most probably 5.4.5. So it would be very reasonable to put this fix into 5.4.4 so that it is ready for the stable production version.
Comment 99 Thorsten Behrens (allotropia) 2017-11-13 10:35:59 UTC
Up to Tamás - but the fix is quite large, I'd hesitate risking that for 5.4. At any rate, there'll be betas out for 6.0 soonish.
Comment 100 Tamás Zolnai 2017-11-13 11:15:20 UTC
As Thorsten mentioned it's a bigger code change, so I don't like the idea of backporting it to a stable branch.
Comment 101 V Stuart Foote 2017-11-13 15:01:32 UTC
IMHO 6.0 is soon enough as this new ww8 filter feature needs QA testing. It is not a good candidate for back port to 5.4
Comment 102 andis.lazdins 2017-11-13 15:06:18 UTC
OK, I waited for this fix since about 2000, a half of year until stable release of 6.0.x is not so much at the end :)
Comment 103 Lars Jødal 2019-04-13 10:03:04 UTC
*** Bug 106584 has been marked as a duplicate of this bug. ***
Comment 104 Lluís 2020-05-19 09:24:19 UTC
I am experiencing a similar bug on LibreOffice, but not for all references just some of them, but on this case the message I see is : "Error: Reference source not found. " . The file was created and edited primarily on Micosoft Office 365 (saved as .docx) and lately edited on LibreOffice (version and more information below. Don't know if I need to open a new bug or if it is related to this one. 

Version: 6.4.3.2
Build ID: 1:6.4.3-0ubuntu0.20.04.1
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 105 Lars Jødal 2020-05-20 07:49:33 UTC
(In reply to Lluís from comment #104)
> I am experiencing a similar bug on LibreOffice, but not for all references
> just some of them, but on this case the message I see is : "Error: Reference
> source not found. " . The file was created and edited primarily on Micosoft
> Office 365 (saved as .docx) and lately edited on LibreOffice (version and
> more information below. Don't know if I need to open a new bug or if it is
> related to this one. 

It sounds like a different issue - the present bug was about LO saving references as plain text in doc and docx formats, which was resolved when functionality was added to the doc and docx filters.

An error of the described kind, "Reference source not found", could be the result of editing if the editing involves deleting the headline/image/whatever that was referenced. If this is not the case - or if it is the case but the handling of it is undesirable - then try to narrow down when the error appears, create a simple document that demonstrates the problem, and post it as new bug. Good luck on pinning it down.