The setting of tab-stops in Draw and Impress components put them only as left-tab-stop, the right-tab-stop, decimal-tab-stop or center-tab-stop are not functioning. 1. Open a new Draw or Impress document 2. Put a text box with enough horizontal dimension (i.e. 6 in) 3. In principal menu select "Format", and then "paragraph" 4. Select "tabs" section. 5. set a new right-tab-stop or any other different to left type, i.e. at 2 o 3 in 6. Select OK 7. type the tab key and write the text... it is not functioning correctly.
*** Bug 52987 has been marked as a duplicate of this bug. ***
This seems to be working for me in 3.7.0.0.alpha0+ (Build ID b806b63).
Bug remains in: Version 3.7.0.0.alpha0+ (Build ID: 85e40d7) All tab stops appear as left aligned regardless of left, centre, right, or decimal. Reverting to OpenOffice until repaired; master page in Draw does not correctly display headers & footers created as text boxes with tab stops.
I can confirm this in 3.6.1.2 (Archlinux build)
As said before, this bug breaks all Draw & Impress documents with headers & footers created as text boxes with tab stops. I think that this bug's importance must be increased.
I confirmed this bug on fresh install of Version 3.6.2.1 (Build ID: ba822cc) on Windows. (Both Draw and Impress)
*** Bug 53966 has been marked as a duplicate of this bug. ***
This bug has been reported on multiple versions and multiple platforms by multiple users. (see duplicates) Marking it back at 'NEW' to give it a chance ... It's a regression from 3.5.x and breaks documents. Some users already switched back to OpenOffice for this. There is the same bug on Impress component (bug url in 'see also', has duplicates too)
Perfect, thanks for confirming. I'll try to find someone to tackle this next week
In case someone asks : yes, still present in 3.6.2.2 release. Also a precision that has not been noted : tab icons in ruler are correct, and line caracters are correct. Only text alignment is wrong.
Created attachment 68117 [details] Wrong text alignment on tabstops in Draw 3.6.2.2 You can see that tab icons in ruler are Ok, also line drawings are Ok. Only Text alignment is wrong.
Marking this as blocking. This regression prevents 'normal' use as it breaks existing documents.
I agree that it is annoying and we should fix it ASAP. Well, it was in several 3.6 releases. It is a "non-trivial" scenario => it should not block 3.6.3 release with other useful fixes => reducing the severity a bit; instead, I listed it in most annoying bugs to get the proper attention.
*** Bug 54103 has been marked as a duplicate of this bug. ***
3.6.3 is now the recomended version for all users. But still have this annoying bug. Do you still think we should not consider it as blocker ? That's not a shiny new feature for fun ... that's a real pain when you use LibreOffice at work and have many drawings/presentations that use left/center/right tabstops in headers/footers.
caused by misplaced 'const' in combination with overloaded function
David Tardon committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=104a855ade9102d694293c1059f99946752f76d8 fdo#52640 fix right-aligned tabstops 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 57986 has been marked as a duplicate of this bug. ***
Just for the information of users posting bugs, a blocker bug is a bug that a) Causes data loss, crashes, memory issues, etc... b) is part of a feature that is incredibly popular When prioritizing bugs, please keep this in mind, this bug should have been marked as "Normal" probably which is basically "can prevent high quality/professional work" @David: Thanks for the patch
I tend to agree (I was one of the original posters of a bug that was marked as a duplicate of this one and if I remember correctly I had not risen the priority as high as 'blocker' at the beginning). However, I take the occasion to notice that long lasting regressions on presentations can really hurt the image of the project. It is really bad when one needs to apologize maybe in front of a 100 people audience because the presentation looks messed. This is not a criticism, just a suggestion that bugs breaking previously drafted presentations should probably be prioritized a little more, on a 'marketing' rather than a truly 'functional' basis.
@Sergio - thanks for the feedback, we're always looking to improve QA policies. We tend to use the Highest - Lowest standard for what you're talking about instead of Blocker - Enhancement. The Blocker - Enhancement is really to define the functionality aspect - ie. loss of data, professional quality, no real impact and just a suggestion, etc.... I agree that having to apologize in front of 100 people is no good, but compare that to trying to open a document and it saying "this file is corrupt" and I think you can see that while the first one is embarrassing, the 2nd one could very well end a presentation before it begins. I use this https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg diagram when I am triaging a bug
already backported to 3.6.5 as: http://cgit.freedesktop.org/libreoffice/core/commit/?id=032d1d3cf5f69c28a39ba7e8a62eb580e545a0d5