Bug Hunting Session
Bug 52640 - FORMATTING : tabstops malfunction in Draw and Impress
Summary: FORMATTING : tabstops malfunction in Draw and Impress
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
3.6.2.1 rc
Hardware: All All
: high critical
Assignee: David Tardon
URL:
Whiteboard: target:4.0.0 target:3.6.5
Keywords: regression
: 52987 53966 54103 57986 (view as bug list)
Depends on:
Blocks: mab3.6
  Show dependency treegraph
 
Reported: 2012-07-29 17:30 UTC by Ismael Cedillo
Modified: 2013-06-26 09:42 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Wrong text alignment on tabstops in Draw 3.6.2.2 (52.83 KB, image/png)
2012-10-05 12:53 UTC, Raphael Rochet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ismael Cedillo 2012-07-29 17:30:29 UTC
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.
Comment 1 Jean-Baptiste Faure 2012-07-31 18:35:32 UTC
*** Bug 52987 has been marked as a duplicate of this bug. ***
Comment 2 Joel Madero 2012-08-02 21:56:16 UTC
This seems to be working for me in 3.7.0.0.alpha0+ (Build ID b806b63).
Comment 3 Ronald V Popowich 2012-08-30 15:54:36 UTC
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.
Comment 4 Raphael Rochet 2012-09-10 15:48:20 UTC
I can confirm this in 3.6.1.2 (Archlinux build)
Comment 5 Raphael Rochet 2012-09-16 11:16:40 UTC
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.
Comment 6 Raphael Rochet 2012-09-22 08:19:40 UTC
I confirmed this bug on fresh install of Version 3.6.2.1 (Build ID: ba822cc) on Windows. (Both Draw and Impress)
Comment 7 Raphael Rochet 2012-09-22 08:28:46 UTC
*** Bug 53966 has been marked as a duplicate of this bug. ***
Comment 8 Raphael Rochet 2012-09-22 08:49:08 UTC
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)
Comment 9 Joel Madero 2012-09-22 19:19:45 UTC
Perfect, thanks for confirming. I'll try to find someone to tackle this next week
Comment 10 Raphael Rochet 2012-10-05 12:48:42 UTC
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.
Comment 11 Raphael Rochet 2012-10-05 12:53:12 UTC
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.
Comment 12 Raphael Rochet 2012-10-23 13:49:41 UTC
Marking this as blocking. This regression prevents 'normal' use as it breaks existing documents.
Comment 13 Petr Mladek 2012-10-23 15:49:47 UTC
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.
Comment 14 Petr Mladek 2012-10-23 15:55:18 UTC
*** Bug 54103 has been marked as a duplicate of this bug. ***
Comment 15 Raphael Rochet 2012-11-10 22:52:05 UTC
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.
Comment 16 David Tardon 2012-12-04 12:53:52 UTC
caused by misplaced 'const' in combination with overloaded function
Comment 17 Not Assigned 2012-12-04 13:29:52 UTC
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.
Comment 18 Rob Snelders 2012-12-13 21:29:21 UTC
*** Bug 57986 has been marked as a duplicate of this bug. ***
Comment 19 Joel Madero 2012-12-13 21:31:42 UTC
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
Comment 20 sergio.callegari 2013-01-20 14:53:27 UTC
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.
Comment 21 Joel Madero 2013-01-20 21:11:20 UTC
@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
Comment 22 Björn Michaelsen 2013-06-26 09:42:30 UTC
already backported to 3.6.5 as:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=032d1d3cf5f69c28a39ba7e8a62eb580e545a0d5