Created attachment 57974 [details] Screenshot of bug. Problem description: If I insert bibliography entry in to Frame then bibliography entry number becomes zero. Steps to reproduce: - strat new Writer document; - insert Frame (insert -> frame... -> ok); - place carret in to frame; - insert bibliography entry (inser -> indexes and tables... -> bibliography entry... -> choose one entry from database -> insert -> close); - place carret otside frame; - inser bibliography table (insert -> indexes and tables... -> indexes and tables -> select "type" = "bibliography" and check "number entries" -> ok); Current behavior: after mentioned steps number of bibliograhy entry becomes "0" (see screenshot). This bug also persist in v3.4. Expected behavior: numbering must be correct. Platform (if different from the browser): Browser: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
In LO 3.5.1 this problem happens only if there is no other paragraph. Steps to reproduce: - strat new Writer document; - insert Frame (insert -> frame... -> ok); - place carret in to frame; - insert bibliography entry (inser -> indexes and tables... -> bibliography entry... -> choose one entry from database -> insert -> close); - place carret otside frame; - inser bibliography table (insert -> indexes and tables... -> indexes and tables -> select "type" = "bibliography" and check "number entries" -> ok); - Entry becomes "0" - I enter a new paragraph (Test: "Test foo bar") - Press F9 - Entry becomes 1
Created attachment 58749 [details] wrong number without paragraph / right with another
Confirmed with: LO 3.5.5.3 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit Confirmed original and comment 1 description.
reproduced in 3.6.4 on RFR 17 64 bit (use "Number entries" on first tab of dialog "Insert index/table")
Confirmed as still a bug in version 4.1.3.2 release 64 bit.
Thanks for additional testing Sorry, but "version" is version where bug initially found. Not a current version of LO. If bug disappears we just closing the bug. Changing back to 3.5.0
Sorry. Thanks for correcting and informing me Sasha. To point out the importance of fixing this bug; note that putting a reference in a figure caption causes the problem. This makes the bibliography system unusable for any scientific writing.
Can reproduce in Version: 4.1.3.2 I agree with celt: This makes the bibliography system unusable for any scientific writing.
*** Bug 74093 has been marked as a duplicate of this bug. ***
*** Bug 73664 has been marked as a duplicate of this bug. ***
Related Apache OO issue added to See Also list. Summary edited for clarity.
A workaround for this problem is to insert an invisible copy of this bibliography entry befor the frame. Then the numbering works. It is not the best solution but it works
For me it works, I use version 4.1 and 4.3(Build ID: 160db96a882a2be8c3307e8a04beda4ae93a13c4) on Windows 7. I always get the "Short name" as defined, with the external data base "Bibliography" and with document internal bibliography entries too. Perhaps you did it different. Can you describe in detail, how you insert the bibliography entry? I do it this way, for example: 1. Set cursor into caption paragraph inside the picture frame. 2. Insert > Indexes and Tables > Bibliography entry 3. Option "from bibliography database". 4. Select "GAS00" from "Short name" drop-down list. 5. Click "Insert" 6. Click "Close" Or with internal bibliography entries. 1. Set cursor into caption paragraph inside the picture frame. 2. Insert > Indexes and Tables > Bibliography entry 3. Option "from document content". 4. Click "New". 5. Fill the record fields, do not forget the field "Short name". OK. 6. Select the item from the "Short name" drop-down list. 7. Click "Insert" 8. Click "Close" With the checkbox "Number entries" in the bibliography index dialog you switch between using numbers and "Short name". That works for and back and there are no zeros.
Removing from MAB list as no contributor has verified that this belongs there. Putting it on multiple lists is against policy - also there are procedures for how a bug makes it to the list and this one has not gone through them. If anyone is interested in joining QA you can join the mailing list or jump into the IRC room here http://webchat.freenode.net/?channels=libreoffice-qa and we'll help you become familiar with the policies. MAB list is supposed to be a way to organize and prioritize, in order to do this we have to stick to these procedures else the list will become unmanageable. Thanks for understanding
Created attachment 92907 [details] ODT and screenshot showing problem. (In reply to comment #13) > For me it works, I use version 4.1 and 4.3(Build ID: > 160db96a882a2be8c3307e8a04beda4ae93a13c4) on Windows 7. > > I always get the "Short name" as defined, with the external data base > "Bibliography" and with document internal bibliography entries too. Perhaps > you did it different. Can you describe in detail, how you insert the > bibliography entry? Regina, I have attached an example and included a screenshot for clarity. Given I am using the default bibliography database provided with v4.1.4.2 Build ID: 0a0440ccc0227ad9829de5f46be37cfb6edcf72 I hope it works for others. The problem does not appear under the index is inserted. Here is how I created the attached: 1. Start Writer (empty document). 2. Insert > Frame > enlarge frame width a bit > click OK. 3. Place cursor in the frame. 4. Insert > Indexes and Tables > Bibliography entry. 5. Use default entries > click Insert > click OK ("[ARJ00]" is inserted). 6. Press ENTER. 7. Type "Text". 8. Press ENTER. 9. Insert > Indexes and Tables > Bibliography entry. 10. Select short name entry "AVV00" > click Insert > click OK ("[AVV00]" is inserted). 11. Press ENTER. 12. Insert > Picture > From file > browse to raster graphic > click OK. 13. Right-click on inserted raster graphic > Caption. 14. Type "TDF logo." > click OK. 15. Place cursor at caption line end > type SPACE 16. Insert > Indexes and Tables > Bibliography entry. 17. Select short name entry "DUD00" > click Insert > click OK ("[DUD00]" is inserted). 18. Place cursor on the first paragraph. 19. Insert > Indexes and Tables > Indexes and Tables. 20. Index/Table tab > select type of "Bibliography" > Formatting of the entries section > check "Number entries" option > click OK. Observed behaviour: The first [ARJ00] and third [DUD00] citations (the two that are in frames) are converted to "[0]". Corresponding bibliography index entries are also set to "0". Expected behaviour: All citations number in sequence (e.g., "[1]", "[2]", "[3]"), along with matching identifier in the bibliography index.
(In reply to comment #15) > The problem does not appear under the index ... The problem does not appear UNTIL the index ...
In some circumstances creating a new paragraph outside of the frame fixes the numbering. However I have some existing documents where this is not the case. So far I have not been able to find the steps to reproduce the "unfixable" version of the bug. Can anyone else provide insight on this, or suggest anything I can try with these files?
Adding self to CC if not already on
Bug is still present in Version: 5.0.3.2 I can reproduce the bug every time I have a source entry that's only used inside an image caption. If you insert the bibliography entry the index gets [0]. Adding the same entry within the normal text indexes it correctly. The previously inserted entry inside the caption still remains [0]. Deleting this entry and inserting it again shows the correct index (The entry also changes the index if you don't delete it and insert the same entry behind it). This index also stay correct if you delete the entry in the normal text (sometimes!!). It also changes if you add or delete entries before the image. It's quite mysterious. I already had pictures where the entry stayed correct after the deleting the entry in the text but now I have one that changes back to [0] if you update all things within the document. Thought you might have to save before updating but it didn't have any effect.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170901
The latest version I currently have is Version: 5.4.0.3 Build ID: 5.4.0-2 CPU threads: 4; OS: Linux 4.12; UI render: default; VCL: gtk3; Locale: de-DE (de_DE.UTF-8); Calc: group I can still reproduce the issue in the same manner. As long as the entry also exists outside the frame the numbering gets updated correctly. But if the entry is only within the frame the numbering is [0]
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to QA Administrators from comment #22) Bug still persists. Version: 5.4.6.2 Build ID: 1:5.4.6-0ubuntu0.17.10.1 CPU threads: 16; OS: Linux 4.13; UI render: default; VCL: kde4; Locale: lt-LT (lt_LT.UTF-8); Calc: group
Also confirmed with the following: Version: 6.0.3.2 Build ID: 1:6.0.3-0ubuntu1 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-AU (en_GB.UTF-8); Calc: group But for some reason, the numbering started at 1 if I had text before the reference and the bibliography. Steps updated for 6.0: - create new Writer document; - insert Frame (insert -> frame -> frame... -> ok); - place cursor inside the frame; - insert bibliography entry (insert -> Table of Contents and Index -> bibliography entry... -> choose one entry from database -> insert -> close); - place cursor outside of the frame; - insert bibliography table (insert -> Table of Contents and Index -> Table of Contents, Index or Bibliography -> select "type" = "bibliography" and check "number entries" -> ok);
Bug still reproducable with the original steps in Version: 6.1.0.3 Build ID: 6.1.0-2 CPU threads: 12; OS: Linux 4.18; UI render: default; VCL: gtk2; Locale: de-DE (en_US.UTF-8); Calc: CL
This was fixed in https://cgit.freedesktop.org/libreoffice/core/commit/?id=417d993b8b8a86c019758ee0850e4b42967e2afa
(In reply to stragu from comment #24) > Also confirmed with the following: > > Version: 6.0.3.2 > Build ID: 1:6.0.3-0ubuntu1 > CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; > Locale: en-AU (en_GB.UTF-8); Calc: group > > But for some reason, the numbering started at 1 if I had text before the > reference and the bibliography. > > Steps updated for 6.0: > > - create new Writer document; > - insert Frame (insert -> frame -> frame... -> ok); > - place cursor inside the frame; > - insert bibliography entry (insert -> Table of Contents and Index -> > bibliography entry... -> choose one entry from database -> insert -> close); > - place cursor outside of the frame; > - insert bibliography table (insert -> Table of Contents and Index -> Table > of Contents, Index or Bibliography -> select "type" = "bibliography" and > check "number entries" -> ok); Actually, in the Contents, Index or Bibliography dialog is possible to select if we want brackets for the entry references. Options: None, [], (), {}, <>, so selecting None fixes this issue. Setting status to RESOLVED WORKSFORME
(In reply to Xisco Faulí from comment #27) > (In reply to stragu from comment #24) > > Also confirmed with the following: > > > > Version: 6.0.3.2 > > Build ID: 1:6.0.3-0ubuntu1 > > CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; > > Locale: en-AU (en_GB.UTF-8); Calc: group > > > > But for some reason, the numbering started at 1 if I had text before the > > reference and the bibliography. > > > > Steps updated for 6.0: > > > > - create new Writer document; > > - insert Frame (insert -> frame -> frame... -> ok); > > - place cursor inside the frame; > > - insert bibliography entry (insert -> Table of Contents and Index -> > > bibliography entry... -> choose one entry from database -> insert -> close); > > - place cursor outside of the frame; > > - insert bibliography table (insert -> Table of Contents and Index -> Table > > of Contents, Index or Bibliography -> select "type" = "bibliography" and > > check "number entries" -> ok); > > Actually, in the Contents, Index or Bibliography dialog is possible to > select if we want brackets for the entry references. Options: None, [], (), > {}, <>, so selecting None fixes this issue. > Setting status to RESOLVED WORKSFORME The problem behind it is still not solved. I can replicate the issue in Version: 6.4.0.0.alpha0+ stragu is right about the problem disappearing if you enter text above the bilio index. And I also can confirm, that the numbering is correct if you don't use any brackets for labeling
I confirm this bug is still present in LibreOffice 6.2.8 and 6.4.2. Reproduced by accident in own document at Debian GNU/Linux Stretch and Buster amd64, LO binaries downloaded from https://www.libreoffice.org/download/download/. K.H.
*** Bug 162722 has been marked as a duplicate of this bug. ***