Bug 35669 - Incorrect cross-references to illustrations and equations in master documents
Summary: Incorrect cross-references to illustrations and equations in master documents
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.4.4 release
Hardware: x86 (IA32) All
: medium major
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: infoprovider:huettemann@oceanwaves.de...
Keywords:
Depends on:
Blocks: mab4.0
  Show dependency treegraph
 
Reported: 2011-03-25 09:11 UTC by sebastien.lever
Modified: 2014-01-30 01:14 UTC (History)
12 users (show)

See Also:


Attachments
Oops - disregard, patch submitted to wrong bug (1006 bytes, text/plain)
2011-04-12 03:01 UTC, Troy Rollo
Details
Test kit, see Comment 2 (52.78 KB, application/zip)
2011-09-12 09:26 UTC, Rainer Bielefeld Retired
Details
simple master doc with two subs containing cross references (23.88 KB, application/gzip)
2012-03-07 04:02 UTC, Jan T.
Details
Screen shot of test case (134.08 KB, image/jpeg)
2012-03-19 08:09 UTC, huettemann
Details
A tar file with a test case (395.26 KB, application/gzip)
2012-11-29 22:15 UTC, Steve Kelem
Details
Same testcase as attachment of Jan T.; created from scratch using LibreOffice master (29.50 KB, application/zip)
2013-05-01 13:55 UTC, Jorendc
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sebastien.lever 2011-03-25 09:11:12 UTC
This issue was first declared in year 2003 (see http://openoffice.org/bugzilla/show_bug.cgi?id=11174)

I steel have the problem with Illustration crossreference witch is well described above.

thanx to anyone for fixing. A 8 years old bug is the bug to kill ;) 

-------------------------original description---------------------------------
I have two writer documents, both containing some Illustrations with a
cross-reference set to the illustration's Number.
So in 
doc 1 I have "Illustration 1"
doc 2 "Illustration 1", "Illustration 2", "Illustration 3"

If I link both documents in one master document, the cross reference to an
Illustration in doc2 is not correct.
A cross refenrence to "Illustration 3" (in the context of the local document)
should point to "Illustration 4" (in the context of the master document)but
points to "Illustration 3" (which is Illustration 2 in context of the local
document).

You can find an example for this in a zip attached to issue 11172:
http://www.openoffice.org/issues/showattachment.cgi?attach_id=4554&file=GlobalDok.zip

Go to any of the directoies called "Err_frame". The Reference at page 6 schould
point to "Abbildung 4", not to "Abbildung 3".
Comment 1 Troy Rollo 2011-04-12 03:01:38 UTC
Created attachment 45507 [details]
Oops - disregard, patch submitted to wrong bug
Comment 2 Rainer Bielefeld Retired 2011-09-12 09:12:40 UTC
@huettemann@oceanwaves.de
Currently I disagree with your proposal to add this one to "most annoying Master".

Sample from <http://bugzilla-attachments-11174.openoffice.org/bugzilla/attachment.cgi?id=4648> is very buggy in LibO 3.4, order of pictures is completely messed. up.

I created a similar new testkit.zip from a.m. test kit using  "LibreOffice Portable 3.3.3  - WIN7  Home Premium (64bit) German UI [OOO330m19 (Build:301  Tag 3.3.3.1)]"  what shows

A) with  3.3.3 
Aa) Sort order of references will be messed up
Ab) References work fine
Ac) Numbering of references in Master under pictures does not look clear: 
    "Illustration 1" shown twice for 'Grrn King' and 'Rose' (for example)

B) with with "LibreOffice 3.4.3 RC2 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:302)]" 

Ba) as Aa (more or less)
Bb) as Ab (more or less)
Bc) as Ac (more or less)
Bd) Even worse: Reference Numbers missing on pages 1 for references without 
    reference names, REGRESSION comparing to LibO 3.3.3, Please do "update all"
    after open before you check! (separate bug?)

C) with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID:  d3d1481-3f8994a-2ba0a9f)]"

Seems to be all the same as "B"

Can someone please confirm my observations (at least A, B) and may be create a new test kit "from the scratch" with 3. to exclude import effects?

