I noticed that master documents created in LO3.4 have now cross-references disrupted in LO3.5.
I'm seeing this too using LO 3.5.3.2. Resolving cross-references in the master document that were set within included documents is somewhat unreliable, showing "Error: Reference source not found" for some but not all of the figure/table references (happens for me for about a dozen out of 50-60 refs total of which almost all are within the includes). Somehow by fiddling around I already got LO twice to resolve all refs correctly. However, after saving/quitting/reopening/updating the master document the same refs are dangling again.
The issue may be related to bug 35669 which was supposedly fixed, but has comments that it is still not working.
It would help a lot if you could attach a test document and steps to reproduce. If it get's broken during safe, please attach the broken document and describe how to fix it.
Created attachment 61986 [details] example files for referencing problem I have created an example master document and two documents that are included with links into the master. Each include has one table number and a reference to it. The refs are fine directly after adding the sections, they get saved correctly, and without updating the links on reopening, they are still fine. However as soon as I select "update all", both references get "Error: Reference source not found". Note, that this problem does not occurr when having only one include.
Well, this is very annoying I hope it can be fixed in a relatively short time. How can v 3.5 be a final version if a basic feature like master document doesn't work properly? Shame! Cheers, Nicola On Tuesday, 22 May 2012 at 22:11, bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=48039 > > --- Comment #4 from Wolfram Riedel <wolfram.riedel@isaco.de (mailto:wolfram.riedel@isaco.de)> 2012-05-22 14:11:11 PDT --- > Created attachment 61986 [details] > --> https://bugs.freedesktop.org/attachment.cgi?id=61986 > example files for referencing problem > > I have created an example master document and two documents that are included > with links into the master. Each include has one table number and a reference > to it. The refs are fine directly after adding the sections, they get saved > correctly, and without updating the links on reopening, they are still fine. > > However as soon as I select "update all", both references get "Error: Reference > source not found". Note, that this problem does not occurr when having only one > include. > > -- > Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug. > >
Yup, the references get broken after you update them. Thanks a for the nice test case. Michael, Cedric, could you please have a look?
Just tried it with version 3.6.0.4 (Build ID: 932b512) on linux, the bug is still there.
(In reply to comment #7) > Just tried it with version 3.6.0.4 (Build ID: 932b512) on linux, the bug is > still there. Sigh! Same here, time ago I tried with a pre-rel 3.6 on mac and bug was still there. Hope this is going to be looked after soon.
This bug is still present in 3.6.1. Does anyone know if this is going to be fixed anytime soon?
On pc Debian x86-64 with master sources updated today I reproduced this problem. Just some first research: "Error: Reference source not found" is defined by STR_GETREFFLD_REFITEMNOTFOUND in sw/source/ui/utlui/initui.src STR_GETREFFLD_REFITEMNOTFOUND is only used to declare aGetRefFld_RefItemNotFound variable here: sw/source/ui/utlui/initui.cxx This variable is only used there: void SwGetRefField::UpdateField( const SwTxtFld* pFldTxtAttr ) (sw/source/core/fields/reffld.cxx) Then reading this: 296 SwTxtNode* pTxtNd = SwGetRefFieldType::FindAnchor( 297 pDoc, sSetRefName, nSubType, nSeqNo, &nNumStart, &nNumEnd 298 ); 299 // not found? 300 if ( !pTxtNd ) 301 { 302 sTxt = ViewShell::GetShellRes()->aGetRefFld_RefItemNotFound; 303 return ; 304 } FindAnchor method is line 831 of this same file. Running gdb on all this showed me that if at the beginning nSeqNo was equal to 1, then it seems always equal to 0. Now is it normal or not? Why is it always 0?...
The cross-reference issues with master docs has plagued this application for almost a decade. The bug that has affected most of us in the staroffice/openoffice/libreoffice community over that time has been that cross references within a subdoc would scramble when the master doc is fully assembled. So a cross reference of "see Table 3-1, below, on page 22", would be scrambled into "see Table 2-3, above, on page 11", or something similar. It rendered cross references useless in projects using master docs. The biggest bummer is that Libreoffice seems now to have broken what has been a usable workaround for this issue for the past 9 years; the workaround being to create a custom counter variable name for each subdoc. This has been easy to do simply by manually typing a cross-reference category name directly into the category field of the caption dialog box. So instead of simply choosing "Table" from the drop-down, you type "fooTable" directly into the dialog. This automatically creates a counter variable called "fooTable" and a paragraph style called "fooTable". The created caption then says "fooTable 1-1: my text here". Then, you could just delete the "foo" from the caption text, leaving a caption of "Table 1-1: my text here". Later a cross reference to this caption could be inserted elsewhere in the same subdoc selecting "fooTable 1-1" in the cross-reference dialog. If you were cross-referencing "category and number", prior versions of Libreoffice and openoffice would correctly insert "Table 1-1" into the doc. With version 3.6.3.2, however, there seems to be a check that the "category" part of the caption text matches the name of the counter variable, and if not, then the category part of the caption is omitted from the cross-reference. So in my example where I used "fooTable" as the counter variable and then just deleted "foo" from the caption, I find that I am unable to insert a proper cross reference that includes the category. Trying to do so inserts only the number part of the cross reference, i.e. "1-1". Please fix cross references in master docs, and please, please, please, undo the change that broke this longstanding workaround. Regards, Joe
The problem I encounter using this workaround is the master document does not number the table or figure captions incementaly anymore (eg. from 1 to 500). The number range variables restart (from 1) in each sub-document. How about you rename the captions accordingly eg. "Ch1-Figure1:" to avoid renaming them in LO 3.6.3.2?
I think this bug should be included in "most annoying.." bugtracker since there's information lost...
(In reply to comment #13) > I think this bug should be included in "most annoying.." bugtracker since > there's information lost... Oops, I did't realize that it was already included in 3.5.
(In reply to comment #12) > The problem I encounter using this workaround is the master document does > not number the table or figure captions incementaly anymore (eg. from 1 to > 500). The number range variables restart (from 1) in each sub-document. > Hi nomnex, yes, the number ranges start over in each subdoc, as is to be expected, since they each use their own counter variable; the numbers are subdoc specific. This is fine for me, however, because the document template design I've been using for a decade uses per-chapter numbering anyway, i.e. Figure 2-5 for the fifth figure in chapter 2. So the workaround I described worked perfectly....until recently when LO broke it. > How about you rename the captions accordingly eg. "Ch1-Figure1:" to avoid > renaming them in LO 3.6.3.2? I don't understand what you're getting at here... Joe
(In reply to comment #15) > design I've been using for a decade uses per-chapter numbering anyway, i.e. > Figure 2-5 for the fifth figure in chapter 2. I did a quick try with heading numbered and numbrering caption by chapter. The chapter caption (figure 2-5: dummy image) is lost when I import the sub-doc in the master (figure 5: dummy image). It's an issue when I create an index of figures. Out of cursiosity, can I see your document for my reference? > > How about you rename the captions accordingly eg. "Ch1-Figure1:" to avoid > > renaming them in LO 3.6.3.2? > > I don't understand what you're getting at here... FWIW, I was simply suggesting to name the "custom number range variable", in each sub-document, in a manner that you don't need to search for and replace them in the master. (e.g. sub1Figure, sub2Figure, etc.).
(In reply to comment #16) > I did a quick try with heading numbered and numbrering caption by chapter. > The chapter caption (figure 2-5: dummy image) is lost when I import the > sub-doc in the master (figure 5: dummy image). Sry., that was my first try... I did not know I also had to "Number by chapter" in the master. Woraround works great (up to LO 3.6.3.2), as per Joe comment. Thanks.
Hello nomnex, I just tried version LibO 3.6.4 and the regression is there as well. Now that you've reproduced the issue and seen how the longstanding workaround has been broken, can you give us any idea when this regression will be fixed? I'm in the middle of a big 1000-page "master doc" project, and the timing of this regression could not be worse for me personally... Joe
I really want to support the request below. At least let us know ASAP when and if you are going to fix this. Thanks On Thursday, 20 December 2012 at 19:19, bugzilla-daemon@freedesktop.org wrote: > > Comment # 18 (https://bugs.freedesktop.org/show_bug.cgi?id=48039#c18) on bug 48039 (https://bugs.freedesktop.org/show_bug.cgi?id=48039) from Joseph Ervin (mailto:joseph.ervin@oracle.com) > Hello nomnex, I just tried version LibO 3.6.4 and the regression is there as well. Now that you've reproduced the issue and seen how the longstanding workaround has been broken, can you give us any idea when this regression will be fixed? I'm in the middle of a big 1000-page "master doc" project, and the timing of this regression could not be worse for me personally... Joe > > > You are receiving this mail because: > You reported the bug. > > >
(In reply to comment #18) > Hello nomnex, > > I just tried version LibO 3.6.4 and the regression is there as well. > > Now that you've reproduced the issue and seen how the longstanding > workaround has been broken, can you give us any idea when this regression > will be fixed? > > I'm in the middle of a big 1000-page "master doc" project, and the timing of > this regression could not be worse for me personally... > > Joe I Don't know if I will be of any help but, this bug is affecting me also, although with a manuscript of ~250 pgs. What I'm doing right now is working with every subfile as always, but instead of a master I'm inserting those files in a new one, using "Insert -> File" option. Regards, Francisco.
Hi - is there any news about this bug? Has it been forgotten? Thanks - nayk
I am moving this to 3.6 MAB as 3.5 is at end of life and therefore we're closing this meta tracker. @everyone - I will try to raise awareness to someone who might be able to fix this one. Thanks for your patience, apologies it's been so long
Can u provide a link we can all check in order to see progresses on this bug? Thanks
(In reply to comment #23) > Can u provide a link we can all check in order to see progresses on this bug? You are at the right place. I made a comment yesterday on the mba3.5 thread #37361, to call for attention, because this bug is assigned to nobody. Thanks to Joel, we have some feedback. As long this bug is assigned to no one, don't expect any change. --nomnex
In 4.0.1 on XUbuntu Quantal, a 250 p document as a master doc with each subdoc as a chapter or appendix. I too have been maintaining these books in this way for many years in OOO and now LO. 3.6x was broken as described in this bug report - "error reference not found" 4.0.1 seems to be working for caption contents, but figure numbering is broken. Tables work correctly - each table caption is numbered "<chapter number>-<table number starting at 1 for each chapter>" Figures however, are always "1-<figure number starting at 1 for each chapter>" Should that be a separate bug report?
(In reply to comment #25) > In 4.0.1 on XUbuntu Quantal, a 250 p document as a master doc with each > subdoc as a chapter or appendix. I too have been maintaining these books in > this way for many years in OOO and now LO. > > 3.6x was broken as described in this bug report - "error reference not found" > > 4.0.1 seems to be working for caption contents, but figure numbering is > broken. > Tables work correctly - each table caption is numbered "<chapter > number>-<table number starting at 1 for each chapter>" > Figures however, are always "1-<figure number starting at 1 for each > chapter>" > > Should that be a separate bug report? Belay that. "error reference not found" is back in 4.0.1. Its possible that deleting and re-creating the figure captions in the subdocs fixes it. Tables work fine.
(In reply to comment #26) > (In reply to comment #25) > > Belay that. "error reference not found" is back in 4.0.1. Its possible that > deleting and re-creating the figure captions in the subdocs fixes it. Tables > work fine. I am getting both types of bug: failure to cross-reference figure captions correctly in the masterdoc " error reference not found" and failure to number figure captions by chapter number in the master doc. I did not completely test a brand new document - I am using old documents originally created years ago. and The results are quite erratic. Some subdocs work some don't. A recreated subdoc didn't work.
this should be bibisectable with bibisect-3.6
source-hash-ce97851773a06103504972eb2771eecd7dd81e36 # bad: [aa062d7ec36c69c1aff1abf994a90c5f0987c5be] source-hash-d50f02bec4a70bd26a518e4e76f4a876454ab937 # good: [bba31ba417672c6f185a6875c813677e8ac44c86] source-hash-9a8d7e2a3f41f9e1c39c5634714a3a2b21776670 git bisect start 'latest' 'oldest' # bad: [631e1335e3a9629152a2a4cb0f99304248299eb0] source-hash-bd6310886dc4351a8ac3ed3ee9a4f65d2a0e005c git bisect bad 631e1335e3a9629152a2a4cb0f99304248299eb0 # bad: [078f3ebbba087e4ff9aa6ef26b9a4b0128850261] source-hash-8b55ef8898a39803e9c4a8cd6a271576389c0249 git bisect bad 078f3ebbba087e4ff9aa6ef26b9a4b0128850261 # bad: [3fe6f9e4a5d75e2a6f05f1fba212c33db30257d2] source-hash-4ff7252375b7b85eafbf176ca4e9184cc392d980 git bisect bad 3fe6f9e4a5d75e2a6f05f1fba212c33db30257d2 # good: [731fe8f30eae43e902b129fd1d9356e1ea665744] source-hash-43c7830b03d141ae11d8617c0fdabefa32dd243c git bisect good 731fe8f30eae43e902b129fd1d9356e1ea665744 # bad: [4541b3234381241e171dcf6e34e638df0316237a] source-hash-a330f38093e2643a26239557050561afae9ff23d git bisect bad 4541b3234381241e171dcf6e34e638df0316237a # bad: [01679256aaddef65a77fccc945aa9ec06197640d] source-hash-ce97851773a06103504972eb2771eecd7dd81e36 git bisect bad 01679256aaddef65a77fccc945aa9ec06197640d
when modifying the sequence numbers of the subdocuments in order to disambiguate the fields we're using two slightly different algorithms for the get and set fields. The updated set fields are renumbered from the largest master document id + 1 onwards, while the updated get fields are renumbered with the lowest number that isn't already a master sequence number
I'll take this on the strict understanding that I'm fixing the (very good) provided test-case example of comment #4. If #4 is fixed after this but something else still doesn't work, then a new bug is indicated, rather than reopening this one. Though of course if the comment #4 attachment still fails, then feel free to reopen.
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=74d942fb2396a268adfcc915e75b8b32fae851dc Resolves: fdo#48039 use same algorithm for assigning get/set replacement ids 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.
fixed on master, gerrit reviews for 3-6 and 4-0 pending
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1b1fe71be534fb05a11f741375e47f552e7a8914&h=libreoffice-3-6 Resolves: fdo#48039 use same algorithm for assigning get/set replacement ids It will be available in LibreOffice 3.6.7. 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.
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9f3fad8804bfcd03e514d0c725c6380a16fb8f5a&h=libreoffice-4-0 Resolves: fdo#48039 use same algorithm for assigning get/set replacement ids It will be available in LibreOffice 4.0.3. 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.
Just tested 4.0.3 and it seems that this bug has been solved. Very many thanks!
(In reply to comment #36) > Just tested 4.0.3 and it seems that this bug has been solved. Very many > thanks! It looks likes it's not? see: https://bugs.freedesktop.org/show_bug.cgi?id=35669#c45