Creating an alphabetical index with an existing or newly created concordance file does not work for normal text. The index only gets filled when having the search text inside a frame (when using caption) Steps to reproduce: 1. Open a new document and type test followed by an enter 2. Insert Indexes and Tables 3. Select type: Alphabetical Index 4. keep for entire document 5. mark Concordance file and select NEW 6. save the file 7. In search term enter: Test 8. In Alternative entry enter: Test 9. Match case and Word only leave both to no 10. Confirm all opening windows by OK Current behavior: nothing appears in Index Expected behavior: Entry Test should appear in Index If you add now a graphic (use for example Gallery) and right click this graphic to add a caption. In the Caption-Field write: Test and confirm by clicking OK Go back to the created Index and refresh/update it. Now the entry appears in the alphabetical Index. Platform (if different from the browser): Browser: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Today I tested the same with the new version of libreOffice Writer 3.5.1.2. Same effect. Can anybody confirm this behavior?
The attempt to insert an alphabetical index using a concordance file doesn't succeed (LibreOffice 3.5.1.2 and earlier in 3.5.0 rc3). The index entries are not marked in the main text and the resulting index consists only of a headline. This is reproductable running different Win-OS like XP (32Bit SP3), Vista (Home Premium 32/64Bit SP2) and Win 7 (Home Premium 64 Bit SP1). Indexing a text directly (without c-file) seems to work. Affected are also the portable version LO 3.5.0. The index by concordance file in LO 3.4.5. works fine. As a workaround I propose downgrading to 3.4.5. until the issue is resolved...
There is a thread about that issue in the users@global.libreoffice.org mailing list archive (http://nabble.documentfoundation.org/Users-td3833634.html)
Tested with LO-3.5.2.2 - still the same behavior
Updating to LO 3.5.3.2 - Alphabetical index still doesn't work! (Win 7 Home Premium 64Bit SP1)
Not working on linux (gentoo-3.5.3.2)
Thanks for bugreport Please attach odt file that demonstrates this problem and corresponding concordance file (for testing purposes)
Created attachment 62009 [details] Testfile with alphabetical index
Created attachment 62010 [details] concordance file for test.odt
as per request, please find the two attached files (test.odt and test.sdi). Thank you for investigating this problem.
Thanks for attachments. For experiment I removed Alphabetical Index from document and generated again, unchecked "Combine identical items". result: 3.3.4 : 14 items 3.5.3 : 4 items So, we see regression after 3.3.4 reproduced on Fedora 64 bit IMHO: in 3.5.3 into Alphabetical Index placed items only from frames and each 2 times
Still a problem in 3.5.4.2 - same behaviour, indexes captions to graphics but not identical items the the main body of the text. If I cut and paste the text from the document and put it into a text frame, the listed words get indexed
According the Releasenotes for Version 3.6.1.2 (Build ID: e29a214) this problem is not listed as solved. Also a test with the LO-3.6.1.2 underlines still this behaviour. Just out of curiosity - when can we expect a fix for it? Sorry to get impatient but I've to write a dissertation and would be happy to use this function again. Thank you.
> when can we expect a fix for it? I hope that in this year. But I am afraid that even in next year this bug will not fixed.
This is reproducible with: Mint 12 x64 LibreOffice 3.5.4.2
*** Bug 52324 has been marked as a duplicate of this bug. ***
*** Bug 52400 has been marked as a duplicate of this bug. ***
Comment on attachment 62010 [details] concordance file for test.odt (Fixed MIME type.)
Comment on attachment 62010 [details] concordance file for test.odt (Sorry, this was the wrong attachment. Reverted. Everybody does something stupid from time to time ;-)
It is very interesting that in this OpenOffice.org 3.3.0 there is no problem.
Same here, regarding the procedure in the original report. I also notice that in a 77-page Writer document, LibreOffice is inconsistent about whether it will add all occurrences of any given word into the Alphabetical Index. Platform: Linux LibreOffice Version: 3.6.4.3. I also notice that the concordance file gets saved with no 3-letter extension at the end, but is instead saved with only a period at the end of the filename. It looks like perhaps an extension of "sdi" was intended by developers.
I can confirm that on LO 3.6.5.2 running on Fedora 18 the problem still exists. Text on the page is not indexed according to the concordance file but text in a frame does get indexed. As mentioned before, this is a regression as this used to work. Unfortunately I am not sure which version it last worked in. I can confirm that the same concordance file, used for my test, works fine, when used with exactly the same text, in OpenOffice 3.4.1 If the file is opened in LO, having been saved in OO then the index displays correctly. If the concordance file is edited and the index is updated, nothing happens. Save the file, open it in OO and update the index - the change is correctly displayed.
Confirmed on 3.6.5 OpenSuse 64bit, 4.0.0.0.beta1 on Win7 this is annoying, as we do not have any 3.4.X installs available at the moment and we have to update some manuals written in 2010... Sure hope, somebody can find a fix for this.
Hello Still Reproduced with windows 7 64bits & Version 4.0.2.1 (Build ID: 7e5467ff8f30d821f4fbf69cb2769163eb64c2c) Regards Pierre-Yves
I can confirm still present in 4.0.2 (OpenSuse version)
01679256aaddef65a77fccc945aa9ec06197640d is the first bad commit commit 01679256aaddef65a77fccc945aa9ec06197640d Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Wed Apr 25 07:28:24 2012 +0200 source-hash-ce97851773a06103504972eb2771eecd7dd81e36 commit ce97851773a06103504972eb2771eecd7dd81e36 Author: David Tardon <dtardon@redhat.com> AuthorDate: Mon Feb 6 19:12:02 2012 +0100 Commit: David Tardon <dtardon@redhat.com> CommitDate: Mon Feb 6 19:12:02 2012 +0100 fix typo :100644 100644 e1c1d62aa980fee004430f920cdbe3fd1ce79bf0 9acf11b8f6f5e26b03649767813ac42f72c38e1b M autogen.log :100644 100644 c14237a7b6ebde67a83585c9b057c78710e08ea2 db4232175b715b6c7f322b17041f56a9145e1622 M ccache.log :100644 100644 c407d12366338584cbcebf2197cd7fcdcf1c522b 1b83a94159f8aa22e004b5dc2ebe1895b32a2724 M commitmsg :100644 100644 3be616510b5296b5ae2f5c154a6c51f7ba49bf24 cc9f341a09ba536bb41d4219c5b7f5dd219d7cc6 M dev-install.log :100644 100644 637e789a93608b99c13fec9e598c2e7a4c454c6d 08ab33c46c34b7b9b0f8b7f21161ad1c1a2ed59a M make.log :040000 040000 c47ba9e6977c3c8a957b11ec3f8b85cfa50362af f87831ea583aaccb888e681ce264cc1e4e44d3aa M opt git bisect log # 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
Per Comment 26 this is already bisected. Thanks for that!
This regression seems to be a sideeffect of: commit 41cd78b805a36d5676b2075a4860e9aee7bc5491 Author: Cédric Bosdonnat <cedric.bosdonnat.ooo@free.fr> Date: Fri Jan 6 10:01:22 2012 +0100 fdo#32726: search for index entries in the whole document, not only the body as reverting that commit seems to fix the issue, thus CC'ing Cedric.
*** Bug 67100 has been marked as a duplicate of this bug. ***
I get this same bug in 4.0.3 and 4.0.4. As I said in the duplicate report bug 46410: "Adding an Alphabetical Index set to index an entire document only indexes the footnotes of the document. "Also, I'm using the Zotero citation plugin to insert citations, so that might affect things, although I tried it in another document without any Zotero citations, and still had the same problem."
according to previous comment I move this report from mab3.6 list to mab4.0 list. 3.6.x is EOL and bug still affects. 4.0.x
Removing comma from whiteboard (please use a space to delimit values in this field) https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Whiteboard#Getting_Started
Is there any fix or workaround for this by now?
hello (In reply to comment #33) > Is there any fix or workaround for this by now? Still occurs on windows 7 64bits with: Version: 4.1.3.1 Build ID: b42498da0e3f91b17e51b55c8295ec4f8f22087 and Version: 4.2.0.0.alpha0+ Build ID: cc2a405915e82c4b332dd25457f76704dc536d7f TinderBox: Win-x86@39, Branch:master, Time: 2013-10-15_15:51:52 Regards Pierre-Yves
(In reply to comment #28) > This regression seems to be a sideeffect of: > > commit 41cd78b805a36d5676b2075a4860e9aee7bc5491 > Author: Cédric Bosdonnat <cedric.bosdonnat.ooo@free.fr> > Date: Fri Jan 6 10:01:22 2012 +0100 > > fdo#32726: search for index entries in the whole document, not only the > body > > as reverting that commit seems to fix the issue, thus CC'ing Cedric. That fix is wrong. If I want to search everywhere, I have to use FND_IN_SELALL, not FND_IN_SELALL|FND_IN_BODY|FND_IN_OTHER, which is by the way invalid, if we take source code comments seriously in sw/inc/cshtyp.hxx.
Andras Timar committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d3ffdf5e7db40ab026a4d55bfe231ab5817c4142 fdo#46410 fix FindRange 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.
Andras Timar committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4edc3c0500acba23518ddc7c35f7aa81739b6b9b&h=libreoffice-4-1 fdo#46410 fix FindRange It will be available in LibreOffice 4.1.4. 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.
Hello (In reply to comment #37) > Andras Timar committed a patch related to this issue. > > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=4edc3c0500acba23518ddc7c35f7aa81739b6b9b&h=libreoffice-4-1 >... > Affected users are encouraged to test the fix and report feedback. WORKSFORME with windows 7/64 & Version: 4.2.0.0.alpha1+ Build ID: 6788b92e15889beb151baf2b8ca8719f6ea38481 TinderBox: Win-x86@39, Branch:master, Time: 2013-11-21_02:40:15 Thank you :) Regards Pierre-Yves
*** Bug 71606 has been marked as a duplicate of this bug. ***
*** Bug 72111 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]