[Upstream] No horizontal ruler snapping in Writer

[Rapachooie]

Binary package hint: openoffice.org

1) lsb_release -rd
Description: Ubuntu 11.04
Release: 11.04

2) apt-cache policy libreoffice-writer
libreoffice-writer:
  Installed: 1:3.3.2-1ubuntu5
  Candidate: 1:3.3.2-1ubuntu5
  Version table:
 *** 1:3.3.2-1ubuntu5 0
        500 http://us.archive.ubuntu.com/ubuntu/ natty-updates/main i386 Packages
        100 /var/lib/dpkg/status
     1:3.3.2-1ubuntu4 0
        500 http://us.archive.ubuntu.com/ubuntu/ natty/main i386 Packages

3) What is expected to happen is when one clicks the horizontal ruler in effort to set up consistent margins, tab stops, and paragraph indents, it snaps to the markers.

4) What happens instead is they have complete freedom of movement.

WORKAROUND: Click Format -> Paragraph... -> Indent & Spacing tab and choose desired indents.

WORKAROUND: Use AbiWord.

apt-cache policy abiword
abiword:
  Installed: 2.8.6-0.3build1
  Candidate: 2.8.6-0.3build1
  Version table:
 *** 2.8.6-0.3build1 0
        500 http://us.archive.ubuntu.com/ubuntu/ natty/universe i386 Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
Architecture: i386
DistroRelease: LinuxMint 6
Package: openoffice.org-core 1:3.0.1-7ubuntu1~intrepid1
ProcEnviron:
 PATH=/usr/lib/openoffice/program:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: openoffice.org
Uname: Linux 2.6.27-7-generic i686
UnreportableReason: This is not a genuine LinuxMint package

[Deragon-j (deragon-j)]

On the ruler, one can setup tab stops. However, the tab stops are not snapping
at specific intervals like if there was a grid. They are free floating, which
make them difficult to manage and set them at a proper place, specially when
working on a high resolution screen. By default, they should snap, snapping
should be an option that can be enabled/disabled and the interval for the snap
grid should be configurable.

[Cloph (cloph)]

confirming, setting target-milestone to "not determined", OS to ALL, Platform to ALL

PS: for advanced usage you should define the Tabs in a style and apply that
style instead of doing hard-formatting/layouting. Besides that, the default
tabstops are already at fixed intervals (the interval can be set using
Tools|Options -> Textdocument) which is almost equivalent to a grid...

but this is still is a valid request...

[A-hk-u (a-hk-u)]

Reassigned to BH

[Deragon-j (deragon-j)]

Off topic, but what would be nice is that one can setup the tab stops visually,
then right-click for the context menu to appear and choose "Apply changes to
style" and the style is automatically updated with the current's paragraph settings.

Do you feel this is warrent of a new issue?

[Cloph (cloph)]

You can already do that.
Edit the paragraph to suit your needs, define the tabstops, etc. and then launch
the stylist. The rightmost button can be used to update the style.

[Cloph (cloph)]

*** Issue 65932 has been marked as a duplicate of this issue. ***

[Cloph (cloph)]

*** Issue 66270 has been marked as a duplicate of this issue. ***

[Sba-t (sba-t)]

SBA: Adjusted summary. This affects all items on the ruler:
 - tab stops
 - paragraph margins
 - table cell borders
 - objects in text (text frames + graphics)

Note: In Draw, this can be configured with a configurable grid.

[Mmenaz-x (mmenaz-x)]

I've seen how the most widely used proprietary program works, and seems fine to me:
the ruler snap is set to the same visual guidelines of the ruler, that are every
2.5mm (you have 4 in every cm).
In the ruler you have the number, i.e. 3, then a small vertical line (at 3.25
position), a bigger vertical line (at 3.5 position), then a small one again (at
3.75 pos.) and the next number (i.e. 4)
Like:
...3--'--I--'--4--'--I--'--5...
This setup seems very reasonable to me, and needs not custom configurability.
In Draw is configurable but that is a drawing program, so you can have different
and special needs, while for writing letters the above visual snap is all what
you need. So better not bloat the config interface with another parameter to set
(and consider the support issues to those that have accidentally set it wrong...).

