Note that the hyperlink remains active, but the text of the cross-reference disappears.

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

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

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".

Thanks for attachment.
Please, attach doc file with working reference, produced by Word.
(for developers can see how it should be inside of doc)

Created attachment 62099 [details]
LibreOffice cross-reference breaks when exporting to Word 2000

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.

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

Created attachment 62229 [details]
first attachment, edited by msWord 2007 and saved as docx

Created attachment 62230 [details]
first attachment, edited by msWord 2007 and saved as doc

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.

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).

I can also confirm that this bug is a showstopper for me.
Having to ditch LibreOffice and go back to Word. Shame.

*** Bug 62216 has been marked as a duplicate of this bug. ***

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

Forgot to state OS: Windows XP and Windows 7

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)

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.

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".

Bug still exists in 4.3 branch.
Please see: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=84637

*** Bug 84637 has been marked as a duplicate of this bug. ***

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.

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

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

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.

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.

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”.

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.

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.

(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.

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.

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.

(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...

(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.

(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!

(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.

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.

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.

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.

Created attachment 117785 [details]
Odt file with "Figure caption"

Created attachment 117786 [details]
Corresponding docx file with captions working.

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.

Created attachment 117787 [details]
Corresponding doc file exported using Libreoffice 5.0.0.5

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.

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.

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?

Just tried with 5.1.0.0.beta1-buildfix1. The same result - cross-references transforms into plain text or disappears.

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.

(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.

(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.

@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

(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 ;) )

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

(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

*** Bug 96117 has been marked as a duplicate of this bug. ***

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

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

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.

(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

Looking at the history - there's zero reason why this should be critical. Changing back to Normal

Normal: Can prevent high quality work

(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

(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.

(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.

*** Bug 99398 has been marked as a duplicate of this bug. ***

Hope that another bug report will provide more motivation to solve this terrible issue.

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.

(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 ;-)

(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

*** Bug 99624 has been marked as a duplicate of this bug. ***

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

*** Bug 100671 has been marked as a duplicate of this bug. ***

"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.

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.

(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.

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.

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.

(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.

(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.

(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.

(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

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.

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.

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.

(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!!!

Created attachment 137569 [details]
ODT sample file with number hierachy (1.1, 1.2, ... 2.1, 2.2, ...)

(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).

> - 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.

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.

(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.

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.

*** Bug 47252 has been marked as a duplicate of this bug. ***

(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!

(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

> 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.

(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)!

(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.

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.

As Thorsten mentioned it's a bigger code change, so I don't like the idea of backporting it to a stable branch.

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

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 :)

*** Bug 106584 has been marked as a duplicate of this bug. ***

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

(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.