Description: As in the description, typing spaces at the end of a line causes the cursor to go beyond the margins until a non-space character is typed. The spaces are in the document, but can only be seen if a non-space character is typed before and after them. This happens in with both LTR and RTL, no matter what the paragraph justification is set to. This is such a simple, obvious, critical bug, and a massive regression, that I wonder if the problem is somehow localized to my particular setup. I will attach a video demonstrating the problem as well. Steps to Reproduce: 1. Open a new document. 2. Type a line of spaces. Notice that the cursor goes beyond the end of the line. 3. Type a non-space character. Notice that the cursor finally goes to the next line. 4. Type a line of text without spaces. Notice that at the end of the line, the text wraps to the next line. 5. Place the cursor after the last character on the previous line. Start typing spaces. Notice that the cursor goes past the margin. 6. Place the cursor in the middle of the previous line. Press enter. Notice that the spaces typed at the end of the line are in the text. Actual Results: Cursor goes past the end of the margin. Expected Results: Cursor should move to the following line and the spaces should appear. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.5.3.2 (X86_64) / LibreOffice Community Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Created attachment 187503 [details] Demonstrates the problem This video demonstrates the problem. Please note that at the point in the video where I type a line of "a"s and then a line of "b"s and the cursor is at the beginning of the line of "b"s, I am hitting the space bar and nothing is appearing. When I move the cursor back to the end of the previous line, the spaces "appear" beyond the margin on the previous line. My current screen capture program only exports to GIF now. If you have trouble seeing the problem, please try this link: https://watch.screencastify.com/v/mtn5l7CBM16CoysDLmFi
In response to the reference to bug 104668, I tested with "Word-compatible trailing blanks" on and off (it was off by default), which made no difference.
I believe this was done by design as a resolution for bug 104683. Can you please have a look at the comments there?
Repro Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8635c9aa8c6f1078a9e220076d5a08daf30077e8 CPU threads: 8; OS: Mac OS X 12.6.3; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
No issue with Version: 7.2.0.4 / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Hi Stéphane, I read the thread you referred to, and the current behavior of the program does not match the request in that thread. The idea proposed there was to provide a numerical indicator when formatting marks were visible for the number of spaces in *justified* alignment. As far as I can tell, this has not been implemented at all, at least in the current version. First of all, this problem happens in all alignments -- left, center, right, and justified. Second, even when formatting marks are turned on, and the alignment is set to justified, no number ever appears and spaces just go on past the margin forever. I know we're not to supposed to reopen bugs marked as "resolved fixed," but I can't imagine that the person who reported bug 104683 is happy with the current behavior either! :-)
(In reply to Stéphane Guillou (stragu) from comment #3) > I believe this was done by design as a resolution for bug 104683. Can you > please have a look at the comments there? I somehow missed this, lets remove they keywords
Well intention is to mimic word, word does allow spaces beyond margin and off page. Factual the same way as LibreOffice handles it today. However the cursor is placed on the next line in Word, so keeps on page instead of going off page. So more a visual feedback thing, I guess
I can reproduce with William's steps, but that was already the case before 7.5. Telesto, what do you mean by "no issue in 7.2"? In my test, spaces were already added beyond the margin, and also suddenly "jump" to the next line if text was added before in the paragraph. Attila's commit made the cursor visible beyond the margin. William, I think the issue you described and the solution you would prefer match bug 43100 and its comments best (marked as fixed by the same commit.) Like Telesto said, and as I understand it, allowing spaces beyond the margin is in part for compatibility with MS Word, so I'm not sure the behaviour will be changed to match your expected result. Copying UX team and Attila in to confirm. "Won't fix"? Dupe of 43100? Smaller visual improvement like cursor in next line (like suggested by Telesto)?
Created attachment 187519 [details] Screencast (In reply to Stéphane Guillou (stragu) from comment #9) > Telesto, what do you mean by "no issue in 7.2"? In my test, spaces were > already added beyond the margin, and also suddenly "jump" to the next line > if text was added before in the paragraph. Press and hold space key... and the cursor goes far beyond the page... Result is even more strange if you create multi-page document and pressing space at the left page.. The cursor appears to be on the right page (but it's actually on the left)
I think this bug report should be rethinked.. and maybe some smaller feature request could be enought for you.. But it is a complex situation and many ideas could be problem for someone else... because this whole situation is a bit controversiar ... we want to be able to hit more spaces, but we want to see as there would be no spaces there .. some cases we want to be able to move into it.. some cases we don't.. we dont want to break line because of them.. but if you put 1 letter in the middle, then suddenly show the spoaces at next line, and change its behaviour... there was 3 related ticket on bugzilla about this: tdf#43100 tdf#104683 tdf#12071 however... some could say... it is a rare case when someone want to put 10+ space at the end of the line... (even i dont know when/why someone want it, sure some will do, just like i when i tested it :) ) The original problem (what i fixed) was a more common problem, that you was not able to see how many spaces are at the end of the line... because sometimes we mistakenly type 2 spaces. For example at justified case, it does not even show 1 space .. because letters was until the margo... and nothing was displayed after margo... For some peoples, it was a critical bug, as they used 3. party tool, that was made errors if there was extra spaces on the line end... They had to open it in MS word to even check where are the errors... and we don't want to suggest peoples to use MS word just because of this.. :) So it had to be fixed... and it was not so simple to fix.. as the extra spaces was not stored like other spaces.. you can check my gerrit, and see what is SwHolePortion, and i had to make sure the layout will not change by this. Once i diplayed the hidden spaces .. when you tried to delete some.. it was very confusing that the cursor was not worked as in the middle of the line... it moved differently and showed false position .. So i made the cursor to work just like in the middle of the line. Just like MS Word do. i did not handled every special cases.. maybe we should crop cursor position at the page end.. but we could think about columns end.. and other cases like.. when there are a hole portion in the middle of the line... (if there is an image that cut a hole into some lines.. ) maybe the "writing a number in then end of the line" could be good too.. but that is again a complex feature (not so easy to implement).. how to display it, so you will not confuse it with real text?.. where to put, when text is centered? at the margin, or right next to text?.. and what about the cursor... if someone want to cut 4 space to the next line from the 10... should he be able to do it.. or should we say, no.. you will have to delete the 4 from here, and insert the 4 space there... Some peoples even suggested to not have any spaces after the margin, but at justified mode, the spaces at the end of the line, must be after the margin... as letters are paced from left to right margins... the space between the last word of the 1. line, and the first word of the 2. line... must be outside of the margins.. I think this kind of ideas should be designed deeply, and carefully. So in short: I would suggest for you to ask fix only for what annoy you now.. for example to not show cursor after the page end... or crop cursor visible position to the page end... or someting like that... i dont promise to fix that.. as i have other things to do now.. but who knows.. :)
sorry for the typo, the 3. ticket was tdf#120715
Thank you, Attila, for the detailed response. I have never used MS Word in any sustained way (or, for that matter, in any occasional way), so I can't speak to their design choices. In one of the threads I read related to this matter, someone made a general point about how LO shouldn't merely mimic Word when Word's implementation of something is bad. I agree with that point, and if this is indeed how Word handles extra spaces entered at the end of the line, then I think Word's implementation is bad, too. I want to address what you wrote here: "we want to be able to hit more spaces, but we want to see as there would be no spaces there .. some cases we want to be able to move into it.. some cases we don't.. we dont want to break line because of them.. but if you put 1 letter in the middle, then suddenly show the spoaces at next line, and change its behaviour..." My first question is *why* "we want to be able to hit more spaces, but we want to see as there would be no spaces there." Why *not* treat spaces entered at the end of the line exactly as any other text character, wrapping to the next line and inserting spaces just as if someone typed a long string of "a"s or whatever? Until I can understand why anyone would "want to see as there would be no spaces there" I can't really relate to the controversy. The fact that spaces are not shown until a letter is inserted, which "change[s] its behaviour" seems like argument enough that not displaying and treating spaces at the end of lines as regular characters is a poor choice. My simple feature request, then, would be to treat spaces like any other text character, that they wrap to the next line and continue to be inserted at the margin. I hope you or someone else can explain why this solution would be bad or negatively affect use cases that I can't currently think of. Whether or not my suggestion is wrongheaded or naive, I think the current implementation is worse than the old implementation where extra end-of-line spaces would simply move the cursor to the beginning of the next line and not display the added spaces. Beyond the bizarre visual artifact of going beyond the margin -- which, if more spaces are added, continues until the cursor itself is no longer visible, this implementation causes problems in Tables (and, I imagine, multi-column pages) when spaces cause the cursor to appear in the next cell, despite still changing the original cell. The implementation is also problematic because selecting the entire line with spaces that go beyond the margin only visually selects until the margin, even though the extra spaces are selected as well. In addition, try the following steps, which initially drew my attention to this issue: 1. Right justify LTR text. 2. Type spaces at the end of the line (or a line of spaces). 3. Notice that the cursor disappears entirely, rather than going beyond the line. I hope these issues will at least push for a reconsideration of this new implementation, and at best, lead to accepting my suggestion that spaces be treated as ordinary characters.
@Khaled, could this be a Harfbuzz composition issue? What width for a space is used for composing line wrap position a line of text against document/paragraph margins? Tabs are not similarly affected--just strings of <Space> characters. In addition to STR here, instead working in a two-column page, string of spaces pass completely out of the column, over the adjacent column, and off the page--seemingly with no line wrap.
How about keeping the current functionality for centered/justified paragraphs but wrap spaces in case of left/right-aligned? The progressive space as implemented today is easy to understand (assuming non-printable character are visible) and familiar for users coming from other office suits. And it sounds rather easy to add a condition that makes it dependent on the alignment. However, doing so breaks compatibility as MSO always continues right, which was always paramount for us.
(In reply to V Stuart Foote from comment #14) > @Khaled, could this be a Harfbuzz composition issue? What width for a space > is used for composing line wrap position a line of text against > document/paragraph margins? Tabs are not similarly affected--just strings > of <Space> characters. No relation to HarfBuzz here, space is a character like any other character and its glyph takes the advance width specified in the font. The decision to collapse spaces at the end of the line is a higher level decision. As for the issue here, this behavior seem unusual to me. I don’t have MS Office to check, but I tested TextEdit and Pages and both keep the cursor at the end of the line no matter how many spaces as entered. I think a survey of how different text editors and office suites handle this situation might be in order, but I can’t imagine the cursor going infinitely into the margin is something common.
Breaking the white space has no value; the hanging indent should be done via paragraph attribute.
Sorry, clearly not a Harfbuzz issue--spaces are stamped correctly between actual text. Whole question is interesting in that MS Word apparently had (through Word 2010, and still supported for .doc binary formats) a '"Wrap trailing spaces to the next line" (for compatibility with WordPerfect)'. Also referred to a Word6 handling. But there is no apparent functional use for the spaces extending beyond the paragraph/page margin, and MS Word user forums advise to use a <Shift>+<Enter> to insert a line break. Smells like DF to me--MS's "solution". Why are we following MS's lead here for handling excess spaces? Seems we really should be breaking lines at paragraph/object margins--wrap like other sane word processors and text editors (including MS Notepad). MS Word user forums suggest: 'Select' the full line of text (including all over the edge spaces), and 'Center' it (with <Ctl>+E shorcut) to delete all extra spaces, then still selected 'Align it' where preferred. Unfortunately, in LO Writer the centering action does not remove the extra spaces in similar fashion. @Attila, truncate on centering might be useful if we continue with parity in function.
Thank you everyone for the engagement around this issue. I agree with V. Stuart Foote's comment #18: "we really should be breaking lines at paragraph/object margins--wrap like other sane word processors and text editors." As for what should be done with the "extra" spaces: 1) I tend to oppose imposing unnecessary limitations on users, even if I can't imagine any use case for manually inserted spaces at the end/beginning of lines. My preference would be to treat spaces at the end of a line like any other character, wrapping them and displaying them on the next line. 2) If this is a problem, then second best would be to ignore the attempt to insert spaces at the end/beginning of lines, and to truncate such spaces automatically when importing Word documents (or to offer a compatibility option to delete or retain them, but *not* display them, as was the behavior prior to LO 7.5). 3) Alternatively, in the interest of maximizing user flexibility/customization, a checkbox could be added somewhere under Tools | Options | LibreOffice Writer: "Allow trailing/leading spaces" -- when checked, spaces would be treated as regular characters, wrapped at the end of lines, and displayed normally (as I suggested in 1 above); when unchecked, no trailing/leading spaces would be permitted, and pressing space at the end or beginning of a line would have no effect (as I suggested in 2 above). 4) Regarding the issues caused by such spaces with centered/justified alignments, I would advocate for a checkbox somewhere under Tools | Options | LibreOffice Writer: "Truncate trailing spaces in center/justified alignments."
About following MS... i only made visible the spaces after line end (over margin), and made the cursor visible there too. Those spaces was already there, and the user was able to navigate there, but it was confusing why the cursor seems not to move sometimes.. like in tdf#120715 where the cursor moved between spaces.. peoples still tohught it stucked. And i was very careful with layout... if we start to interpret the spaces over the end of line differently... like droppoing them to new line... many old document may change.. some 1 page long forms may become 2 page long.. we can make a compat flag to have 2 different behaviour.. but then it may become too confusing, when spaces goes to new line, and when not... If we trucate the spaces we probably break already made documents... (dont forget.. users may used this unintentionally.. if he made his doc looks good with this 'error' if we fix it, he will only see that we broke his doc... ) If we "offer a compatibility option to retain them, but *not* display them" then we resurrect the original bug reports, as we wont be able to see it. If we think so complex resolutions then it still easyer to make an option, to display spaces/cursor this way, or the previous way... because the document, and the layout would be the same.. only the visibility of cursor, and extra spaces would be changed Sorry about the confusion with the cursor movement... i was mistakenly believed that wont be a big problem, and if a user put more spaces after end of line, then in most case it is a mistake... But i did not checked tables.. and it can be easyly annoying.. I dont want to advertise MS office.. but i think they made this thing very well... the only difference i see with actual LO is that MS does not display spaces/cursor when it is over some logical boundary... I mean after page end, it does not display the cursor.. (the cursor wont be visible) In table it diplay sapces/cursor only in the cell.. but sure you can put more spaces, and move the cursor out from the cell.. you just wont see the extra spaces/cursor... If there is an image over the text.. i mean the text is around the image... then the spaces/cursor displayed only until the image... you can put more spaces and run throught the image... but you wont see that. And at MS the selection is displayed even over the margin.. at LO you can select those spaces, it just dont display the selection. If i will have some spare time i can check if i could hide cursor in some of these cases, but there may be a lot of special cases i didnt even thought about... i'm not sure if i could find them easily... if anyone want, feel free to do it.. :) Or we may could revert the cursor movement fix, and leave only the extra space display... you wont be able to move cursor into wrong places... but cursor movement will be confusing.. even more as it was long before... because now you would see the spaces, but you wont be able to click into it.. :)
As this has moved into the UX-advise arena, I would move to truncate the excessive spaces aggressively. - Any new document would have sane line wrap and paragraph/page/cell margin. - Any existing document would add additional lines--easily corrected by Find-Replace actions and application of style. Perpetuating the odd MS Word handling using <space> characters for layout and formatting is simply not supportable given LO preference for style based layouts over DF. At a minimum--implement the same "truncate surrounding whitespace for line" on *Center* that MS provides to efficiently remove the excess space padding.
I very much appreciate Attila's detailed analysis and especially his concern with breaking older docs. I certainly agree that existing users should not be penalized for having made docs that worked with existing quirks/bugs. At the same time, that's a recipe for stagnation. Compatibility flags/options may be the only way to balance stability/backwards compatibility with innovation and progress. As for the concern that "If we "offer a compatibility option to retain them, but *not* display them" then we resurrect the original bug reports, as we wont be able to see it" -- couldn't they only be made visible with "Formatting Marks" enabled? BTW, with the current implementation, even with "Formatting Marks" enabled, you can no longer see extra spaces (in the form of vertically-centered blue dots) beyond the right hand *page* (not margin) boundary, even though the cursor goes into the gray area beyond the page boundary. More than that -- you can't click the cursor onto spaces that go into the gray area. Clicking on the gray area on a line that has spaces going into the gray area beyond the page boundary puts the cursor at the boundary of the page; you can then press the right arrow or end to get to the end of the spaces. And, as Attila points out, "And at MS the selection is displayed even over the margin.. at LO you can select those spaces, it just dont display the selection." This is yet another problem with the current implementation. Selection should show exactly which characters have been selected so that the user will know what is being affected with the next edit. Upon reflection, it seems that there are really two issues here, which are separable but intimately connected: 1) One is the layout issue -- how are trailing/leading spaces actually treated: do they wrap to the next line, do they extend infinitely, or are they disallowed/truncated? The second is the cursor movement issue, which only shows up if trailing spaces are allowed to extend infinitely. In terms of the layout issue, extending infinitely seems to me the absolute worst possible choice of the three (so of course MS Word went with that option! :-) ), and I think it is deserving of serious reevaluation. 2) The second is the cursor movement issue, which of course only appears if trailing spaces are allowed to extend infinitely. The guiding principles, to my mind, should be: A) the cursor should never disappear, as it now does if you right justify a line and type LTR spaces past the left margin -- try it with Formatting Marks on, the spaces suddenly shift to the right and disappear off the right end of the page! B) you should always be able to click to place the cursor in existing text. You can't right now, because if spaces extend into the gray area beyond a page border, you can't click there. This also addresses Attila's concern that "we may could revert the cursor movement fix, and leave only the extra space display... you wont be able to move cursor into wrong places... but cursor movement will be confusing.. even more as it was long before... because now you would see the spaces, but you wont be able to click into it" -- you already can't fully click into it in the current implementation! C) if selecting text, *all* of the text to be affected should be highlighted (currently not the case, because spaces beyond the page *margin* are not highlighted). In the immediate term, I would vote to revert the new cursor implementation, which in my experience causes more problems than it solves. In the longer term (which I hesitate to say, since in LO terms that has meant and could mean decades!), I think a full re-evaluation of how trailing/leading spaces are handled is in order.
justified alignment means text are from left margin to right margin... so, spaces after last letter MUST be on the margin. dropping spaces to new line wont help here.. only if we break the justified alignment.. but i bet we dont want to do that... justified alignment is a commonly used good feature. (justified is not the only problem, but seemed easy to explain) If we accept spaces on margin.. we can choose to A) hide all those spaces.. B) try to show all spaces C) try to show some spaces.. and maybe have some tricks A) all spaces was hidden before my commit... pro: there was nothing to argue about, if the space/cursor is over the margin or the page, or cell border... con: we dont have a chance to find extra spaces if that is a problem.. + cursor movement problems B) showing all spaces is impossible normally .. if i insert 1 million spaces.. ?! ... would we make a scrollbar 10000 times wider as the page itself?! :) C) showing some spaces is what i tried to achieve... pro: we can see some extra spaces, and may move on them ... practically we can eliminate A) con part for a limited amount of spaces... in default case it is about 20 space con: after the limited amount of spaces it will have some problems... based on what we do after it.. i did not do much after it .. because: 1) That was the fastest way :) (doing nothing :) ) However i handled a few special cases i found.. like if you put an image into the text... i made sure the cursor wont be displayed under/after the image 2) naively i thought having ~100 meaningless spaces is a so rare case, that we could accept that is a bit ugly , and suggest to delete some of them.. :) 3) There is many special cases that should be handled, and i dont even know every case... if you found 1 and report it.. someone may fix that case.. But dont forget.. we can mix A) and C) in different cases.... or based on an option.. like a toggle button to show spaces or not... or whatever... I think we should rather analyze the special cases where and what is the problem.. and set the limitation based on that... For example .. i thought having cursor + extra spaces go from margin only untill the page end .. would be better... then it would be like A) with a bit of extension.. that is will work for like 20 spaces better it is good that someone mentioned that in tables it is a bigger problem.. we should fix it... we could disable this behaviour there.. and fallback to A) case... i think Or if someone would find a common solution.. where not to display or move the cursor.. / display the spaces... but im not sure if we could find a common solution.. Selection is just an other special case i did not fixed because of 1) .. :) but if i have to fix all related problems while i fix a bug... then i wont be able to fix any complex problems. :)
(In reply to V Stuart Foote from comment #21) > - Any new document would have sane line wrap... What justifies a line break per space? IMO, there is no good reason to indent a single line and to make a text processor work like ASCII editor (however, you can by using tabs). Spaces have to be added to the line end - and need to be shown for proper feedback. (In reply to Attila Szűcs from comment #23) > C) try to show some spaces.. and maybe have some tricks Nothing to say against smarter solutions, eg. showing "ellipsis" as long as more than three spaces are at the line end (not really smart as deleting a space has no good feedback then). The point is: how many users will add multiple spaces at the line end wondering where the cursor goes? Maybe we should just accept and resolve the report as NAB.
(In reply to Heiko Tietze from comment #24) > (In reply to V Stuart Foote from comment #21) > > - Any new document would have sane line wrap... > What justifies a line break per space? > > IMO, there is no good reason to indent a single line and to make a text > processor work like ASCII editor (however, you can by using tabs). Spaces > have to be added to the line end - and need to be shown for proper feedback. > What? A space is a valid legitimate character that has a known (per font) advance assigned (comment 16)--it is text! I am asking it be treated as text--not a half baked formatting tool. We allow no other text to extend beyond margins--for what *purpose* do we allow this text to extend "dangling" outside a paragraph or cell without wrap?
(In reply to V Stuart Foote from comment #25) > ...for what *purpose* do we allow this text to extend "dangling" outside a paragraph... We follow the example of Microsoft blocking the abuse of spaces to indent the line, I guess. Can you answer the question what purpose multiple spaces have? (I mean it in a positive sense, both views might be valid.)
(In reply to V Stuart Foote from comment #25) > (In reply to Heiko Tietze from comment #24) > > (In reply to V Stuart Foote from comment #21) > > > - Any new document would have sane line wrap... > > What justifies a line break per space? > > > > IMO, there is no good reason to indent a single line and to make a text > > processor work like ASCII editor (however, you can by using tabs). Spaces > > have to be added to the line end - and need to be shown for proper feedback. > > > > What? A space is a valid legitimate character that has a known (per font) > advance assigned (comment 16)--it is text! I am asking it be treated as > text--not a half baked formatting tool. We allow no other text to extend > beyond margins--for what *purpose* do we allow this text to extend > "dangling" outside a paragraph or cell without wrap? i just answered this at comment 23: "justified alignment means text are from left margin to right margin... so, spaces after last letter MUST be on the margin." That means, every editor that support 'justified alignment' must allow spaces on margins. we can only decide to hide them (if they are ugly) or show them. (if someone would want to see what is between the 2 word.) Im not sure where peoples would use it if they are not mistakenly write multiple spaces, and not trying to indent... maybe some peoples want bigger gap between some words, and put 2 spaces... and if he write some text before it, then the 2 space move to the end of the line... ?! .. i dont know.. but to type 20-100 spaces ?
(In reply to Heiko Tietze from comment #26) > (In reply to V Stuart Foote from comment #25) > > ...for what *purpose* do we allow this text to extend "dangling" outside a paragraph... > We follow the example of Microsoft blocking the abuse of spaces to indent > the line, I guess. Can you answer the question what purpose multiple spaces > have? > > (I mean it in a positive sense, both views might be valid.) Well, none really--and why they should be *easily truncated* (i.e. MS's centering behavior) to facilitate other means of object alignment. But *when present*, they should behave like any other "printing" character for the font in use--wrap at margins. And this of course is not just the U+0020 instance. Rather that all Unicode whitespace within text spans be handled the same. E.g. a run of U+0020 and a run of U+00A0 should get the same handling--wrap at margins. They don't currently. Not to be confused with handling on document canvas of NPC--e.g. the zerowidth joiners, RTL/LTR marks, or the Pilcrow paragraph markers that can extend beyond margins.
(In reply to Attila Szűcs from comment #27) > > i just answered this at comment 23: > > "justified alignment means text are from left margin to right margin... so, > spaces after last letter MUST be on the margin." > > That means, every editor that support 'justified alignment' must allow > spaces on margins. > > we can only decide to hide them (if they are ugly) or show them. (if someone > would want to see what is between the 2 word.) > Agree, but that would be just one (1) space of the line of text. The rest *should* wrap to the start of the following line (or better simply be truncated)--allow the paragraph margins l/r to control the width of the justified text and apply appropriate spacing. A one off case of an intentional single line "paragraph" would need to honor the document's page margins--truncate or wrap. Otherwise paragraphs are multi-line by nature.
(In reply to V Stuart Foote from comment #29) > Agree, but that would be just one (1) space of the line of text. The rest > *should* wrap to the start of the following line (or better simply be > truncated)--allow the paragraph margins l/r to control the width of the > justified text and apply appropriate spacing. > > A one off case of an intentional single line "paragraph" would need to honor > the document's page margins--truncate or wrap. Otherwise paragraphs are > multi-line by nature. not just 1 space, all spaces... justified means, the line ends with a letter, and the next line start with a letter... all spaces between them must be on margins.. we could truncate, but i would afraid to modify the document automatically .. maybe if it could be optionally chooseable. If someone put 2 spaces between 2 word... then type 1 line text before that... and later he sees the 2 space become 1 space... he will say it is a huge regression... And we should start explaining that while he typed, the 2 spaces was moved to the line end, and then truncated.. and when moved forwad, it remained 1 space. (and sure there could be a lot other problematic situations...) But i agree... if the user specifically choose to do it, it could be a useful command to clear the meaningless spaces.
Created attachment 187620 [details] silly FODT showing issue Add one extra space to this one line paragraph of justified text. Watch what happens to the edit cursor.
(In reply to V Stuart Foote from comment #31) > Created attachment 187620 [details] > silly FODT showing issue > > Add one extra space to this one line paragraph of justified text. Watch what > happens to the edit cursor. Sorry, one sentence (already two lines). Point is the behavior is wrong! The text span of spaces should wrap, justified or not.
(In reply to Attila Szűcs from comment #30) > >... justified means, the line ends with a > letter, and the next line start with a letter... all spaces between them > must be on margins.. Unfortunately not clear that is a viable definition of justified paragraphs. Especially as the other "alignments" provide empty space before or after the start of lines. The extra printing whitespace (e.g. U+0020, or the U+2000 - U+200A block) needs to be accommodated in some fashion. Truncation, compression, or wrap. Allowing it to extend off document canvas, and worse taking the edit cursor with it is just not acceptable.
(In reply to V Stuart Foote from comment #31) > Created attachment 187620 [details] > silly FODT showing issue > > Add one extra space to this one line paragraph of justified text. Watch what > happens to the edit cursor. There is nothing wrong with spaces, or alignment here... this strange behaviour is because the 'i' become 'I' ... and that is bigger then i.. so it does not fit in the 1. line, it goes to the 2. line. and the last line of justified text behave differently but that is again a special case, that have its logic.
(In reply to Attila Szűcs from comment #34) > (In reply to V Stuart Foote from comment #31) > > Created attachment 187620 [details] > > silly FODT showing issue > > > > Add one extra space to this one line paragraph of justified text. Watch what > > happens to the edit cursor. > > There is nothing wrong with spaces, or alignment here... > this strange behaviour is because the 'i' become 'I' ... and that is bigger > then i.. so it does not fit in the 1. line, it goes to the 2. line. > > and the last line of justified text behave differently but that is again a > special case, that have its logic. Sorry, should have been clear. Place your cursor into the run of spaces and add another space. I'll attach a screen capture.
Created attachment 187624 [details] animated GIF of issue, edit cursor way off canvas
(In reply to V Stuart Foote from comment #33) > Unfortunately not clear that is a viable definition of justified paragraphs. > Especially as the other "alignments" provide empty space before or after the > start of lines. > > The extra printing whitespace (e.g. U+0020, or the U+2000 - U+200A block) > needs to be accommodated in some fashion. Truncation, compression, or wrap. > Allowing it to extend off document canvas, and worse taking the edit cursor > with it is just not acceptable. All other text editor i seen behaved the same about justified alignment... Not because they want to be similart to any other alignment... but because its usecase want this... like in news paper.. where they want the text to be placed from margin to margin... even if there is 4 column on the page... and the lines are really short... they use it to make sure the text start and end perfectly at the same position. I think that is the same reason why the last line of a justified text is behave differently.. because the common usecase want that... it would be ugly if only two small word would be there separated by a huge gap. We dont have to allow cursor to run off from the page.. that is not a feature.. that is a side effect that may should be limited... but the limitation is not implemented.
(In reply to V Stuart Foote from comment #35) > Sorry, should have been clear. Place your cursor into the run of spaces and > add another space. I'll attach a screen capture. We already mentioned that the cursor is a different story.. if it is ugly to have the cursor off the page, we could find other tricks to make is better... But that does not require any document changing things.. it is just a visual effect, what you see only while editing the text..
The only really important thing is that tha seenable (printed) text.. i was very careful to not harm the layout.. all other things like, how spaces / cursor is displayed, is just a design question.. i implemented this, because it was easy to do so, and in most case it works the same way as in the middle of the line ...
Point is that *no* multi-line paragraph would ever begin or end in a run of <spaces>, only some misguided effort to directly format using spaces. I've no issue with a 3 or 5 character DF fixed indent, but I personally would not then attempt to justify that DF line. As LO is a WYSIWYG editor we have not obligation to retain the spaces--if anything we are obliged to truncate--bcz they remain in the ODF bloating the character count (just like MS Word). They occupy space, they respond to edit cursor, imagine they extend any size calculation of paragraph/page width requiring crop. There is something there--there should not be. Unlike a line editor, we deal with paragraphs--and should treat the printing spaces like the characters they are--ALWAYS. Force them to wrap, only exception if the paragraph style or DF is made "justified" and then I'd truncate a run of spaces down to 2 (to allow word wrap, eventual justification, and two spaces between sentences). Visual action provides immediate visual feedback on the content, and user could revert if they don't like the trend. As is we are mixing format with multiple <space> content the text spans. There is no need to maintain the multiple space characters on the LO document canvas. It is counter to style usage and use of multiple spaces are questionable DF when we have alternatives there as well.
(In reply to V Stuart Foote from comment #40) I may misunderstand you... but the way we justify the text is not an attempt from us, but rather a standard .. it is used everywhere for many years, and peoples used to it. If we start to alter from standards in layouting ... i would prepare a ton of annoyed peoples complaining about regressions... interopability problems, and so and so... If we just truncate meaningless spaces, we will get less complains.. Because the layout may not change at that time.. but later the layout can change. you should prepare for reports like this: I typed 'A' then deleted.. and the layout not as it was.. ?! I printed like 100pieces when i realyzed they are bad... you may try to explain to him that his 2-3 space moved to line end, there it truncated, and then when came back it remained 1 space.. so layout changed.... but they will not care.. they will say.. it shoud not happen... if i type a letter and delete back... it should be the same! Or if you delete every 2 spaces.. many peoples will complain about... why i can't put 2 spaces between 2 word? i used to do that... and now i can't... This is only 2 example that i suddenly thinked about.. but be prepared for a lot more, some much more complex... and their problem wont be simple visual effect... but problem in printed versions... If my commit with the wrong cursor is annoy you so much that you think it cant be patched to be OK ... then go ahead and revert it.. i dont care.. (however some peoples may will complain to you) but please, do not try to alter layouting with just some logic reasons... it can potentially do a lot of harm to a lot of users... who used to this layouting in the past 10+ years... you should think about all of them, you should check many special cases, and make sure to do minimal problems for them. for exampole think about peoples who just changed from MS word, but somewhy they are forced to import/export docx files.. and have to send their docs to peoples with MS word ...
Sorry, not intending to be difficult. And, I agree that we do reasonable things with the handling of justified lines of text, i.e. to start and end at the margins with a character--I didn't mean to imply that handling needed to change. It is more just a question of what to do with the *excess* spaces when justification is applied. Keeping them hanging around beyond the page/paragraph margin, where the cursor can get lost, simply suggests an obvious action to either truncate or wrap. Otherwise when alignment is not justified, as DF or paragraph style, then it would be a simple and consistent action for the spaces to wrap by default. But also, establish an option to globally truncate 3 or more spaces--and selectively apply [M] [T] Autocorrect table action. In general multiple spaces are never a helpful occurrence and should be pruned. @Justin, what is your take on this?
Not my area. Nothing of value to add.
Created attachment 187634 [details] Document showing another cursor problem The attached document suffers from another problem with cursor placement. 1. Set the alignment to "right." 2. Type a character. 3. Press space. 4. The cursor is now beyond the right margin. If you show formatting marks, you will see the space is beyond the right margin. Why? I cannot reproduce this using a new document, however. If this issue is unrelated to our current discussion, I will file a new bug report.
(In reply to William Friedman from comment #44) > Created attachment 187634 [details] > Document showing another cursor problem > > The attached document suffers from another problem with cursor placement. > > 1. Set the alignment to "right." > 2. Type a character. > 3. Press space. > 4. The cursor is now beyond the right margin. If you show formatting marks, > you will see the space is beyond the right margin. Why? > > I cannot reproduce this using a new document, however. > > If this issue is unrelated to our current discussion, I will file a new bug > report. The question what you call bug here? The layout, or the displayed spaces, or the cursor? The layout / visible space was there even before my commit, i just tested it with 7.0.0.0 alpha... My commit only allowed the cursor to be displayed in its real position... if you chek it, you could move the cursor into the spaces.. it just not displayed as if in the spaces Important note: I dont know why new document, have different layout as the old document.. BUT i suppose it for compatibility reasons... maybe long ago it was different, and now we dont want to break their documents. Anyway i burned too much time on explaining this ticket... I already said why it is like this, what makes it complex, what options i see to make it better, and what changes could be dangerous in my opinion.
Not visible text cursor and search selection are definitely regressions. It's possible to revert the cursor moving part of the original fix for the broken layout problem. Other option is to improve it, showing the cursor only on the page. Likely it's worth to check this in DTP software, too. It's possible, that they are more sensible for double spaces, completely forbidding cursor movement on them (document editors, e.g. OpenOffice.org always moved the cursor position, only that was not visible before fixing Bug 104683). @William at all: thanks for the bug report and comments!
*** Bug 155935 has been marked as a duplicate of this bug. ***
The topic was on the agenda of the design meeting. To summarize the comments: + we mimic MS Word that also allows spaces beyond margin + it's a controversial situation (which was the ticket) and the use case is quite dubious (OTOH treating spaces as any other character makes sense too) + many other applications keep the cursor at the line end + MS Word had in the past an option to wrap or not Putting all together it sounds reasonable to add an option under Tools > Writer > Compatibility and let the user decide whether spaces at the line end wrap or not. Enabling the option breaks the layout for old documents and the compatibility with MS Word but should be easy to switch on/off.
(In reply to Heiko Tietze from comment #48) > Putting all together it sounds reasonable to add an option under Tools > > Writer > Compatibility and let the user decide whether spaces at the line > end wrap or not. Enabling the option breaks the layout for old documents and > the compatibility with MS Word but should be easy to switch on/off. I applaud this decision. However, I want to raise a few questions: 1) As Attila pointed out, there are two separable (but related) issues here -- the actual underlying treatment of spaces, and the *display of the cursor* when spaces do not wrap. This decision treats the first but not the second. Will the cursor behavior remain the same (going off into infinity, not displaying the full range of selected text, etc.) if spaces do not wrap (i.e., if the current underlying behavior does not change)? Although this will not affect me personally, since I will set spaces to wrap, the cursor issue in the non-wrapping spaces mode will in my opinion remain a bug, as Laszlo pointed out in comment #46. 2) How will treating spaces as ordinary characters affect center/full justification (which was one of Attila's concerns)? 3) Would it also be possible the implement an *option* to trim spaces, as V Stuart Foote advocated for in comment 21 and as I suggested in comment 19? This could be implemented under the same Tools > Writer > Compatibility tab, e.g.: Treatment of Leading/Trailing Spaces [ ] Allow but do not wrap leading/trailing spaces (Compatible with MS Word) [ ] Wrap leading/trailing spaces [ ] Trim leading/trailing Spaces [ ] always [ ] In center/justified alignments only The tricky part is that if "trim trailing/leading spaces" is selected and "in center/justified alignments only" is also selected, then either wrap or do not wrap would also need to be allowable options to control what happens to leading/trailing spaces in left/right justification. Thank you again for addressing this issue!
(In reply to William Friedman from comment #49) > However, I want to raise a few questions: I suggest to keep it simple. One option to have a different behavior, and keep the current otherwise. > 2) How will treating spaces as ordinary characters affect center/full > justification (which was one of Attila's concerns)? If the new option is enabled, I'd wrap the line independently from the alignment.
(In reply to Heiko Tietze from comment #50) > (In reply to William Friedman from comment #49) > > However, I want to raise a few questions: > I suggest to keep it simple. One option to have a different behavior, and > keep the current otherwise. It seems clear that the current *cursor* behavior is minimally undesirable (e.g., cursor looking like it's in an adjacent column or table cell) and maximally actually buggy, per Laszlo's comment #46. I guess users who select that option can report it in the future, though I suspect that they will be confused to find this bug report on their exact problem and be told that it was fixed, only to find out that a different but related bug/enhancement was dealt with instead! :-) > > > 2) How will treating spaces as ordinary characters affect center/full > > justification (which was one of Attila's concerns)? > If the new option is enabled, I'd wrap the line independently from the > alignment. Is the idea that trailing spaces will be ignored in center/justification alignment and just wrapped to the next line (instead of being trimmed as per current MS Word behavior)? Or will they be treated as regular text characters for the purposes of center/justification? Either way, I would recommend this be explicitly indicated in the documentation for the new option.
*** Bug 158082 has been marked as a duplicate of this bug. ***
(In reply to William Friedman from comment #0) > 2. Type a line of spaces. Notice that the cursor goes beyond the end of the > line. > > ... > > Actual Results: > Cursor goes past the end of the margin. > > Expected Results: > Cursor should move to the following line and the spaces should appear. Not wrapping spaces is completely, absolutely correct behavior of the program; it is defined in the international standards - most important, UAX #14 Unicode Line Breaking Algorithm [1], which explains this in length. It defines space character's (U+0020) behavior in a class SP, which tells: > ... spaces at the end of a line are ordinarily not measured for fit. If there is > a sequence of space characters, and breaking after any of the space characters > would result in the same visible line, then the line breaking position after the > last space character in the sequence is the locally most optimal one. In other > words, when the last character measured for fit is before the space character, > any number of space characters are kept together invisibly on the previous line > and the first non-space character starts the next line. This behavior is reinforced there in Example 2, which mentions terminal style line breaks (in fixed positions) as non-conformant. Writer implements a standard-compliant, useful, universally adopted in the industry (word processing software) behavior. There is no sign that any sizable user group actually wants the change. Out of 11 CCed people here, most are developers, UX and QA people. I don't see a reason to introduce an option to behave differently to the *word processing* standard. If people need not-a-word-processor behavior from Writer, they obviously use a wrong tool. The discussion got too long. What is the current status of the discussion? [1] https://www.unicode.org/reports/tr14/
(In reply to Mike Kaganski from comment #53) > The discussion got too long. What is the current status of the discussion? Thanks for the reference Mike. Reading Unicode UAX#14, 5.1 line break class SP(XP) seems we are standards compliant. I withdraw my objection in comment 42 and earlier. However, I still would like to see us implement a convenient trim function as enhancement. Perhaps follow the MS "on center" truncation as noted comment 18 [1] https://www.unicode.org/reports/tr14/
(In reply to V Stuart Foote from comment #54) > However, I still would like to see us implement a convenient trim function > as enhancement. Perhaps follow the MS "on center" truncation as noted > comment 18 Implemented in bug 104668; see "Word-compatible trailing blanks" last element under Options->Writer->Compatibility.
> The discussion got too long. What is the current status of the discussion? This bug report involved two different elements which got conflated. My main issue was the cursor display issue, which results in actually buggy behavior (see my comment 22 and Laszlo's confirmation in comment 46) like disappearing cursors and invalid selection areas, and which IMO should be reverted. The question of how the spaces are actually treated is a secondary issue to this bug.
(In reply to Mike Kaganski from comment #55) > (In reply to V Stuart Foote from comment #54) > > However, I still would like to see us implement a convenient trim function > > as enhancement. Perhaps follow the MS "on center" truncation as noted > > comment 18 > > Implemented in bug 104668; see "Word-compatible trailing blanks" last > element under Options->Writer->Compatibility. Hmm, enabled that Writer Compatibility option (undocumented bug 131235) but that doesn't seem to provide this behavior: <snip> MS Word user forums suggest: 'Select' the full line of text (including all over the edge spaces), and 'Center' it (with <Ctl>+E shorcut) to delete all extra spaces, then still selected 'Align it' where preferred. </snip> Unfortunately, in LO Writer the selection and centering action does not remove the extra spaces in similar fashion. Looking at the commit it only looked to affect the space characters of text set RTL.
(In reply to William Friedman from comment #56) > This bug report involved two different elements which got conflated. My main > issue was the cursor display issue, which results in actually buggy behavior > (see my comment 22 and Laszlo's confirmation in comment 46) like > disappearing cursors and invalid selection areas, and which IMO should be > reverted. IMO, instead of the spaces over margins, our usual metaphor for text not fitting to the space - which is a red triangle showing "more content outside of the bounds" - could be used instead. Cf. to a fixed-size table cell / frame, having too much text. However, the cursor would still not move to the next line immediately, since it will walk through every space in the hidden space run. It is IMO the only sane behavior - skipping all the whitespace at once is inconsistent. > The question of how the spaces are actually treated is a secondary > issue to this bug. OK - got confused then by the text in comment 0. But then, are the bugs marked as duplicates actually duplicates?
(In reply to Mike Kaganski from comment #58) > IMO, instead of the spaces over margins, our usual metaphor for text not > fitting to the space - which is a red triangle showing "more content outside > of the bounds" - could be used instead. Cf. to a fixed-size table cell / > frame, having too much text. Or - in this specific case - maybe use a dedicated icon, not a red triangle, but some image resembling ellipsis. This would mean, that on margin, with enabled formatting marks it could look like (| means right page margin; [...] means the new ellipsis icon; ¬ means the existing line break mark): ... text + many trailing spaces | [...] ... text text text text line 2 | ... text line 3 with line break | ¬ ... line 4 - spaces + line break | [...]¬ and the marks would take fixed width, regardless of the number of spaces that were eaten when breaking lines. Note that currently, the marks on margins (like paragraph marks, line break marks in block adjust mode) aren't marked when selecting text. I don't think it's really a problem. But if it's really wanted that they all also change they background, it should be a separate request; the display of cut spaces and cursor travelling is separate from that.
(In reply to V Stuart Foote from comment #57) > Hmm, enabled that Writer Compatibility option (undocumented bug 131235) but > that doesn't seem to provide this behavior: > <snip> > MS Word user forums suggest: 'Select' the full line of text (including all > over the edge spaces), and 'Center' it (with <Ctl>+E shorcut) to delete all > extra spaces, then still selected 'Align it' where preferred. > </snip> Hmm. No, not RTL. But I overlooked the the behavior of actually removing the trailing blanks *of a paragraph*. The quote is wrong in use of word "line": e.g., if in a paragraph you have a multi-space run somewhere in the middle, and this space run is last in its line, then no matter how you select, centering does not change it. And vice versa: if the spaces are last in a paragraph, you don't need any selection - just have cursor inside the paragraph to drop the trailing spaces. I don't think that centering (formatting) should actually change content. If needed, a separate function could be implemented ...
> IMO, instead of the spaces over margins, our usual metaphor for text not > fitting to the space - which is a red triangle showing "more content outside > of the bounds" - could be used instead. Cf. to a fixed-size table cell / > frame, having too much text. I think either this or the solution you offered in comment 59 is superior to the current behavior, and would more closely match the original request in bug 104683. (Which the patch which causes this behavior was intended to solve, but IMO does not.) If it were possible to add a counter as was originally requested there, all the better (see below). > However, the cursor would still not move to the next line immediately, since > it will walk through every space in the hidden space run. It is IMO the only > sane behavior - skipping all the whitespace at once is inconsistent. This is the core issue. Prior to the change resulting from the "fix" to bug 104683, as soon as a space invisibly traverses the margin, the cursor would go to the next line and remain "stuck" there if additional spaces were added until a non-space character was entered. I happen to prefer that, because at least it indicated clearly where the next non-space character would go. I don't think there's a clear "sane" choice in this case, because I think that *every action that changes text should result in some visual indication that text is being changed.* This principle is violated both by: 1) freezing the cursor at the end of the line when pressing the space bar invisibly inserts spaces past the margin, *and* 2) by freezing the cursor at the beginning of the following line when pressing the space bar invisibly adds spaces to the previous line. That is why I think a counter would be superior to a static visual indicator that there is "something" invisible; it would indicate that changes are being made. > > > The question of how the spaces are actually treated is a secondary > > issue to this bug. > OK - got confused then by the text in comment 0. But then, are the bugs > marked as duplicates actually duplicates? You are right that in my "expected results" text I also conflated cursor movement with the internal treatment of spaces. Bug 155935 is a duplicate since it relates only to cursor movement. Bug 158082 requests that spaces move to the next line, which was the second part of my request rejected here, which I suppose is NAB. (But I don't think you're right that the current standard treatment of spaces is particularly desirable, nor that the number of users cc'ed on a bug report reflects anything about the desires of the larger user base. For a complaint about this going back to 2015, which requests a change that violates the standard, see https://bugs.documentfoundation.org/show_bug.cgi?id=43100#c6.)