![]() Move the mouse pointer down till the tab has disappears (don't leave the mouse button)Ĥ. Drag to the right so that mouse pointer is outside of the document window, as long as you're vertically inside the ruler the tab will snap to the right marginģ. I think that the behavior for dragging an existing tab is quite forgiving, even for people over 18. You're referring to what happens when you drag a new tab from the well into the ruler while I'm speaking of what happens when you drag an existing tab inside the ruler. It looks like we're speaking of two separate issues. The circle with the + in it disappears once the cursor is moved too far, but getting the cursor back to exactly the point where the circle with + in it reappears is finicky and requires precise non-shaking hand movement which is difficult for elderly people and for those many persons (including me) who have problems with hand-eye coordination. Otherwise the cursor continues to be moved rightwards. With that said, I agree that we could improve our handling of this case and we will think about a solution for this (although I'm not sure it will be in time for 2.9) but I don't think this is "totally wrong" and certainly not a bug.ĭRB wrote:Eyal: the reverse tap sticks to the right margin indicator only if the user is extremely precise in getting the cursor on the line in the ruler. Regarding consistency: Note that TextEdit, Pages and Open Office all exhibit behavior that is closer to what Mellel does (although I couldn't find any two applications that behave the same) The fact that MSWord excludes the '63' from the the line break calculations can also cause it to position the number in a non aligned fashion, in certain circumstances: However, if you do have another tab stop then Word will put the number on the left (unless the word preceding it is wider then the position of the tab stop. So this works nicely when you don't have any other tab stop. In MSWord, on the other hand, the number is excluded from the line width calculation and the line is broken only when there is not enough room to include "title" in which case it will break the lines like this: So the 63 is positioned at the beginning of the line. The difference between Mellel and MSWord here is that Mellel includes the number in the line width for the line break calculation while word doesn'tĪnd assuming there's not enough room to fit the 63 inside the margins then Mellel will break the text like this: I see that if you're not using any other tab stop except the reverse tab then you can get MSWord to do what you want. I’ve been trying Microsoft Word using the same settings, augmenting and reducing the right margin continually around the challenging distances: the limit where the last word from the paragraph rises the end and must continue on the next line, and the page number never was placed at the left -as Mellel oddly does- getting always a solid correct behavior and placing the page number at the right in all cases. To me, this inconsistent and weird behavior (intentional or not) is totally wrong and a bug. Why if I have: left and right justification, and also a right (reverse) tab, the 63 number stays at the left?Īgain, as I said before: it seems that Mellel has problems placing text right aligned when the EOL exceeds just a little bit the line. This way I’m avoiding the 63 number to get placed alone at the left due to this ‘indent tab’ and theorically forcing the 63 number to the next tab (the reverse tab). Ok, now I don't have any ‘indent tab’, leaving the ‘reverse tab’ alone to be as clear as possible. If the title is long enough to actually extend to the next line, like it does in the examples, then then reverse tab will catch.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |