Hello to all, in 5.3.0.0.beta1 and above in the configuration for the directories I've set a blank before and bihind the tab. When I create the directories, there are backspaces set for the blanks. Best regards, Helmut!
sorry I don't understand... would you please try to rephrase or post a screenshot?
Yes, a pic would be awesome. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the screenshot.
Created attachment 129273 [details] Please open it with LO-Version 5.2.4.1 and 5.3.0.0.b1 and above. Then the diffrence is shown. The same is happened by the index.
Created attachment 129288 [details] Screenshot with 5.2.3 and 5.4 They look identical. I also tested with 5.3 beta1 and it looks the same. I still don't understand the problem. Arch Linux 64-bit, KDE Plasma 5 Version: 5.2.3.3 Build ID: 5.2.3-1 CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; Locale: fi-FI (fi_FI.UTF-8); Calc: group Arch Linux 64-bit, KDE Plasma 5 Version: 5.4.0.0.alpha0+ Build ID: 8a238809ba861c810304354f01a5504d43111399 CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on December 2nd 2016
Created attachment 129290 [details] The expected result in 5.2
Ok thanks to Dennis on IRC, I finally got what is the problem. Repro steps for a completely new document: 1. Type Title1 and set its style to Heading 1 2. Insert - Table of contents.. - Table of contents.. 3. Entries tab: click to the white field between E and T and type a space 4. Click OK and observe the result In 5.3, the 1 from Title1 is chomped away.
Adding Cc: to Abhilash (abhilash300singh@gmail.com). Also adding Cc: to jan iversen (committer). Please take a look. https://cgit.freedesktop.org/libreoffice/core/commit/?id=250252d02bac88877845a4bc27e3f1837f1312ba tdf#44282 fix missing space for numbered lists in TOC Bibisect details: c3007fb15c1ced9b37e5460f585e72a497efdeec is the first bad commit commit c3007fb15c1ced9b37e5460f585e72a497efdeec Author: Jenkins Build User <tdf@pollux.tdf> Date: Tue Oct 25 11:18:56 2016 +0200 source 250252d02bac88877845a4bc27e3f1837f1312ba source 250252d02bac88877845a4bc27e3f1837f1312ba # bad: [b356e15c1f14e3d0f0bb73662c878d14fc8aa992] source ada8a2123ea655142be74a11c23e042a0109d5f8 # good: [09613c3ea582c72cd064e1627766e3e96c196ebf] source 5b168b3fa568e48e795234dc5fa454bf24c9805e git bisect start 'b356e15c1f14e3d0f0bb73662c878d14fc8aa992' '09613c3ea582c72cd064e1627766e3e96c196ebf' # good: [78a4f08cf26d3f800710c509a99b1f4ad8a4e783] source db231633af4667e24281e0be69ab63ad3081fdc3 git bisect good 78a4f08cf26d3f800710c509a99b1f4ad8a4e783 # good: [d9f68fca812338acc473efb5053add57fbdf6415] source 8fab6ab36589d0dcd75d45feab43a0b06b7f2a3e git bisect good d9f68fca812338acc473efb5053add57fbdf6415 # bad: [ed68fdb510a1b043a83cd50a28ee77bdd9ea943d] source ae3fb69ebca4e253959cdf9bf620296e7797a501 git bisect bad ed68fdb510a1b043a83cd50a28ee77bdd9ea943d # skip: [4fa90d2aa58fa9fd7ede2fdc86ee899d8faf8873] source 81dde672f15965cf77b041c1991bd260c4774278 git bisect skip 4fa90d2aa58fa9fd7ede2fdc86ee899d8faf8873 # skip: [5252aaac3066a8ee85aa5168ebedb3591b59da8e] source 918d85a82d6535932118247a7fb754dde9f49cd1 git bisect skip 5252aaac3066a8ee85aa5168ebedb3591b59da8e # good: [cff3c3864a46cefde1b6e3145995b28ae6f9f008] source 0d93900801224b797741e9a1abf305109fa35665 git bisect good cff3c3864a46cefde1b6e3145995b28ae6f9f008 # good: [35698108d9ad331d50766bc0dc3fd82cd2478d2c] source 75ab2019a577813bcca2cdbe6aae38187cb52b50 git bisect good 35698108d9ad331d50766bc0dc3fd82cd2478d2c # good: [ab310e669ca8d4163d13d21e38b3c1673d571577] source 9ab408277b8c68f3d987a36744171fc0ef1de2f6 git bisect good ab310e669ca8d4163d13d21e38b3c1673d571577 # good: [3f21e7237c02bd224ec2f9e7aefa94be6129612d] source 27a4fb657fad157d26d07934ecd0cce578a99f38 git bisect good 3f21e7237c02bd224ec2f9e7aefa94be6129612d # good: [4442ae9f0cf2b930f1b4385c3157bdda6398913a] source d129099624d2b646d975c9567541ed9c18adb7ef git bisect good 4442ae9f0cf2b930f1b4385c3157bdda6398913a # good: [a2103183a3d4865b6801657fc88cf913d46b9039] source 59ec27f44630fe129a590ba4caf6998bb671ecb5 git bisect good a2103183a3d4865b6801657fc88cf913d46b9039 # good: [05f356b59ce0ea831de9f0d90d1e8f247dbe9df4] source 681a1ca27f606282a1fb3a60d67f61c0f3ba9579 git bisect good 05f356b59ce0ea831de9f0d90d1e8f247dbe9df4 # bad: [c4d16dbfec2e2e9c0d78bf4b45050052931011cc] source 461e9cc64b5a6e9943db397d27c6415327386494 git bisect bad c4d16dbfec2e2e9c0d78bf4b45050052931011cc # good: [0831975e520cc606461ad936fbd0e0099292733a] source 0560f6cc3cd83923f03ec909a1771c6a984ee25d git bisect good 0831975e520cc606461ad936fbd0e0099292733a # good: [22b6b1216810b1b539b1aa484bd4b10808c99819] source 8ae33b1652cb1e654c426350169d3bb9fa031a4f git bisect good 22b6b1216810b1b539b1aa484bd4b10808c99819 # bad: [c3007fb15c1ced9b37e5460f585e72a497efdeec] source 250252d02bac88877845a4bc27e3f1837f1312ba git bisect bad c3007fb15c1ced9b37e5460f585e72a497efdeec # first bad commit: [c3007fb15c1ced9b37e5460f585e72a497efdeec] source 250252d02bac88877845a4bc27e3f1837f1312ba
I had written that patch thinking( after reading this http://opengrok.libreoffice.org/xref/core/sw/inc/tox.hxx#177 ) that case TOKEN_TEXT is only hit when the user types something between E# and E. Seems I'm not fully clear on when different cases are hit. Any explanations on when these cases are hit will help. I'll take a look again. Thanks.
Created attachment 129322 [details] The case happened, when I set a blank before T and set a blank behind T
Dear all, there is happened nothing for 2 weeks. Is the bug working in process? I'm still interessted in the development of the bug. I've installed Version 5.3.0.0.b2. There the bug is continued. For all I wish a merry christmas and a happy new year, Helmut!
please do not change status field. the bug was already confirmed so correct status is NEW, not UNCONFIRMED
Dear all, I've installed Version 5.3.0.1. The bug isn't fixed. What can I do for the answer to the problem? Best regards, Helmut!
consider that is Xmas time and development is slow in this period.
Hello, what's the matter with my bug? - Version 5.3.0.3 may be downloaded. The bug is still find. My regards, Helmut Wolff!
*** Bug 105698 has been marked as a duplicate of this bug. ***
Would it be possible to revert the offending commit until a better fix is found? Thanks!
*** Bug 105758 has been marked as a duplicate of this bug. ***
*** Bug 105763 has been marked as a duplicate of this bug. ***
ugly hack indeed with bug 44282 ;) On the other hand: how often does one set a space _after_ the item in the TOC? So not sure if the patch should be reverted right away.
(In reply to Cor Nouws from comment #19) > On the other hand: how often does one set a space _after_ the item in the > TOC? see bug 105758, comment 0 >> Additional Info: >> ... >> The index format I am using is the format recommended >> in both The Chicago Manual of Style, and The Oxford Guide to Style. >> >> So I would say it is fairly important that this works properly in Writer. > So not sure if the patch should be reverted right away. imo, it should be reverted as there is no workaround for this bug. but bug 44282 as an easy workaround, add a space after the chapter number in the TOC.
*** Bug 105859 has been marked as a duplicate of this bug. ***
Helmut: please stop changing the fields to wrong content. You keep changing architecture to 64-bit and OS to Windows, even though there are reports/confirmations on 32-bit and Linux.
(In reply to Cor Nouws from comment #19) > ugly hack indeed with bug 44282 ;) > > On the other hand: how often does one set a space _after_ the item in the > TOC? > So not sure if the patch should be reverted right away. In our environment, for every single document. We have spaces directly after the item and before the page number. It is easier to read for the viewer IMHO.
(In reply to Cor Nouws from comment #19) > ugly hack indeed with bug 44282 ;) > > On the other hand: how often does one set a space _after_ the item in the > TOC? > So not sure if the patch should be reverted right away. Adding a space is not the only trigger of this bug. In my bug report: Bug 105758 - Writer 5.3.0.3 Truncates Alphabetical Index Entries I deleted the [T] (tab) and replaced it with ", " (comma space) Same problem, truncates last letter. Just tested with other characters replacing the tab. - Comma alone - same problem, truncates last letter. - Underline character alone - same problem, truncates last letter. - Letter X alone - same problem, truncates last letter. So this bug affects virtually any change which deletes the tab entry. Furthermore it makes no sense for the default index format to include this tab. It would make more sense for the default index format to be what is actually used in professional documents. Pick up virtually any textbook or technical book on your bookshelf and take a look at the index. It will most like likely have an index formatted as recommended by The Chicago Manual of Style and/or The Oxford Guide to Style. Neither of these guides recommends an Index format which looks like a Table of Contents. It would make more sense for the default Index format in LibreOffice to follow the recommendations of these industry-standard guides - like virtually every book on your bookshelf. Why should LibreOffice users have to fix this every time they make a new document? That is just dumb.
Just tested with entering nothing after deleting the tab. Same issue, truncates last letter.
(In reply to LibreTraining from comment #24) > > Adding a space is not the only trigger of this bug. Then I request to immediately revert the patch that caused this problem.
*** Bug 105916 has been marked as a duplicate of this bug. ***
Created attachment 131167 [details] Example file showing and describing the problem with another character than space This attachment uses an x instead of a space, partly for visibility (a space is hard to see), partly to demonstrate that the problem is not specific for a space. The bug may be a regression (I only experienced it myself recently), but de-installing the fresh LO version (5.3.0.3) and instead installing the current still version (5.2.5.1) does NOT make the bug disappear!
*** Bug 106003 has been marked as a duplicate of this bug. ***
(In reply to Xisco Faulí from comment #29) > *** Bug 106003 has been marked as a duplicate of this bug. *** OK, So I still urgent repeat the request to kill the last patch, back to the version of 5.2.4, where there not this problem with killing letters, but also, that the TAB-Funktion to set the TAB to the right side by confirming, will be killed, if you put any letter between the "T" and the "#" AND a letter behinde the "#" will also kill the page number! So this bug make the complete use of the open textfield between all functions of the ToC-formating to non-sense. So please debug this last patch! Thanks alot!
Hi abhilash, (In reply to abhilash300singh from comment #8) > I had written that patch thinking( after reading this > http://opengrok.libreoffice.org/xref/core/sw/inc/tox.hxx#177 ) that case > TOKEN_TEXT is only hit when the user types something between E# and E. > Seems I'm not fully clear on when different cases are hit. Any explanations > on when these cases are hit will help. I'll take a look again. If you have no better solution now, can you please revert the patch shortly?
*** Bug 106017 has been marked as a duplicate of this bug. ***
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dc8ebf205c3231ffc4d6737b53cee396c2ac0bfd tdf#104315: Revert "tdf#44282 fix missing space... It will be available in 5.4.0. 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.
Commit reverted in master and cherry-picked to 5.3: https://gerrit.libreoffice.org/#/c/34295/ Closing this one as RESOLVED FIXED and reopening bug 44282
*** Bug 106005 has been marked as a duplicate of this bug. ***
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=05116fb49efa563610f6486d0c3f6216624dcd13&h=libreoffice-5-3 tdf#104315: Revert "tdf#44282 fix missing space... It will be available in 5.3.1. 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.
*** Bug 106036 has been marked as a duplicate of this bug. ***
(In reply to Commit Notification from comment #36) I just tested with LibreOfficeDev 5.3.1.0.0+ and the issues has not been resolved. The last characters are still not displayed for Entry upon insertion of a blank space between Entry and Tab stop.
(In reply to Darius Daniel Grigoras from comment #38) > (In reply to Commit Notification from comment #36) > > > I just tested with LibreOfficeDev 5.3.1.0.0+ and the issues has not been > resolved. The last characters are still not displayed for Entry upon > insertion of a blank space between Entry and Tab sto Have you used today's build which includes http://cgit.freedesktop.org/libreoffice/core/commit/?id=05116fb49efa563610f6486d0c3f6216624dcd13&h=libreoffice-5-3 ? If so, please open a follow-up ticket and let's keep this one closed as the problematic commit has been reverted.
*** Bug 106092 has been marked as a duplicate of this bug. ***
*** Bug 106258 has been marked as a duplicate of this bug. ***
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/22069151cdf12729ef675f2f5a8d7a069e1c5378 tdf#104315: sw_uiwriter3: Add unittest It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Sorry for having to ask, but is unclear to me what was left of the bug? With LO 7.5.1.2, I see strange endings in the table of contents upon opening each of the two example files, but when I update the table of contents, it looks OK. Version: 7.5.1.2 (X86_64) / LibreOffice Community Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: da-DK (da_DK); UI: da-DK Calc: threaded I do not see different behaviour when I use the newest development version. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b5c3a7502f7ff6ccf0f829c1f3a2ba50b8584c41 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: da-DK (da_DK); UI: da-DK Calc: threaded I may be overlooking something, but what is still buggy in the 7.5 line from before the latest patch?
(In reply to Lars Jødal from comment #43) > I may be overlooking something, but what is still buggy in the 7.5 line from > before the latest patch? There has been nothing buggy about this since 5.4. The latest commit was adding an automated test to guard against the bugginess from ever appearing again.