[Tomory (tomory)]

This is a feature I sorely miss, coming from Word. As for the advice about
using styles: I use styles extensively, but I prefer to design them visually
using GUI tools. "GUI" need not be synonymous with "imprecise."

N.B.: In Tools - Options - OpenOffice.org Writer - Grid, there already exist
settings that _seem_ like they should govern this behavior, but they apparently
are for something else, or are unimplemented, or both. (That tab is largely
undocumented, so I can't tell whether it's supposed to be relevant to this
feature, but it seems like it would be.)

[Dbachmann (dbachmann)]

I agree this is a rather pressing issue. It's not absolutely crippling, but it
significantly annoys people coming from Word. I also expected Tools - Options -
OpenOffice.org Writer - Grid to address this.

[Bh-1 (bh-1)]

Hi Mathias, I have changed the current owner to your owner. Please take the
ownership of these enhancements.

[Jwork123nl-9 (jwork123nl-9)]

It is unbelievable that such a basic issue still is not solved.
Is this due to programming difficulty or is the issue not seen as a problem
with developers?
This is one of the really annoying things when migrating from other word
processors.

[Mba-e (mba-e)]

I think you exaggerate. While this might be an issue for some users (votes tell
that) many others won't recognize it at all (like me, I never use the mouse for
things like this and use styles instead where I enter the values numerically).
It surely isn't one of the most important issues in OOo Writer. And I hope you
agree that more important things should be done first.

BTW: If everything is declared as important, nothing is really important. So
don't expect that comments like yours can make any difference. We get them in
nearly every RFE.

My personal feeling is that this issue is one of medium importance. Not
unimportant but clearly less important as e.g. a missing outliner, a missing
normal view etc. And all of these issues take time, sometimes a lot of time. So
please think about that before you make one of these "it's unbelievable..."
comments.

[Mmenaz-x (mmenaz-x)]

to mba and all the other developers:
Premise: developers are doing a great work! Thanks!
COmplain: what I see as a big problem in OOo is the fact that "important" avoids
consider daily annoiances and problems users can face. I.e. developers consider
much more important a crash that occurs 1 time over 1.000.000 instead of an
"annoiance" that a user faces every day many times a day.
There are too much exaples of this, unfortunatly. Just I can remember / report
the first ones comes to my mind:
1) this issue ;)
2) the decimal separator of the numeric keyboards in Calc (fixed after too much
time)
3) calc that as default prints ALL the sheets and not the current one (solved
just recentrly, but with problems in the preview page number)
4) writer that did not had (or still has?) the "create single print jobs",a real
night mare if you have double side printer and have to print multiple copies
5) "Deleting newline deletes formatting on subsequent line (when in empty
paragraph)" #50135, was targeted for 2.3 then moved to "2.x"
6) etc. ;)
In short, watching OOo fix around 1.200 bugs / improvements, and have vary
annoying (belive me, I use OOo in my office) that seems (of course, for someone
that is familiar with the huge codebase) "easy to fix" be there since 1.1
version is something that makes you scream "unbelivable".
Also being one that tries to move people from M$crap to OOo, and be ashamed for
some of these "bugs" is really a bad experience. Remember that people that try
to move from M$ don't give OOo many chances, once Calc prints 50 sheets instead
of 1 Excel would have printed, they simply remove OOo. And having me forced to
set tabs and margins in numeric way with a dialog instead of simply drag with
the mouse is something that I fight daily and depresses mee too.
So please, for OOo sake, put users priorities on top of developers one. Btw,
also the "format paintbrush" does not work as expected, developers defending the
behaviour for "tecnical reasons", while users are upset because works not as
expected. Users don't mind about internal rapresentation or the way the code is
build, they follow their mental model, and that's what developers should care
most (see Alan Cooper's books about it, for instance).
Again, the above complain does not mean that I (we) don't apreciate your work,
just I (we) think that priorities should be fixed with another, more "productive
/ user friendly" criteria.

[Mmenaz-x (mmenaz-x)]

ehm, of course
"4) writer that did not had (or still has?) the "create single print jobs",a real
night mare if you have double side printer and have to print multiple copies"
have to be read as
"4) writer that did not had (or still has?) the "create single print jobs" AS
DEFAULT SETTING, a real
night mare if you have double side printer and have to print multiple copies"

[Jwork123nl-9 (jwork123nl-9)]

Hi mba,

First of all thanks for responding so promptly.
I like that aspect from the volunteers and paid staff of the Openoffice.org
community.

Apart from this I have to say I never had any luck with seeing my
reported issues.
And some issues are just not solved for years...

For example, I still get spurious (leftover) lines on the display after
having moved the ruler. I guess this will never be solved, since I use
the least interesting OS (Linux) with the least interesting environment
(KDE).
http://www.openoffice.org/issues/show_bug.cgi?id=50954

Also for some (unknown) reason Openoffice decided not to implement the
Microsoft-like three-triangle paragraph setting widget on the tab bar.
Together with the bug on non-snappability this makes it much more difficult
to easily create hanging indents.
BTW this ruler change was in the plan for 2.0, but never implemented, for
unknown reasons.

I agree with the previous poster that indeed user priorities should not be
forgotten.

As to my wording, I try not to be denigrating, It is just the literal fact:
I really cannot believe it, it is an expression of my feeling!

Best of luck

John

[Jwork123nl-9 (jwork123nl-9)]

MBa, one more remark, meant in good spirit :-)