Then we can do further steps.
Comment 3 Rainer Bielefeld Retired 2011-09-12 09:26:04 UTC
Created attachment 51080 [details]
Test kit, see Comment 2
Comment 4 huettemann 2011-09-30 07:05:20 UTC
With LibreOffice 3.4.2 
OOO340m1 (Build:203) on Win 7 (64bit)

Illustration naming and numbering is correct.
References link work correct but order of references is mixed up.

Order is:
Illustration 5,4,3,6

should be:

Illustration 3,4,5,6

LibreOffice 3.4.3 
OOO340m1 (Build:302) on Win 7 (64bit)

Illustration naming correct but numbering is incorrect.
Illustration number is missing in references.
References link work correct but order of references is mixed up.


Hope ,that helps
Comment 5 Daniel 2011-09-30 07:05:30 UTC
Ich bin vom 04. Oktober bis 07. Oktober ausser Haus. Ich werde Ihre Nachricht nach meiner Rückkehr beantworten.

I am out of the office from 4th of October thru 7th of October. I will answer your message upon my return.

PROPRIETARY: This e-mail contains proprietary information some or all of which may be legally privileged.  It is intended for the recipient only.  If an addressing or transmission error has misdirected this e-mail, please notify the authority by replying to this e-mail.  If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail.
Comment 6 Steve Kelem 2011-11-17 12:40:13 UTC
This problem still exists in LibreOffice 3.4.4 OOO340m1 (Build:402)

What information is missing to keep the fixing of this bug from going forward?
Cross references work within a sub-document, but they get really messed up when I try to update those chapters that are part of a master document!

In my subdocument, my text references figures 47, then 48, then 47.
When included into the master document, these get damaged, and end up as figures 10.5, then 10.48, then 10.5!

When I look inside the xml for the sub-document, the references are messed up!
For example, one reference ends up like:
<text:sequence-ref text:reference-format="category-and-value" text:ref-name="refIllustration46">Illustration 1.48</text:sequence-ref></text:span>

Note that the refIllustration46 is wrong!  It's supposed to be refIllustration48!

I then re-inserted the correct references from inside L.O., ran "Tools/Update Fields", and got:
<text:sequence-ref text:reference-format="category-and-value" text:ref-name="refIllustration85">Illustration 1.47</text:sequence-ref>

It got even more messed up.  I finally edited the content.xml, correcting the refIllustration, which was now called refIllustration85, and was used to define two illustrations, 1.47 and 1.48!  I fixed both of them to use appropriate names (refIllustration47 and refIllustration48), ran Tools/Update Fields, and the names stayed the way they were supposed to.

Then I went to the master document, clicked on the chapter I had updated, selected Update Selection, then, from inside the master document, clicked Tools/Update Fields.  The sub-document file then turned on its "modified" flag. I saved the file, then looked at the xml.  Some of the references got messed up!
Here's one:
<text:sequence-ref text:reference-format="category-and-value" text:ref-name="refIllustration48">Illustration 1.49</text:sequence-ref>

One thing that's unusual, is that Illustrations 48 and 49 show up in the document in that order, but are in the other order in the content.xml.

Maybe that's messing up the Update Fields command.
Comment 7 Steve Kelem 2011-11-18 11:08:09 UTC
I'm marking this as a blocker, because I can't publish my document if the references aren't correct.
Comment 8 Steve Kelem 2011-11-18 13:27:11 UTC
I'm still trying to figure out what might be causing this problem, but I'm looking at only my document, not the LO code.

The reference that gets messed up has to do with the following figures. The odd thing is that Illustration 47 comes before Illustration 46.

