Created attachment 120606 [details]
Example document demonstrating ruler with wrong tabstops
In tables/frames where spacing to contents is applied, the ruler doesn't account for this change. This will make the ruler representation for tabs always be off by the amount of the spacing to contents.
Steps to reproduce:
* New document
* Insert 1 cell table
* Table Properties -> Borders -> Set spacing to contents for all sides to 1 inch
* Insert a tab in the table (ctrl-tab)
* Use the ruler to set the tab to something like 2 inches
Our cursor should be under the tab marker in our ruler.
Since our spacing to contents never adjusted our ruler to begin with, the ruler tab representation is left of our actual tab by a full inch (the size of our spacing to content).
This problem seems to have been introduced in LibreOffice 4.2.x and is still present in the 5.1 nightlies. I've bibisected:
1cb483c5f696c8e7d262c7959e482f2bc2edc0cb is the first bad commit
Author: Bjoern Michaelsen <firstname.lastname@example.org>
Date: Fri Oct 18 08:55:44 2013 +0000
Author: Jan Holesovsky <email@example.com>
AuthorDate: Mon Sep 16 16:30:45 2013 +0200
Commit: Jan Holesovsky <firstname.lastname@example.org>
CommitDate: Mon Sep 16 17:04:03 2013 +0200
Related bnc#819614: The diagram is a group.
It is not really desired to import diagrams broken into individual objects;
makes trouble with the hieararchy, and also the user wants to see it as a
group - can be ungrouped for modifications easily.
:100644 100644 fee0f30959daf77c81436a4f8ac3e02565f8eeeb c75c37d83ee583b525d1d7b5e20160f317b1ece9 M ccache.log
:100644 100644 e9d2d40d848a15a42165222cc8523b2eb6e76dd6 af1032fa0056513199b478e1bc898479e5bddb7d M commitmsg
:100644 100644 dcfc3034a0ec4a0dd291eb47e8f5e74dfe2a68db 389eee42cd988e4e17d77afea6674dd465e6c2a1 M dev-install.log
:100644 100644 5e75a14ac7b006e5f559156a71a77ca88fd96bab 99667ecacb0583c14353535065c393ab43bd8cd3 M make.log
:040000 040000 db81fdeb8c6fa6df65425276c2768c93b74c5464 4a96cccb9e759f62b07d63e63da4a57cc5b622df M opt
$ git bisect log
git bisect start 'last43onmaster' 'last41onmaster'
# bad: [33ac6698e6d90d84f99d784b9553ee87eec27d6a] source-hash-732c0f929fc0229b6da37d4ec4b6de8994fcea46
git bisect bad 33ac6698e6d90d84f99d784b9553ee87eec27d6a
# bad: [e3a648fdaa2bb87293750400b70ba590733a804a] source-hash-33526481788137d959f27ae32910127d1436c1a8
git bisect bad e3a648fdaa2bb87293750400b70ba590733a804a
# good: [b886825d7eb2550ab40d7b4cd16de8096c57d6eb] source-hash-b46688a663b8709e0e0795f25ef8961db1f46cba
git bisect good b886825d7eb2550ab40d7b4cd16de8096c57d6eb
# good: [f789e50909694bc398aaca477bc79ea38828034e] source-hash-e926621fb00f31471b0037d7955b6a3d7f908dc0
git bisect good f789e50909694bc398aaca477bc79ea38828034e
# good: [73ffd89349ad4e6772d1c0e672f1fe49750077e6] source-hash-d261ddf3c8e76b44b07ea8be69234a123d2f4271
git bisect good 73ffd89349ad4e6772d1c0e672f1fe49750077e6
# good: [f404200bd6f153825680cab6261f756ef7b77770] source-hash-b73dec8a06ef762098e642b2c37e4baad780b11a
git bisect good f404200bd6f153825680cab6261f756ef7b77770
# bad: [1cb483c5f696c8e7d262c7959e482f2bc2edc0cb] source-hash-59373b753902f69cd44d183568b084429322e7ab
git bisect bad 1cb483c5f696c8e7d262c7959e482f2bc2edc0cb
# good: [f183d146de94c2dea7931279049827aedf4f01a4] source-hash-6fe1efc01d6f9dc333a74a4e76e554b182651f60
git bisect good f183d146de94c2dea7931279049827aedf4f01a4
# first bad commit: [1cb483c5f696c8e7d262c7959e482f2bc2edc0cb] source-hash-59373b753902f69cd44d183568b084429322e7ab
Win 7 Pro 64-bit Version: 22.214.171.124.alpha1+
Build ID: b216cc1b8096eb60c27f67e8c27b7cd756c75e38
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-11-12_00:06:20
Locale: fi-FI (fi_FI)
Migrating Whiteboard tags to Keywords: (bibisected)
Seems to be the same as bug 96558
Trent: you can decide how to dupe.
*** Bug 96558 has been marked as a duplicate of this bug. ***
It looks like this regression was introduced by
Author: Tomaž Vajngerl <email@example.com>
Date: Thu Sep 12 21:05:14 2013 +0200
ruler: RTL fixes for indents in tables and columns
Adding Cc: to Tomaž Vajngerl
Still reproducible in:
Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1
CPU threads: 4; OS: Mac OS X 10.9.5; UI render: GL;
Locale: en-US (en.UTF-8); Calc: group threaded
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!