Your advice of using styles and entering numerical values will not be
appreciated by my wife, who uses Openoffice mainly to create one
or two page letters.

Please try to understand the way in which people want to use a word processor
For simple letters you do things manually using the provided elements of the
UI. For more complicated jobs you use styles etc. For yet more challinging
document that need to be typgraphically well layed out and aligned you do
not use Openoffice.org at all, but something like Scribus.

But Openoffice.org should really be usable for users from the first category
above, and this is something that developers may loose sight of.

[Mba-e (mba-e)]

Thanks for your reply; it lets me understand your motivation better. But OTOH
you should see our situation: beneath the permanent bug fixing we have to do and
the unfortunate fact that we have to implement yet-another-Word-import-filter
(sigh) we have a lot of RFEs, just take those with more than 10 votes:

http://www.openoffice.org/issues/buglist.cgi?component=Word+processor&issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&email1=&emailtype1=exact&emailassigned_to1=1&email2=&emailtype2=exact&emailreporter2=1&issueidtype=include&issue_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=&short_desc_type=allwords&long_desc=&long_desc_type=allwords&issue_file_loc=&issue_file_loc_type=substring&status_whiteboard=&status_whiteboard_type=substring&keywords=&keywords_type=anytokens&field0-0-0=votes&type0-0-0=greaterthan&value0-0-0=10&cmdtype=doit&namedcmd=mba+2.3&newqueryname=&order=Reuse+same+sort+as+last+time&Submit+query=Submit+query

As you can see we are working on some of them, but it's impossible to work on
all of them now. You also can see that the number of votes is not the only
criterion for what we do next (I explained that some time ago in our GullFOSS blog).

[Mba-e (mba-e)]

Sure, my comment wasn't done to deny this request for enhancement, it was just
meant as a hint that this is a problem that only a part of our users have - and
an explanation why it can be *believable* ;-) that we didn't fix it.

[Rb-henschel (rb-henschel)]

*** Issue 82447 has been marked as a duplicate of this issue. ***

[Discoleo-3 (discoleo-3)]

The Items on the ruler should also snap to positions of existing items (IF these
differ from the defined positions).

Added myself to cc-list.

[Cloph (cloph)]

*** Issue 83125 has been marked as a duplicate of this issue. ***

[Ace-dent (ace-dent)]

*** Issue 4029 has been marked as a duplicate of this issue. ***

[Ace-dent (ace-dent)]

*** Issue 89636 has been marked as a duplicate of this issue. ***

[Ace-dent (ace-dent)]

For info, these two Issues are closely related:
Issue 22503 - Position ToolTip needed when dragging margins on rulers
Issue 24070 - Items on ruler (i.e. tab stops, paragraph indent, table borders)
should snap.

[Typist-k (typist-k)]

"------- Additional comments from cloph Sun Jan 4 21:56:56 +0000 2004 -------"