<draw:frame draw:style-name="fr4" draw:name="Frame25" text:anchor-type="paragraph" svg:x="4.9799in" svg:y="2.1098in" svg:width="1.7264in" draw:z-index="61">
     <draw:text-box fo:min-height="3.7425in">
      <text:p text:style-name="Illustration"><draw:frame draw:style-name="fr32" draw:name="Fig47" text:anchor-type="paragraph" svg:y="0in" svg:width="1.0098in" svg:height="3.1799in" draw:z-index="62"><draw:image xlink:href="file:images/Fig47.png" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/>
       </draw:frame>Illustration <text:sequence text:ref-name="refIllustration47" text:name="Illustration" text:formula="ooow:Illustration+1" style:num-format="1">1.47</text:sequence>: Caption for Figure 47</text:p>
     </draw:text-box>
    </draw:frame><draw:frame draw:style-name="fr26" draw:name="Frame24" text:anchor-type="paragraph" svg:width="4.7429in" draw:z-index="95">
     <draw:text-box fo:min-height="1.5764in">
      <text:p text:style-name="Illustration"><draw:frame draw:style-name="fr30" draw:name="Fig46" text:anchor-type="paragraph" svg:x="0in" svg:y="0in" svg:width="4.7429in" style:rel-width="100%" svg:height="1.5799in" style:rel-height="scale" draw:z-index="96"><draw:image xlink:href="file:Fig46.png" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/>
       </draw:frame>Illustration <text:sequence text:ref-name="refIllustration46" text:name="Illustration" text:formula="ooow:Illustration+1" style:num-format="1">1.46</text:sequence>: Caption for Figure 46</text:p>
     </draw:text-box>
    </draw:frame>
Comment 9 Steve Kelem 2011-11-18 13:30:41 UTC
I tried switching the order around for those two figures inside the xml. The results looked the same when viewing the chapter, but messed up even worse when viewed inside the master document.
Comment 10 Petr Mladek 2011-11-21 08:24:38 UTC
Hmm, I see that many people asked for fixing the bug https://issues.apache.org/ooo/show_bug.cgi?id=11174. It had many votes, ... => I think that it is a good candidate for most annoying bugs and I am going to nominate it.

On the other hand, it is a very old bug. Nobody was able to fix it within last 8 years. There exists workarounds. They are ugly but:

1. Don't use master documents.  Cross-references within and between chapters
for Illustrations and Tables don't work.

2. Reword cross-references.  Instead of writing "See Illustration 3.14", write
"See the illustration below" or "See the second table from the bottom two pages
back".

=> it can't block the release => lovering severity
Comment 11 Björn Michaelsen 2011-12-23 11:45:32 UTC
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 12 Björn Michaelsen 2011-12-23 16:59:39 UTC
needinfo keyword redundant by needinfo status.
Comment 13 huettemann 2012-01-02 02:31:20 UTC
Bug still exist. Tested with

LOdev 3.5.0beta2 
Build ID: 8589e48-760cc4d-f39cf3d-1b2857e-60db978

Windows XP
Comment 14 Rainer Bielefeld Retired 2012-01-02 03:29:16 UTC
@Cédric:
Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
Comment 15 Cédric Bosdonnat 2012-01-26 07:09:04 UTC
Fixed in master branch (3.6)
Comment 16 Cédric Bosdonnat 2012-01-26 07:09:31 UTC
oops, forgot to add link to the commit:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=5e51960dede5015b862df05b7b16f02884647889
Comment 17 huettemann 2012-01-26 07:24:04 UTC
Great thanks for solving this issue.
Is there any chance that this will also be fixed in 5.1 ?
Release 6.0 is quite far away.

Regards


Soeren
Comment 18 Cédric Bosdonnat 2012-01-26 07:33:00 UTC
(In reply to comment #17)
> Great thanks for solving this issue.
> Is there any chance that this will also be fixed in 5.1 ?
> Release 6.0 is quite far away.

Sure. I asked for reviews for -3-5-0, 3-5 and -3-4 branches.
Comment 19 sebastien.lever 2012-01-26 07:38:52 UTC
Thanx a lot for this fix. this cause me some headache
...and welcome to Clémence ;)

Regards,

Sébastien
Comment 20 Jan Holesovsky 2012-01-31 06:35:17 UTC
The recent patches improve the situation a lot, unfortunately the original report is still not handled correctly.  Exact instructions to reproduce:

Download http://www.openoffice.org/issues/showattachment.cgi?attach_id=4554&file=GlobalDok.zip and unzip.

- ./soffice GlobalDok/Err_Frame/Draw.sxg
- confirm "Update links"
- F9 to update references
- Go to page 8, see "In dem erscheinenden Dialog (Abbildung 2) geben", which points to "Ein kleines Beispiel, der Traktor"

Expectede result

