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".
Created attachment 45507 [details] Oops - disregard, patch submitted to wrong bug
@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.
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. 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
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! 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.
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"> <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>
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 back". => 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: 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
needinfo keyword redundant by needinfo status.
Bug still exist. Tested with LOdev 3.5.0beta2 Build ID: 8589e48-760cc4d-f39cf3d-1b2857e-60db978 Windows XP
@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.
Fixed in master branch (3.6)
oops, forgot to add link to the commit: http://cgit.freedesktop.org/libreoffice/core/commit/?id=5e51960dede5015b862df05b7b16f02884647889
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
(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 ;) Regards, Sébastien
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
(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
fixed in libreoffice-3-5: http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=d3294590d6c15205cc0a176e96ef04f2816079cd http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=5de902f2b66e64bc4b4755356db3b259c01ddcdd http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=cee3e301b4553095b70cf6abff15038b4aae8936
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.
@huettemann: 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 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
@huettemann@oceanwaves.de, @Jan T. to me this "not found" problem seems completely different?! <https://wiki.documentfoundation.org/BugReport_Details#How_to_reopen_Bugs>
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 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?
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 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
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.
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 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".
(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.
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: 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
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
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) https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Whiteboard#Getting_Started
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.
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?
(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.
Notes for unit test writers: Revert has to be done manually.