It's maybe time to set the priority of unaddressed-for-years, nonetheless
important issues some steps higher - perhaps a step a year - we'd reach priority
-2 very soon, this way.

Stacking 'duplicates' is maybe fun, but not very sportive.

Regards,

typist

[Mba-e (mba-e)]

setting target 3.x for better visibility

[Chris Cheney (ccheney)]

I'm not certain what you are talking about with respect to the gray alignment arrows.

For alignment of tables does the format tables dialog not give you sufficient information to align them properly? It seems to allow me to set the table exactly where I want it on the page.

[Chris Cheney (ccheney)]

Oh, I think I might know what you are talking about now and I think the reason you think it isn't working is that the grey arrows only appear to format text and not the tables themselves. To format the tables you have to use the format table dialog.

[Rapachooie (g-bonello)]

Yes I know what you mean about using the format table dialog, but it is substantially more difficult than simply snapping the alignment arrows (sorry, I dont know their proper name) on the ruler.

If you have a look as MS office or Abiword, they implement this and its very useful (one of those useful things that I didnt realise I needed til I missed

For example, I completed a document recently that had almost as much table-content as there was word content. I wanted all of it aligned in the same way (text in tables and edges etc) and if the aligners snap to a specific set of points, which are ALWAYS UNIFORM, then its extremely easy to set alignment of text.

You said you can align the text as you like now, and yes I can too, but it allows for alignment to ANY increment... this isnt really useful I think... I dont think anyone would want even small alignment variances, and as I see it, I cant be sure that all of my text is aligned in this way; I would instead need to manually enter in a left alignment amount in the "indents and spacings" tab.

I really think it would be good if some pre-determined ruler snapping points were implemented (or at least, implemented, and disabled by default with the option to activate it for people such as myself) as per ms office and abiword.

Thanks for looking at it.

[Chris Cheney (ccheney)]

Can you please report this bug upstream at http://www.openoffice.org/issues/query.cgi , it would be better if you worked with the OpenOffice.org developers directly on this problem. After reporting the problem in their bugtracker please attach the bug number to this bug report. Thanks!

[Chris Cheney (ccheney)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

[Rainerbielefeld (rainerbielefeld)]

*** Issue 104774 has been marked as a duplicate of this issue. ***

[Mru-o (mru-o)]

*** Issue 108611 has been marked as a duplicate of this issue. ***

[Jamesblevins (jamesblevins)]

I hate registering for websites I won't visit very often. So I never do it
unless I have feel an overwhelming urge to do so. This issue is the _only_
reason I created an account. I also gave it the maximum number of votes allowed,
as this nonsense of the ruler not snapping makes me hate OOo. I so desperately
want to love it, but it's the "little things" like this that make me dislike it.

I've read the comments. I know that the developers want to have users create
styles and format their documents based off those styles. It's the "better" way.
I get that, and will probably start doing things that way.

Normal users, on the other hand, want to do things using the path of least
resistance. If it involves having to go to the help and do some planning, many -
if not most -users will not do it. They would rather invest two seconds every
time they open a new document to set the hanging indent by dragging the slider.
They don't want to spend 15 minutes figuring out how to do it the "right" way.
Most users aren't power users, so they couldn't care less about doing things the
One True Way(TM).

Please think about this for just a moment. You can't set the hanging indent with
any precision by using the slider. Say you want a .75" indent. Maybe with blind
luck you could get the slider to land there. Odds are, you'll have to go format
your paragraph and enter it manually anyway.

Since you can't set tab stops with the slider and have to set them with the
keyboard, do you realize what that means? The slider to set tab stops is:

Completely. Useless.

Actually, it's even worse than completely useless. Because it works in an
unusable manner, it tricks the user into thinking it is useful for something
when it actually isn't. It's a hypocritical illusion of a feature that pushes
people away from using OOo. It screams, "This product lacks polish, and the
developers don't really have a clue how people use/want to use their product."
It drives people away from OOo.

Six-and-a-half years is far too long to let this languish. As for number of
votes (also duplicated 8 times) being an indicator of how important this is to
users, I can tell you that Grandma and Joe Sixpack aren't going to go through
the hassle of getting an account just so they can vote on this issue. Yet, this
is precisely the kind of thing they're going to notice right away and beg the
geek in their life to find them a copy of Microsoft Office somewhere.

I know programming isn't easy because I do it on a regular basis. I also do a
lot of end-user support. OOo is a massive undertaking, and I think that overall,
you guys do a phenomenal job. I want this project to succeed. We need open
formats and open-source software with which to create it. We need OOo. I want to
see more and more people adopt it. It kills me that this issue creates negative
first impressions of an otherwise spectacular product.

Please reconsider your classification (enhancement) and priority (P3) of this
bug. Thank you.

[Adion (adion)]

jamesblevins said it perfectly - I also created an account months ago just to
vote on this single issue. I'd rather not create half-a-dozen styles with
various hanging indent values (which in itself is more complicated than it needs
to be) in each and every new document. I was eager to make OOo my new office
suite of choice when I switched to Linux a few months back, but there seem to be
not just one, but several operations in OOo that are akin to digging a hole to
install a ladder to wash the basement windows. Just plain unnecessary and
time-wasting.

[Jwork123nl-9 (jwork123nl-9)]

It seems OpenOffice developers like working more on high profile user interface
redesign and importing/exporting alien file formats than some basic usability
issues.

I think that this bug will never be solved. It has been discussed to death
in the forums since at least 2003.
http://www.oooforum.org/forum/viewtopic.phtml?t=46

Ona related note, did anyone notice that feature plan for OpenOffice.org 2.0 (!)
contained an entry about creating a MS office like ruler to easier create
hanging indents?
(using three triangles instead of two). Was never implemented. Together with
a "snappy" ruler this would have been a godsend for 7 years already.
But the developers do not want simple users, they want you to create and
use styles.

Or what about trying to do something basic like inserting cut rows in calc?

http://www.openoffice.org/servlets/ReadMsg?listName=users&msgNo=145404
I guess also here the developers do not want to support simple users.
Here you need some three-fingered trick using ctrl-alt whatnot keys.
Usability? Not important.

Sorry about the rant, consider it my mourning process moving away from
OpenOffice.org and back again to Microsoft Office after five years...

I can accept now that "some things never change"

[Mru-o (mru-o)]

*** Issue 113126 has been marked as a duplicate of this issue. ***

[Juanitogan (juanitogan)]

I'm not a developer on this project but it's the little usability things like
this that I fix first on my projects. I'm always looking for shortcuts to make
the users happier. Usually, I put them in before the user even thinks to ask
for it because I test everything. And I test keyboard access as well! (Too
many slackers skip that one these days. Ugh.)

I gave max votes to this long ago even though I personally use styles
extensively and don't have a dieing need for the snap. What's the use of fancy
features if the users hate the basics?

Anyhow, enough ranting. Give me a grant to take a sabbatical from my job and
I'll learn the code and fix this myself (the fix should take not much time at
all -- it's setting everything up to find, test, and submit the update that
would take time since I'm an outsider at the moment working in a completely
different realm of development). [I won't sacrifice my personal time with my
family time to do this so a grant would be necessary. There is no free lunch is
there?]

[Satoshi-hayaki (satoshi-hayaki)]

I myself am also amazed at this not being fixed yet. Just like everyone said:
it's the little things.

Now, if I may ask, why exactly has this been overlooked for so long? Lack of
developers? Lack of interest? Difficult to implement? (I'm actually curious as to
how hard implementing this is).

I'm no programmer, but if I were to attach a patch, would it be accepted
(assuming it's sane and functional)?

[Mailias (mailias)]

I tell everyone to use styles when they write larger documents, but with smaller
documents it often does not make to use styles because it decreases productivity
enormously.

I really do not understand why user needs are so often neglected in favor of
debates on principles. IMHO good software should rather be soft towards the
users and adapt to their needs instead of trying to educate them.

I would even be willing to make a donation if user needs were considered more.
But due to the reluctance of OO developers to improve usability and adapt to
user needs I finally purchased MS Office and I do not regret this decision.
Sorry guys, this attitude does not help to spread OO...

[Dominussuus-n (dominussuus-n)]

Even using styles, the main issue for me is that there's no way (I know of) to
calculate how far a tab stop is. If there's a conversion calculator between
cm/in to tabs then let me know. So, even using styles, one has to pull out
one's calculator and say "okay, I want something to be right aligned two tab
stops from the right margin and there are X tabs to a page and N cm per tab at Z
pt font so I need to set the right stop to (n*x - 2*n) cm which works out to..."
like, seriously, I've had to do this.

What's worse, the ruler in OO.org/LO **marks tab intervals** so the program
basically taunts you when you try to align your margin or stop to it (and
conveniently disappears if you go too far past it). So, my point is that the
styles 'workaround' wouldn't work even if I tried to make it.

Parting thought: people think in relative points "X Qs to the right from this
and Y Qs above something else." Computers think in absolutes of "X Qs from
(0,0), which is located at the top left-hand corner of the bounding frame." All
positioning in OO.org/LO is calculated from the page origin, which is located at
the top left-hand corner of the page. Therefore, OO.org/LO is designed for
computer typists and not humans!

[ariel cornejo (arielco)]

Upstream bug report:
Bug 24070 - Items on ruler (i.e. tab stops, paragraph indent, table borders) should snap.
http://openoffice.org/bugzilla/show_bug.cgi?id=24070

[penalvch (penalvch)]

ariel cornejo, good catch on bringing this bug back from the dead! :D Confirmed in LibreOffice.

lsb_release -rd
Description: Ubuntu 11.04
Release: 11.04

apt-cache policy libreoffice-writer
libreoffice-writer:
  Installed: 1:3.3.2-1ubuntu5
  Candidate: 1:3.3.2-1ubuntu5
  Version table:
 *** 1:3.3.2-1ubuntu5 0
        500 http://us.archive.ubuntu.com/ubuntu/ natty-updates/main i386 Packages
        100 /var/lib/dpkg/status
     1:3.3.2-1ubuntu4 0
        500 http://us.archive.ubuntu.com/ubuntu/ natty/main i386 Packages

[Adolfo Jayme Barrientos (fitojb)]

Maybe we need to report this also in LibreOffice bug tracker? The linked OOo bug dates from 2004.

[penalvch (penalvch)]

Downstream bug may be found at:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/370034

OOo bug may be found at:
http://openoffice.org/bugzilla/show_bug.cgi?id=24070

1) lsb_release -rd
Description: Ubuntu 11.04
Release: 11.04

2) apt-cache policy libreoffice-writer
libreoffice-writer:
  Installed: 1:3.3.2-1ubuntu5
  Candidate: 1:3.3.2-1ubuntu5
  Version table:
 *** 1:3.3.2-1ubuntu5 0
        500 http://us.archive.ubuntu.com/ubuntu/ natty-updates/main i386 Packages
        100 /var/lib/dpkg/status
     1:3.3.2-1ubuntu4 0
        500 http://us.archive.ubuntu.com/ubuntu/ natty/main i386 Packages