- when you look at the originating document (Draw02_Traktor.sxw), it should point to "Fangobjekt" instead
Comment 21 Cédric Bosdonnat 2012-02-08 05:13:22 UTC
(In reply to comment #20)
> The recent patches improve the situation a lot, unfortunately the original
> report is still not handled correctly.

Fixed in master by this commit:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=44f971506c0ed37928c48e55d8007f24b0c43a5f
Comment 23 nomnex 2012-02-10 22:14:19 UTC
will the fix be backported to LiO 3.3.n ? I use F-15 and it is still supported until next May 2012. Thank
Comment 24 nomnex 2012-02-10 22:14:53 UTC
will the fix be backported to LiO 3.3.n ? I use F-15 and it is still supported until next May 2012. Thanks.
Comment 25 Julien Nabet 2012-02-11 00:24:47 UTC
nomnex: There won't be backport on 3.3 since there's no more 3.3.X versions.
About 3.4, there wont be backport too because the code is quite different (see http://nabble.documentfoundation.org/REVIEW-3-5-3-4-Fix-for-fdo-35669-tp3725913p3726085.html)
Comment 26 nomnex 2012-02-11 00:48:04 UTC
Julien, thank you for the feedback.
Comment 27 huettemann 2012-02-14 07:03:41 UTC
Is it supposed to be fixed in 3.5.0 ?
I just tried the test from Rainer Bielefeld and it is still not working correct.
Pressing update two times lead to reference not found.
Comment 28 Michael Stahl 2012-02-14 07:24:12 UTC
@huettemann:
please take a look at the Whiteboard field which contains "target:3.5.1"
Comment 29 Jan T. 2012-03-07 04:02:04 UTC
Created attachment 58114 [details]
simple master doc with two subs containing cross references
Comment 30 Jan T. 2012-03-07 04:03:44 UTC
Comment on attachment 58114 [details]
simple master doc with two subs containing cross references

After reading this thread I installed LibreOffice 3.5.1.1-rc and performed a simple test with a master document and two subdocuments, which failed (the "Update all" function in the master document destroys the cross references in the subdocuments). See attached file (test cases included).
---
LibreOffice 3.5.1.1 
Build ID: 45a2874-aa8c38d-dff3b9c-def3dbd-62463c8
SLES11.1, kernel 2.6.32.12-0.7-pae
Comment 31 Rainer Bielefeld Retired 2012-03-07 04:52:35 UTC
@huettemann@oceanwaves.de, @Jan T.
to me this "not found" problem seems completely different?!
<https://wiki.documentfoundation.org/BugReport_Details#How_to_reopen_Bugs>
Comment 32 Jan T. 2012-03-14 05:14:40 UTC
ok, I give up. Today my testkit worked without the "not found" error. Don't know what I did wrong, it seemed to reproduce fine. I tried with your testkit from comment 2, and it also worked. And yes, you are right, the "not found" error is a different problem, but since the cross reference issue has been there for so long I thought it should be handled by the same bug#.
Sorry I didn't read the howto on reopening bugs (but now I did) :)
Comment 33 huettemann 2012-03-19 08:09:54 UTC
Created attachment 58688 [details]
Screen shot of test case
Comment 34 huettemann 2012-03-19 08:11:45 UTC
Sorry to say but for me with Libre Office 3.5.1.2 it is still not working.
If I load the master document test from Jan T. and say refresh links at the first prompt when opening the master document.
The illustration number is still wrong for the second document.
The same for the test kit from Rainer Bielefeld.
Am I  missing some thing?
Comment 35 nomnex 2012-11-06 01:13:50 UTC
Why has these bug marked as fixed, when obviously it is not, see: https://bugs.freedesktop.org/show_bug.cgi?id=48039 Can I get some feedback thanks.
Comment 36 Steve Kelem 2012-11-29 22:15:09 UTC
Created attachment 70805 [details]
A tar file with a test case

The attached tar file contains:
% tar tzf cross-refs.tgz 
cross-references/chap1.odt
cross-references/chap2.odt
cross-references/cross-ref-master.odm
cross-references/images/
cross-references/images/adifferentplace.jpg
cross-references/images/images.jpg
cross-references/images/imgres
cross-references/images/modern_art_paintings_21st.-.-merello.-_pietro_di_milano.jpg
cross-references/images/modern-art-mobile-mcm.jpg
cross-references/images/modern_art_mexico.jpg
cross-references/images/dream_away.jpg
Comment 37 Steve Kelem 2012-11-29 22:17:32 UTC
This bug has not been fixed. I attached a simple test case.
Now, in 3.6.3.2 (Build ID: 58f22d5), ALL the references turn into:

Error: Reference source not found

when viewed in the master document, but are correct when the chapters are viewed separately.
Comment 38 Petr Mladek 2012-11-30 13:27:26 UTC
Let's leave it only in one MAB => removing from 3.5 MABs because there is not planed any other 3.5 bugfix release.
Comment 39 nomnex 2012-12-12 02:48:30 UTC
I follow https://bugs.freedesktop.org/show_bug.cgi?id=48039 which seems to relate the same issue. Shouldn't both reports merged?

"LibreOffice 4.0 Test Marathon, running from December 14 to 19 and based in Berlin. This marathon will gather users to test a developmental version of LibreOffice 4.0 and report bugs to developers." --> Is there a way to echo this long standing bug in the AQ report of the beta. Would it help in any manner?
Comment 40 Caolán McNamara 2013-04-16 10:30:13 UTC
be nice if this could be retested with the respective branches dailies after bug 48039 is (apparently) fixed for 4-1, 4-0 and 3-6
Comment 41 Steve Kelem 2013-04-19 06:44:05 UTC
Still broken in 4.0.2.2! In my (real) document, references are fine most of the way through chapter 9. Then one of the references, instead of referring to the illustration immediately above, referred to something bogus in chapter 11!  All the following references, even in chapter 10, say "Error: Reference not found".
Comment 42 Steve Kelem 2013-04-26 21:38:40 UTC
(In reply to comment #10)
> Hmm, I see that many people asked for fixing the bug
> https://issues.apache.org/ooo/show_bug.cgi?id=11174. It had many votes, ...
> => I think that it is a good candidate for most annoying bugs and I am going
> to nominate it.
> 
> On the other hand, it is a very old bug. Nobody was able to fix it within
> last 8 years. There exists workarounds. They are ugly but:
> 
> 1. Don't use master documents.  Cross-references within and between chapters
> for Illustrations and Tables don't work.
> 
> 2. Reword cross-references.  Instead of writing "See Illustration 3.14",
> write
> "See the illustration below" or "See the second table from the bottom two
> pages
> back".
> 
> => it can't block the release => lovering severity

1. Not using master documents is a blocker. I tried this until my document grew to over 500 pages. Then the performance is horrible. OO/LO becomes unusable.
2. Rewording is ludicrous: As in, "See the illustration below, or somewhere in the surrounding pages because LO moved it. Make sure not to confuse it with the 3 other nearby illustrations which are very similar to it." Reference numbers are there for many reasons, including not having to describe which picture your text is discussing.
Comment 43 Julien Nabet 2013-05-01 11:34:54 UTC
Joren: on pc Debian x86-64 with master sources updated today, I don't reproduce the problem or perhaps missed the point. Could you give it a try?
Comment 44 Jorendc 2013-05-01 12:05:35 UTC
(In reply to comment #43)
> Joren: on pc Debian x86-64 with master sources updated today, I don't
> reproduce the problem or perhaps missed the point. Could you give it a try?

Tested using Linux Mint 14 x64 with LibreOffice Version: 4.1.0.0.alpha0+
Build ID: a514c72071a4e572bb712f78b8b119ed0b2eb6b
As far I can see I still can reproduce this behavior using Jan T.'s attachment.

What I did:

* Unpack attachment
* Open the odm file
* Update YES

Behavior: The caption of the second frame is still wrong (Illustration 1: frame-2). Should be Illustration 2: frame-2.

The last sentence in that document is: 
Now we insert a cross reference to the frame. Should be “Illustration 1” in subdoc 2 and “Illustration 2” in the master: Illustration 1.

So, still reproducible as far I can see.

Kind regards,
Joren
Comment 45 Jorendc 2013-05-01 13:55:24 UTC
Created attachment 78719 [details]
Same testcase as attachment of Jan T.; created from scratch using LibreOffice master

When I open the test document (odm) as mentioned in my previous comment and do a Tools > update > update all the numbering etc are all correct. So it looks like this bug is partially fixed. Once I save and reopen the document, it is incorrect again.

To test it has nothing to do with the version of LibreOffice which you create this document, I create a new testcase from scratch. Almost identical as the testcase Jan T. made.

Testcase created using Linux Mint 14 and LibreOffice Version: 4.1.0.0.alpha0+
Build ID: a514c72071a4e572bb712f78b8b119ed0b2eb6b
Comment 46 tommy27 2013-08-08 10:43:40 UTC
do you still see the bug with 4.0.4 and 4.1.0 final releases?
Comment 47 tommy27 2013-09-07 06:28:58 UTC
issue confirmed in 4.1.1 final (Win7 64bit)
same findings as in Comment 15

moving from mab3.6 to mab4.0 list since 3.6.x is EOL.
Comment 48 tommy27 2013-09-07 06:30:12 UTC
(In reply to comment #47)
> issue confirmed in 4.1.1 final (Win7 64bit)
> same findings as in Comment 15

typing error. I meant Comment 45
Comment 49 Robinson Tryon (qubit) 2013-10-19 00:22:05 UTC
Removing comma from whiteboard (please use a space to delimit values in this field)
https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Whiteboard#Getting_Started
Comment 50 Owen Genat (retired) 2013-11-21 23:12:54 UTC
I am providing a clarification about the attachment to comment #36, as this exhibits a different problem to the one described in this bug. In the sub-documents, outline numbering (Tools > Outline Numbering...) does not have numbering (Number tab > Number set to "1, 2, 3, ...") turned on for the Heading 1 paragraph style. This is required in order to get the leading chapter number to display in the caption i.e., the "Illustration 1.1" form of notation. 

Turning this on fixes the issue of only "Illustration 1" displaying in the caption and the cross-references. The document still exhibits a problem with this leading chapter number not incrementing as expected in the captions, when viewed from the master document. This is however NOT a cross-reference issue, but a caption / field one that requires a separate bug report.

Re-confirming results indicated by Joren and tommy27 for the attachment to comment #45 i.e., that the initial load does not appear to trigger an update. Tested under Crunchbang 11 x86_64 running v4.1.3.2. Thanks to the developers for all the work done fixing this. Great improvement.
Comment 51 Michael Stahl 2014-01-29 21:17:27 UTC
do i see it right that the only thing not fixed here
is that after initially loading a master document the fields
show the value they have in the sub-document and only
after F9 (update fields) the right values are displayed?

this is actually not special about master documents,
if you load this ordinary odt
https://bugs.freedesktop.org/attachment.cgi?id=77991
you see the first field has invalid value "Illustration 9"
which changes to "Illustration 1" only after Update Fields;
the wrong value was read from the file:

  <text:sequence-ref text:reference-format="category-and-value" text:ref-name="refIllustration0">Illustration 9</text:sequence-ref>

but usually non-master documents have the right value
already in the file.

i think this should be a separate bug from this MAB.
can we close this one?
Comment 52 Owen Genat (retired) 2014-01-30 01:14:36 UTC
(In reply to comment #51)
> do i see it right that the only thing not fixed here
> is that after initially loading a master document the fields
> show the value they have in the sub-document and only
> after F9 (update fields) the right values are displayed?

Yes, this is my understanding. I have re-tested attachment 58114 [details] and attachment 78719 [details] using v4.1.4.2 Build ID: 0a0440ccc0227ad9829de5f46be37cfb6edcf72 and pressing F9 updates the fields. Attachment 70805 [details] has a separate issue relating to outline numbering (as I describe in comment #50).

I have also tested the files available in the related Apache OO issue (old URL link above removed and new link added to See Also list). The attachments from eric.savary and bohdal in the related bug all load and display as expected (without the need for F9 refresh). The attachments from bobkeyes deal with footnote cross-references and so, again, are a separate issue not described by either this bug or the related Apache issue, both of which are concerned with illustration and equation (i.e., caption) cross-references.

> i think this should be a separate bug from this MAB.
> can we close this one?

I think we can. I am setting it to RESOLVED as FIXED, but if this is incorrect, please feel free to adjust.