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 ;)
I have two writer documents, both containing some Illustrations with a
cross-reference set to the illustration's Number.
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
You can find an example for this in a zip attached to issue 11172:
Go to any of the directoies called "Err_frame". The Reference at page 6 schould
point to "Abbildung 4", not to "Abbildung 3".
Created attachment 45507 [details]
Oops - disregard, patch submitted to wrong bug
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 18.104.22.168)]" 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.
Created attachment 51080 [details]
Test kit, see Comment 2
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.
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
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.
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!
<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.
I'm marking this as a blocker, because I can't publish my document if the references aren't correct.
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">
<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:frame><draw:frame draw:style-name="fr26" draw:name="Frame24" text:anchor-type="paragraph" svg:width="4.7429in" draw:z-index="95">
<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>
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.
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
=> it can't block the release => lovering severity
[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:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
needinfo keyword redundant by needinfo status.
Bug still exist. Tested with
Build ID: 8589e48-760cc4d-f39cf3d-1b2857e-60db978
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.
Fixed in master branch (3.6)
oops, forgot to add link to the commit:
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.
(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.
Thanx a lot for this fix. this cause me some headache
...and welcome to Clémence ;)
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"
- when you look at the originating document (Draw02_Traktor.sxw), it should point to "Fangobjekt" instead
(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:
fixed in libreoffice-3-5:
will the fix be backported to LiO 3.3.n ? I use F-15 and it is still supported until next May 2012. Thank
will the fix be backported to LiO 3.3.n ? I use F-15 and it is still supported until next May 2012. Thanks.
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)
Julien, thank you for the feedback.
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.
please take a look at the Whiteboard field which contains "target:3.5.1"
Created attachment 58114 [details]
simple master doc with two subs containing cross references
Comment on attachment 58114 [details]
simple master doc with two subs containing cross references
After reading this thread I installed LibreOffice 22.214.171.124-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).
Build ID: 45a2874-aa8c38d-dff3b9c-def3dbd-62463c8
SLES11.1, kernel 126.96.36.199-0.7-pae
@firstname.lastname@example.org, @Jan T.
to me this "not found" problem seems completely different?!
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) :)
Created attachment 58688 [details]
Screen shot of test case
Sorry to say but for me with Libre Office 188.8.131.52 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?
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.
Created attachment 70805 [details]
A tar file with a test case
The attached tar file contains:
% tar tzf cross-refs.tgz
This bug has not been fixed. I attached a simple test case.
Now, in 184.108.40.206 (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.
Let's leave it only in one MAB => removing from 3.5 MABs because there is not planed any other 3.5 bugfix release.
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?
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
Still broken in 220.127.116.11! 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".
(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",
> "See the illustration below" or "See the second table from the bottom two
> => 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.
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?
(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: 18.104.22.168.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.
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: 22.214.171.124.alpha0+
Build ID: a514c72071a4e572bb712f78b8b119ed0b2eb6b
do you still see the bug with 4.0.4 and 4.1.0 final releases?
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.
(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
Removing comma from whiteboard (please use a space to delimit values in this field)
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 v126.96.36.199. Thanks to the developers for all the work done fixing this. Great improvement.
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
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?
(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 v188.8.131.52 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.