3) What is expected to happen is when one clicks the horizontal ruler in effort to set up consistent margins, tab stops, and paragraph indents, it snaps to the markers.

4) What happens instead is they have complete freedom of movement.

WORKAROUND: Click Format -> Paragraph... -> Indent & Spacing tab and choose desired indents.

[Björn Michaelsen (bjoern-michaelsen)]

[This is an automated message.]
There are no new official OpenOffice.org releases in Ubuntu packaging anymore => Won't Fix

If the problem persists, please mark this bug as "also affects project Libreoffice" or "also affects distribution Libreoffice (Ubuntu)" if that has not happened already.

Please leave references to upstream OpenOffice.org bugs in place to allow cross pollination.

[Björn Michaelsen (bjoern-michaelsen)]

[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html

[Sasha-libreoffice (sasha-libreoffice)]

Copy-paste explanation of functionality request:
On the ruler, one can setup tab stops. However, the tab stops are not snapping
at specific intervals like if there was a grid. They are free floating, which
make them difficult to manage and set them at a proper place, specially when
working on a high resolution screen. By default, they should snap, snapping
should be an option that can be enabled/disabled and the interval for the snap
grid should be configurable.

[Hansonjon17 (hansonjon17)]

Issue is confirmed to also affect LibreOffice 3.4.3

Voting for this one to be resolved. Please fix.
Major annoyance but probably a minor fix.

[Vitriol-vitriol (vitriol-vitriol)]

*** Bug 48800 has been marked as a duplicate of this bug. ***

[Emir Yasin Sarı (emir-sari)]

I think this is one of the areas that MS Office switchers would find LO lacking. It is so convenient to be able to set pre-defined indents via the ruler. If no one opposes, setting importance to "MEDIUM".

[Marco Menardi (mmenaz)]

I totally agree, I raised the issue YEARS ago in OOo, founded (with a small donation as a "thank you" and convincing a developer) the implementation of the snap in Koffice, and today, with 4.0 out, I feel really sad that to set visually the margin at 2cm I can't do with drag and drop. Basic UI design principles dictate that "gizmos" must be manipulated in a useful and reasonable way, having the ruler be moved of 1/100 millimetre makes no sense, if I want 1/100 precision I will use the "indent and spacing", for all the rest I must be able to drag the ruler.

[Emir Yasin Sarı (emir-sari)]

I remember, that I could do this in Word 95. It is very basic functionality in fact, and it is sad to see that LO does not have this feature.

[Johnrieley (johnrieley)]

Remarkable that ruler snap-to-grid, such a fundamental, orderly, feature has not been added in years. I appeal for its addition, for ease and purity of formatting

[Emir Yasin Sarı (emir-sari)]

It seems there is some activity on the AOO side about this subject. Hopefully a fix from AOO could be implemented with ease.

[Emir Yasin Sarı (emir-sari)]

Could this be an easy hack?

[Emir Yasin Sarı (emir-sari)]

Okay, now I will try to explain why this is so important for LibreOffice from the point of view of a MS Office switcher. I cannot *comfortably* suggest LO to MS Office users, especially heavy Word users, because first thing they will notice is the lack of this feature. And I know that they will bug about this, because I've had this conversation already several times.

Imagine, you are writing a nice report, something or whatever, it is not important. You want your document to look nice with paragraphs nicely stacked and listed. You have lots of sub-sections on your document, lots of lists, bullets, numberings etc. The first thing you will want to do is arrange these sections, so that one reading your document will understand what is going on there. Eventually you have a ruler, so you will want to use it first. You were already using this ruler for years in MS Word, because it allowed you to arrange document elements with ease and with 0.0 pixel perfection. But when you start to drag the ruler in Writer, you will notice something odd, ruler is not snapping to grids in LO. What?! So you won't be able to arrange items with pre-set length variables, you have to go to Paragraph dialog box, and set each thing manually, - without any or less visual aid. I don't even mention the number of extra clicks to do this.

This is probably one of the biggest usability and UX issues LO (OOo, AOO) ever had. Speaking of novice users, no one will bother to look for the Paragraph dialog box, instead they will get irritated about this and probably they will switch back to MS Office, if they have no sense of FOSS or if they do not have financial concerns.

I hope this will get some attention from the developers' side, because this is really a serious issue, and it is simply unbelievable to see this wasn't addressed in 20 years. At least this could be an Easy Hack. There has been some noise about this on AOO side, it is possible to check with them also.

I hope there is someone with some free time to hack on this. :)

