Created attachment 140038 [details] ODT file that shows mangled index entry after Update->All The attached ODT document illustrates the bug. If an alphabetical index entry is placed in the text, prior to some text that is superscripted and/or italicized, the index entry itself gets mangled in various ways (after Update->All). Then mangled entry is often partially italicized, partially superscripted, and sometimes has unreadable characters. The following text shows the relative placement of the index entry, and the italicized text with superscripts. 1. [index entry here]John Doe [italic text with superscripts] As explained in the attached ODT document, the problem did not exist in 5.3.7.2, but does appear in 5.4.4.2, and in the latest release 6.0.1.1.
Looks as reported in master 61+ and started in 5.4.0. Prior versions also show italic on attachment fileopen but it's corrected after update index or Tools->Update->All and can be properly saved.
Seems to be win only. I can't reproduce it in Versió: 6.1.2.1 ID de la construcció: 1:6.1.2~rc1-0ubuntu0.16.04.1 Fils de CPU: 4; SO: Linux 4.15; Renderitzador de la IU: per defecte; VCL: x11; Configuració local: ca-ES (ca_ES.UTF-8); Calc: group threaded but I do in Versión: 6.1.2.1 Id. de compilación: 65905a128db06ba48db947242809d14d3f9a93fe Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; Configuración regional: es-ES (es_ES); Calc: group threaded
I can't reproduce it in Version: 6.2.0.0.alpha0+ Build ID: 425af6845ebe066c950b0b63f50563e067485f3e CPU threads: 16; OS: Windows 6.3; UI render: default; VCL: win; Locale: en-GB (en_GB); Calc: threaded
In a large chronological journal document I prepared with V6.0.6.2, I found that when I started my text file entry with a superscripted date (as in "1st" or 2nd), the index entry for any indexed text that follows the superscripted number has superscripts part way along the entry in the index. After some significant work, I removed the superscript from the numbers at the beginning of each line and voila, the problem disappeared. However, to be fair, I shouldn't have had to do that.
Created attachment 148246 [details] Example ODT file shows corrupted index entry I think this is the same bug. In my case the index entry is placed after some text that includes a superscript and subscript (for demonstration purposes). The index entry ends up with the same superscript or subscript in the positions from the original text. In the attached example, * The superscript “1” is at position 5, and causes the “y” in “entry” to be a superscript. * The subscript “2” is at position 8, and causes the “e” in “text” to be a subscript.
Re: original example. Updated the index in Version: 6.3.4.2 (x64) Build ID: 60da17e045e08f1793c57c00ba83cdfce946d0aa CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; Locale: en-GB (en_GB); UI-Language: en-GB Calc: threaded No bug apparent, at least as far as italics are concerned.
I cannot reproduce this bug in 6.2.8.2 (x64): Version: 6.2.8.2 (x64) Build ID: f82ddfca21ebc1e222a662a32b25c0c9d20169ee CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded The original testcase that I supplied no longer manifests the problem (when I select menu item Tools->Update->Update All). I have also put together larger and more complex test cases that fail to demonstrate the problem. The bug has probably been fixed, or at least rendered much less likely to manifest. I am going to assume this should be marked RESOLVED - FIXED.
(In reply to Rick Sullivan from comment #7) > I cannot reproduce this bug in 6.2.8.2 (x64): > > Version: 6.2.8.2 (x64) > Build ID: f82ddfca21ebc1e222a662a32b25c0c9d20169ee > CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; > Locale: en-US (en_US); UI-Language: en-US > Calc: threaded > > The original testcase that I supplied no longer manifests the problem (when > I select menu item Tools->Update->Update All). I have also put together > larger and more complex test cases that fail to demonstrate the problem. > > The bug has probably been fixed, or at least rendered much less likely to > manifest. > > I am going to assume this should be marked RESOLVED - FIXED. Thanks for retesting the issue with the latest version. Setting to RESOLVED WORKSFORME since the commit fixing this issue hasn't been identified.