I rest my case...
Best regards,
Emir

[Quikee (quikee)]

Interesting.
I don't think this is very hard to implement and it makes sense. I will look into this.

Regards, Tomaž

[Quikee (quikee)]

Hi,

I managed to implement this for most scenarios. The only problem for now are the tables. I will commit the change without tables today so you can test this in daily build.

Regards, Tomaž

[Emir Yasin Sarı (emir-sari)]

@Tomaz,

Thank you very much, it is a great job in such a short amount of time. I am personally grateful. :)

[Libreoffice-commits (libreoffice-commits)]

Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=98608e57f21820ec1d2c6cd77f433b6963e249a6

fdo#38144 In ruler snap to markers for tab stops, margins, etc.

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.

[Sasha-libreoffice (sasha-libreoffice)]

Thanks for fixing this bug and for improving code. Code becomes now more understandable for me.

[Emir Yasin Sarı (emir-sari)]

@Joel, I've added you to CC, since there are no master builds for OS X right at the moment, could you please test this feature?

Thanks in advance. :)

[Vmiklos-g (vmiklos-g)]

FWIW, Norbert kindly said he'll tweak MacOSX-10.8_21-10.7SDK to upload daily builds for master/-4-1.

[Libreoffice-commits (libreoffice-commits)]

Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bfa3f8584b2f2492f5c0573f22e4ebd96d9a8af5

fdo#38144 Enhance snapping to markers, also snap to frame margins

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.

[Libreoffice-commits (libreoffice-commits)]

Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=fbd059fb60fc0afca20eec7ea26e0ae9beb384e4

fdo#38144 Fix calculation of tick size in snapping to frame margin

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.

[Emir Yasin Sarı (emir-sari)]

Works great. Thank you very much Tomaz for this great functionality once more.

Do you plan to add any more functionality or we can close this thread?

[Quikee (quikee)]

There are some issues left - when you have a table and move any text margin slider, the left and right text margin changes after you finish with dragging. This was working correctly before.

One thing that is not done yet is the ability to get the previous "snapless" behavior when you hold ALT, as this is possible in other word processors.

I would also like to show the new margin value while dragging, so you have even better indication to what value you will change the margins.

[tormen (quickhelp)]

Hi.

Is there any way to also make the colums of tables *snap* ?

Or is there a way assuring a /straight/ table column border when changing the widths of cells (most common use case: after /splitting/ a cell you often want to readjust the width and also often you want it to match the width of an already existing cell above and/or below.

In case my description was not clear, I am referring to this feature:
http://ask.libreoffice.org/en/question/9864/how-to-snap-table-borders-to-grid-when-resizing-table-columnrow/

And would hope this BUG could be the solution.

Thanks for any feedback on this!

Tormen

[tormen (quickhelp)]

Another huge downside of *not* having ruler-snapping for table columns...

...is that without it can very easily happen that you accidentily shift your table column by a mm left or right just because you clicked in the area for other editing purposes.

A ruler snap would only lead to the column width being changed if I really drag the column border FURTHER than any (most) accidental clicks will be able to reach (given a reasonable ruler snap-width).

Knuth (aka Tormen)

[Quikee (quikee)]

Columns of tables already snap to ruler marks.. or should snap. There is currently a bug that makes snapping erratic but I will fix this sooner or later.

[tormen (quickhelp)]

Created attachment 83815
Example-Table_with_non-snapping_table-columns.odt

Hmm...

For me snapping of the table columns isn't remotely working in this example file.

I am using Version 4.0.3.3 (Build ID: 400m0(Build:3))
libreoffice 1:4.0.3-2~bpo70+1 amd64 from debian wheezy backports

Is this version maybe to old for it to work ?

[Emir Yasin Sarı (emir-sari)]

(In reply to comment #25)
> Created attachment 83815 [details]
> Example-Table_with_non-snapping_table-columns.odt
>
> Hmm...
>
> For me snapping of the table columns isn't remotely working in this example
> file.
>
> I am using Version 4.0.3.3 (Build ID: 400m0(Build:3))
> libreoffice 1:4.0.3-2~bpo70+1 amd64 from debian wheezy backports
>
> Is this version maybe to old for it to work ?

This feature is only available in master builds for the moment.

http://dev-builds.libreoffice.org/daily/master/

[julien2412 (serval2412-6)]

Knuth: just to bring some extra info, "target:4.2.0" in "Whiteboard" part means it's fixed on 4.2.0 (see https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Whiteboard#Releases)

[Libreoffice-commits (libreoffice-commits)]

Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8c8b165f54399aa5a4f1c26f29101d4482eb9339

fdo#38144 more stable ruler actions on tables

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.

[Quikee (quikee)]

OK, I think I can close this now. Create a new bug if there are any issues.

[Michael-meeks-1 (michael-meeks-1)]

Great work Tomaz ! :-) thanks so much for implementing that. Any chance of a nice screenshot at:

https://wiki.documentfoundation.org/ReleaseNotes/4.2#Writer