Seems there are many duplicates for this problem :
Issues 2197, 9485, 19226, 19341, 20512, 20878,...

Issue 2197 seems the first which describes the problem.

Can you confirm it ? And mark them as duplicated ?
My english is not really good.

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

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

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

added keyword Q-PCD

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

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

Just wondering, would this issue benifit from having a higher priority than 3?

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

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

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

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

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

but even though so many people have filed an identical issue, are we any closer
to actually doing something about it?

FL: Suggested for new target "Beta" waiting for p-team approval

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

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

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

Due to missing resources the product team and the development decided to shift
this feature to the next target 'OOo later'. It is unlikely to integrate this
feature in OOo 2.0.
If somebody in the community have the knowledge to help Sun here, please contact
the development and retarget this feature.

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

Please note that invisible spaces in headings may become visible in the table of
contents (TOC) as the line often wraps at another point in the TOC. The reason
for the spaces in the TOC is hard to find because the spaces don´t show in the
heading where they come from even if you choose "Nonprinting Characters On".

I am surprised/disappointed that this issue is not given higher priority. Being
able to see spaces at the end of a line is rather important for proofreading
documents. Regards, Herbert Eppel, www.HETranslation.co.uk

I am completely amazed that this does not have higher priority - it infuriates
me every single time I use OpenOffice to prepare text. I would classify it as a
fundamental breakdown in the WYSIWYG paradigm.

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

version 'current'

keyword added: needhelp

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

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

@ skoorb: get familiar with issue handling guidelines regarding version and
priorities. restoring prio, version.

Before adding this bug to the Translators Wishlist for OOo, I tried to duplicate
the bug behaviour in OOo 2.0 on W2K, and there is an oddity with triple-clicking
marking all the line *but* any spaces at the end of a line, but I can clearly
*see* the spaces.

Tried with odt, rtf and an old Word doc, inside and outside of tables and headings.

I don't know if the text selection oddities when triple-clicking should be
viewed as a part of this bug, or qualify as a new bug.

After some discussing and testing this on the OOo for translators list, we found
that the bug is indeed there after all, but it is only *at the wrapped end of a
wrapped line* that the space disappears.

IMHO, the bug summary should be changed to "Show spaces at wrapped end of a line
in Writer", to avoid confusion and better pinpoint the problem. I believe this
is one reason why nobody addressed or even set this issue to "confirmed" or
"worksforme".

In a table this bug shows as a downright ridiculous breakage of the WYSIWYG
paradigm: after typing past a line wrapping, one can insert as many new spaces
as one likes, none at all show. Hard spaces show the behaviour one might expect
from normal space.

If inserting all those spaces didn't result in a corresponding amount of space
characters being inserted, it might not have mattered (in some senses, although
it would of course be a serious thing in other ways), but it does. Copy-pasting
the portion from the table reveals all those spaces again.

If OOo is used to process tables that are used for importing e. g. proofread
material into some application, the results can be more or less disastrous. This
is not an academic excercise, I and many other translators use such applications
every day to make a living.

I suggest raising this bugs priority as much as possible, it's a serious bug.

Created attachment 32233 [details]
Simple table with test-cases that show this bug

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

The erreur.odt attachement shows a simple line, at the end of which you won't be
able to write a single space.

Created attachment 33679 [details]
Can't add space at the end of line

FL: This issue is a "left over" from last release (OOo 2.0) and has many votes
and duplicates. So I set the target to OOo 3.0 for this usability related issue.

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

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

It looks like this issue has been known for almost five years now (issue 2197).
Can anybody tell me why it hasn't been fixed yet? According to the policy for
priority 3 it should have been fixed long ago.
I would really appreciate if this could be resolved soon, the problem sincerely
annoys me.
Thanks a lot!

set target to OOo 2.x

fl, how about setting the target to OOo 2.0.4?
That would be great! :-)

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

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

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

changing component to "Word Processor"

This is one of the most irritating things about OO Writer. I often create text
in OO then pour it into some other system, or a reformat using a different font
or size, either of which changes where the line wraps occur. Extra spaces where
I don't want extra spaces is a document bug.

I don't believe this is a code bug, but a rather poor design decision by someone
in the past. Somebody had to craft their code to do this. Can we rip this
irritating routine out of the OO source?

Judging by the number of new issues which are a duplicate of this one, there are
a lot of people upset by this. As redi2go said, it is "A fundamental breakdown
in the WYSIWYG paradigm." Thanks.

The 'problem' comes from whitespaces with the xml attribute "text:c" for example
<text:s text:c="484"/> in the attachment #33679 [details].

It seems that when a line is re-wrapped due to spaces added at the end of a
paragraph, they're concatenated with this attribute. But if this value is too
high, it's impossible to remove it and we don't see the spaces we type anymore,
even if there is still much room on the line. I modified the value 484 in the
content.xml of the issue attachment and I was able afterwards to type spaces at
the end of the line (whereas it was impossible before) ! 

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

I found that setting the text:c attribute in content.xml to a very low figure,
such as 0 or 2, fixed the problematic document.  In the problematic paragraphs
that attribute was set to numbers in the 50s or 200s.

The customer of mine who is experiencing this issue has no technical skills
whatsoever, so the likelihood of them being able to fix the problem that has
affected their document without help is zero.  They were completely thrown by
this issue, believing that they couldn't add any further content to the document.

Set target.

hagar_de_lest: Sounds like a different, but related issue. Here the problem
isn't the end of the paragraph, but within the paragraph at every place the line
wraps. You don't even need a <text:s/> tag to trigger it.

mikeymike: I did some experimentation and found exactly what you are referring
to. But it's not the issue or the solution. Even without a <text:s/> tag the
problem exists. I suppose if one knew one wanted no more than singular spaces in
their document, one could create a filter to go through the raw ODT file and
modify context.xml to strip out all the <text:s/> tags, but that's not a
universal solution.

Since ordinary spaces and <text:s/> tags within the content.xml file are being
treated identically by the document display routine in Write, I conclude that
the problem is probably in the display routine. I would guess that the <text:s/>
tags are being converted to spaces before they get to the display routine.

I noticed this bug (which also exists in Thunderbird) within days of 
downloading Writer (within minutes in Thunderbird). I'd be looking at the 
screen at the end of the line and notice that my space wasn't showing so I'd 
hit space a few more times then realize that I need to backspace over the 
excess spaces and I'd have to backspace until part of the last word is deleted 
to see where I am. The excess spaces can be copied to the clipboard and I 
assume they're saved too, so I wouldn't want to just leave them in there when 
they're not needed, but I don't want Writer to _assume_ I don't need the 
spaces. They might be needed when viewing the text with a different font size 
or screen width, when they may appear in the middle of a line. I want them to 
exist if entered and be indicated somehow and I want to know where my cursor is 
if I choose to delete them. 

The question is whether the end-of-line spaces should be indicated by the 
cursor advancing into the margin (what to do when it reaches the end of the 
margin is another issue) or indicated on the following line, where the next non-
space would appear. If they'll be indicated on the following line, then the 
cursor would move backwards, over the spaces, when the non-space is typed, 
which might not look as pretty to some people as margin spaces. 

I think end-of-line spaces should be shown in the margin (outside the body of 
the text). I read that MS Word does that. If there are so many spaces that they 
overflow the margin, then do one of the following: 

1. Widen the screen, adding a horizontal scroll bar if necessary. 

2. Have the cursor stop at the far side of the margin while continuing to 
record additional spaces, as happens before the margin with the current bug.

3. Indicate additional spaces on the following line, where the next non-space 
would appear. When a non-space character is typed, display it at the beginning 
of the line (backspacing over the spaces but remembering the spaces exist).

If View > Nonprinting characters is selected, then a dot should be shown for 
each end-of-line space (currently dots are only shown for mid-line spaces even 
when end of line spaces exist) when the spaces don't exceed margin width. If 
the spaces exceed margin width and method 1 is used (screen widening), then let 
the space-indicating dots appear past the margins when viewing nonprinting 
characters.

If the spaces exceed margin width and method 2 is used (cursor stops) then use 
some notation in the margin to indicate the number of spaces when viewing 
nonprinting characters and when adding or deleting spaces there.

If the spaces exceed margin width and method 3 is used, render the spaces as in 
method 1 or 2 once a non-space character after the end-of-line spaces is 
entered.

Barry - forget it. Nobody will ever do anything about this any way. It was first
raised in 2003. I pointed out over two years ago that it was a fundamental
breakdown in WYSIWYG. Since then as far as I can see nobody has done a thing. It
appears in OpenOffice, in Thunderbird, in several Bulletin Boards that I use
that reuse OpenOffice code. You may have noticed it's here in this data entry
box. I hit it several times a day. Every day.

It doesn't need any of your suggestions. What it needs is that when I type a
space, I get a space. Just like any other character. I get a space at the start
of a line, in the middle, and in the end. That's all that's required - treat a
space like any other character.

It's shameful that this bug should still exist after all this time and all these
reports.

redi2go: this bug has been around even longer than that. It was reported in 
issue 2197 ( http://qa.openoffice.org/issues/show_bug.cgi?id=2197 ) on November 
13, 2001. It's almost six years old.

I use Writer for letters, which don't have spaces at the beginning of lines. 
Spaces shouldn't be treated like any other character because that would mean 
that when I type a normal letter to someone, I'd have to look at the screen at 
the end of each line to know when to hit enter so there won't be a space at the 
start of a line. But I'm not sure if you intended for it to work like that when 
you said "treat a space like any other character."

Another way to fix the bug would be to allow up to two spaces at the end of a 
line when the last non-space character is sentence-ending punctuation, and 
subsequent spaces would show on the next line.

Barry - yes I can easily believe it's been around longer than that. I guess it
was an aberration of the original code that's just never had the priority to get
sorted out. I wonder what would have happened if they'd done the same thing to
the letter 's' as they do to space? So every time you tried to write 'impress'
at the end of a  line it started swallowing the 's's. That would have been
regarded as a real bug and certainly been fixed; quite why spaces are treated as
second class citizens I've no idea.

I gather from what you're saying that you lay out your letters by adding a
carriage return at the end of each line? This is not the way to use a word
processor. It is designed for continuous text input - hard carriage returns are
only used to separate paragraphs, not lines. If you are doing this I suggest you
find someone with good experience of using a word processor to introduce you to
the basics. Alternatively, there are lots of texts on the net eg
http://www.compusmart.ab.ca/alummis/beginnerword/index.htm or
http://www.aarp.org/learntech/computers/howto/a2003-07-21-howtousewordprocessor.html
that will explain it.

In the meanwhile, believe me, Microsoft Word does nothing special with spaces at
start or end of line, and works beautifully. As should OpenOffice.

fme->redi2go: Just two comments:

[...] That's all that's required - treat a space like any other character. [...]

Ok, but be prepared that a paragraph in justified alignment does not look the
way you expect it anymore if we treat a space just like any other character...

[...] It's shameful that this bug should still exist after all this time and all
these
reports. [...]

It's all a question of resources and priorities. Do you really think we are
ignoring this because we don't want to fix this? Did it ever came to your mind
that there might be more important bugs to fix / features to implement?

fmc – I am personally not worried about what it looks like in justified
alignment, since if I’m that concerned about layout I generally use InDesign
which has much more comprehensive text formatting capabilities.

However, I was obviously talking in a specific context – that of text entry,
which I doubt many perform in justified mode since the constant text movement is
very disconcerting. Ragged right is the norm, and that is how the default
template starts you off.

When I do choose justification I expect to see spaces disappear at the end of a
line – this is behaviour I have specifically requested after all, and if I don’t
like it I can go back to ragged right and add the justification when I’ve
finished. What I do not expect is for this behaviour to spill over into the
normal case, where it is plainly inappropriate.

‘Do you really think we are ignoring this because we don't want to fix this?’
It’s been a very long time, it would be one logical conclusion. 

‘Did it ever came to your mind that there might be more important bugs to fix /
features to implement?’ That thought had occurred to me, of course, but
personally I’d much prefer that the core worked well than that yet more new
features I’ll never use were added.

‘It's all a question of resources and priorities.’ Hard to disagree with that.
But I fear that it’s a fundamental problem of open source software that
usability gets low priority. This bug for instance has been raised innumerable
times. At a guess I would say every single user of Writer has been irritated by
it at some time. But it will never get priority because there’s a workround
(just back up a few spaces to find out what you’ve written) and because most of
the ‘5% of the functionality’ users like me who would like to see it fixed will
never find their way to the bugfix voting system.

I’ve obviously upset you with my emotive remark. Please forgive me – one howl of
protest every couple of years against something that irritates me every single
day is surely not too excessive? I thought I'd been very restrained :-)

in xml, multiple whitespace characters are treated as one, so there is no way to
have multiple spaces within the Writer document without encoding it with the
text:s with count tags. So if you have a document that behaves like that and
doesn't have that tag, then please add it to this (or another) issue.

And for removing the spaces, you of course don't need to modify the xml files
themselves, just using del or backspace will work as well, same goes for using
search and replace.

To prevent this situation in the first place, you can set the AutoCorrect option
to ignore multiple spaces (this will prevent somebody from falling asleep on the
spacebar, but it will still be possible to add multiple spaces after each other)

cloph: I set AutoCorrect to ignore double spaces (Tools > AutoCorrect > 
Options), but the problem is that even a single space isn't shown when entered 
at the end of a line (the cursor doesn't advance). That AutoCorrect setting had 
no effect. In fact, I can still enter double spaces in the middle of a line and 
they appear in the document, so I'm not sure what that setting does.

fme, from your statements I gather that you're active in the development of OO.
You said:
[[ It's all a question of resources and priorities. Do you really think we are
ignoring this because we don't want to fix this? Did it ever came to your mind
that there might be more important bugs to fix / features to implement? ]]

How did the team come to the conclusion that this was not a significant bug? Why
does the team think that we would rather see new features before we see existing
bugs fixed? Perhaps to the Linux and Solaris communities this is insignificant
because they have no good word processors to compare this against, and on those
platforms OO has no significant competition. This is not the case for Windows or
Macintosh.

Consider an office that has been using Microsoft Office or WordPerfect Office
and they are considering the switch to OpenOffice. It only takes a few early
adopters to run into this bug and similar (and they also exist) and the early
adopters start bad-mouthing OpenOffice. "There's some weird usability thing with
spaces at word-wrap," they might say. Consider many people it takes to say,
"They can't even get the fundamentals right," or, "I hate it," to kill adoption
of OO by the team.

I am committed to OpenOffice (call it idealism), despite the fact that I have a
perfectly usable copy of MS Office sitting on my bookshelf. I have taken the
time to learn OO when I already knew MS Office. And MS Office does everything I
could want, and does it better and more completely than OO. And now you expect
me to put up with some Micky Mouse bug that wastes my time every day?

Every day I fire up OO and use it for something. And every day I run into this
dammed bug. Every day I have to manually check how many spaces I have at the end
of a line, or manually remove an extra space, or go back and put in a space I
thought was already there. Every day, several times a day, THIS BUG WASTES MY TIME!

And now this kind of craptastic word-wrap behavior has found its way into other
open source projects. If they copied it from OO, then you and the rest of the
staff have a heck of a lot to answer for.

fme->scottydm:

[...] Every day I fire up OO and use it for something. And every day I run into this
dammed bug. Every day I have to manually check how many spaces I have at the end
of a line, or manually remove an extra space, or go back and put in a space I
thought was already there. Every day, several times a day, THIS BUG WASTES MY
TIME! [...]

Ok I got the point. This is important. Each and every bug is important to at
least somebody. But actually this does not help. Write a specification. Commit a
patch. DO something. And now please let me get back to my work. Answering this
kind of comments definitely wastes my time!

fme->fl: Do we already have a specification for this?

FL->FME: It is a OOo 3.0 issue anyway, so lets start working on this once the
zoom feature has been finished. Here is my first proposal for the iTeam:
 1. never “eat” spaces at the end of a line
 2. show up to two or three spaces outside the text area, if the text is
justified, right aligned or there is just no space left inside the text area.
 - ensure to give visual feedback in case such a space get deleted (more than
two or three spaces present at the end of a line)
 3. show one space outside the text area, if there is just one space at the end
if the text is justified, right aligned or there is just no space left inside
the text area. 
4. keep general formatting/layout behavior for paragraphs (alignment, line breaks)

@fme, @fl:
 Thank you very much, from many of us users, for starting to do something about
this issue. I don't know if this is the right forum to develop a spec, but here
you surely have an involved audience! :-)

I would like to help with a suggestion that might solve two problems: (a) what
to display when there are more than the two (or three) spaces which will fit
outside the text area; (b) providing user feedback, particularly on Delete
operations.

(a) When there are more spaces than two (or three), display a new glyph instead;
I nominate the "big dot" as somewhat intuitive.
(b) The tricky part: when a Delete operation is aimed at the new glyph, delete
all spaces that can't be displayed. Then the display changes to show the two (or
three) small dots, which behave in normal fashion for further Deletes.
If the text line is shortened within the text area, the new glyph should "bleed"
small dots into the text area, and be converted to small dots if the number of
excess spaces drops far enough.
The above is supposed to be direction-neutral, since this should work L-T-R and
R-T-L. /tj

Thank you!

I don't think we need any special glyphs. They create their own set of challenges.


Current Behavior:

Let's say you're typing a new paragraph. When you're in the middle of a line (or
at least not at the end of the line) you type a word then a space--the space is
visible and the cursor is between the space and the pilcrow. <- (good)

You keep typing so that the last letter typed is at the end of the line (or
perhaps I should say still "within the zone where text goes" and just barely
touching the margin). If you type another letter the word will snap down to the
next line. <- (good) But if you type a space the word stays and the new word
will start down on the next line. <- (also good) However, what the typist sees
in the current rev is that when you type that space it's invisible and the
cursor remains planted at the end of the word, apparently waiting until you type
the first letter of the next word before it snaps down to the next line. <-
(troublesome, counter intuitive behavior) If you continue to type spaces the
cursor stays stuck at the end of the line (and word), the spaces invisible, and
the cursor doesn't snap down to the new line until the typist types the first
letter of the new word. <- (troublesome, no clue as to how many spaces exist)

For a multi-line existing paragraph, none of the spaces at the ends of the lines
(where the word-wrap happens) are visible. <- (troublesome, no clue as to how
many spaces exist)


Proposed Changes in Behavior:

Let's say you're typing a new paragraph. The first part, where you're not yet at
the edge of the text area, remains with the same behavior. Word, space, and
pilcrow, with the cursor between the space and the pilcrow. <- (no change)

You keep typing so that the last letter typed is at the end of the line. If you
type another letter the word will snap down to the next line. <- (no change) But
if you type a space the word stays and the cursor snaps down to the next line,
waiting for the typist to start the next word. <- (new behavior) The space
character should be visible at the end of the previous line even when that means
it's outside the text zone and in the margin. <- (new behavior)

Now if the typist types the first letter of a new word, no problem. The letter
appears in the first position of the new line and the cursor moves over so it's
between the letter and the pilcrow. <- (the change is that the cursor was at the
beginning of the line before typist started the new word)

However, if the typist types a second space, the cursor remains planted at the
beginning of the new line. <- (new behavior) And a second space appears on the
previous line so that both are visible at the end of the previous line. <- (new
behavior) If the typist types dozens more spaces, they will all appear at the
end of the previous line, filling up the margin. <- (new behavior)

However, if you have a bunch of spaces it should not be necessary to show all of
them. With "View/Print Layout" enabled you could show the spaces going to the
edge of the page (and those in the gray become invisible). With "View/Web
Layout" enabled there's a bit more of a problem because the margin outside the
text box is very narrow, so normally only one space may be visible (depending on
font size, etc.). The simplest for "Web Layout" may be to just go with it, if
only one or two spaces are visible, then only one or two are visible. For
"View/Web Layout" if there is some element that controls the width of the text
area then it maybe possible to show dozens of extra spaces, if they exist.

For a multi-line existing paragraph, make the spaces at the ends of the lines
visible. <- (new behavior)


Editing Existing Text:

When there is one space at the end of the line: The back-arrow will take the
cursor to the beginning of the line (before the first letter of the first word
on the line), then another back-arrow will jump up to the end of the previous
line and skip over that last space so the cursor is at the end of the last word
on the line.

When there are multiple spaces at the end of the line: The back-arrow will take
the cursor to the beginning of the line (before the first letter of the first
word on that line), then another back-arrow will jump up to the end of the
previous line so the cursor is before the last space on that line... that is,
with two spaces it will be between the spaces. In some cases this means the
cursor will be in the margin. If the view doesn't let the typist see the spaces
around the cursor then the cursor should be up against the edge of the view-pane
so that it's visible.

It this case where the cursor is between space characters which are in the
margin, it should be possible to insert a character. If the character is a
space, the space is inserted into the margin area. If the character is a letter
or punctuation (any non-space character) then the cursor and the new character
will snap down to the beginning of the next line with the character at the start
of the line followed by the spaces, and with the cursor between the new
character and those spaces.


Selecting Text:

Currently when you select a block of text, the select zone (shown as reverse
video) is from margin to margin--irregardless of the justification used, and
instead of following the boundaries of the actual text selected. I suggest this
be changed to follow the actual selected text to prevent user confusion,
especially with the "dangling" spaces visible--which could very well be outside
the text zone and in the margins. For example when selecting a paragraph, we
want to select the whole paragraph including the spaces at the ends of the lines
(even with multiple spaces there). Going to ragged edges on the select zone is
more intuitive.


Close:

If you'd like, I could dummy up some screen shots, and maybe even create a
little web page if I feel I need more than a few illustrations.

Hmmm...

Let me see if I can translate this into a few simple rules. These rules apply
only for word-wrap and not hard returns (new paragraph) or soft returns
(line-break within a paragraph).

#1a. When the view pane is the same size or larger than the text area, show all
characters unless they fall outside the view pane. In this case always show the
cursor even if it's at the edge of the view pane (make sure it's visible). For
purposes of "Page Layout" the view pane does not include the gray area, which is
not part of the page.

#1b. When the view pane is smaller than the text area, do what you do now: crop
the characters and the cursor as required.

#2a. Except for the pilcrow (see 2b) allow only spaces outside the text zone and
in the margin. -- Note, treat non-breaking spaces as ordinary characters.

#2b. The pilcrow character may intrude one "unit" (it's own width) into the
margin. -- Note, between rule 2a and 2b the cursor could end up in the margin.
When followed by a space this is acceptable. -- Note 2, the intent of rules 2a
and 2b is to define where the cursor may go via the character that follows it,
rather than the cursor itself.

#3. Keep the cursor "glued" to the character that follows it (could be any
character including the pilcrow). -- The effect of this rule is to control when
the cursor snaps down to the next line.

#4. Do not put spaces at the beginning of a line (that is a word-wrapped line).
-- Rather, pile them up at the end of the previous line.

#5. A "word" is a unit of characters delimited by spaces, tabs, hard returns, or
soft returns (either side); or a hyphen, soft hyphen, en-dash, or em-dash
(proceeding the word only). Example: "long-life" is two words, "long-" and
"life". Also "hyphen," can be a word too (with the punctuation attached). A
"word" does not include the spaces, tabs, etc., but will include the hyphen,
soft hyphen, en-dash, and em-dash. -- This is not the same definition used for
counting words. -- Question, do we allow a non-breaking hyphen (a third type of
hyphen)? If so, treat it like an ordinary character.

#6. Do not allow any part of a word to protrude out of the text zone and into
the margins. If it does, snap the word down to the next line.

#7. The soft hyphen should remain collapsed (zero width) unless it is at the end
of a line. If expanding the soft hyphen causes it to protrude into the margin
then snap it and the attached word down to the next line (and re-collapse the
soft hyphen when it "bumps" into its trailing word again).

#8. I can't think of a number 8. Is there anything I missed? -- Maybe define the
behavior when a word is wider than the text area.


Unfortunately, I don't know a lick of Java. I suppose I should learn, in fact I
kinda want to, but I've been struggling to learn this other object-oriented
language. I think years of Verilog have ruined my brain for groking O-O
principles. I'll get there someday. On the bright side, I do get procedural
languages.

I'll do what I can to help.

People working on this should know how MS Word does it. Microsoft might have 
thought of something that we didn't. I don't know exactly how MS Word does it 
so I can't help there.

I haven't read through all of the recent ideas, but this was mine, in case 
people forgot:
http://www.openoffice.org/issues/show_bug.cgi?id=20878#desc52

Two posts later I suggested:

"Another way to fix the bug would be to allow up to two spaces at the end of a 
line when the last non-space character is sentence-ending punctuation, and 
subsequent spaces would show on the next line."

Meaning that if spaces aren't being used as a standard sentence separator then 
the user might want spaces to be visible to the reader even when they're at the 
end of a line, so in that case, show them at the beginning of the next line 
where they'll displace text rather than showing them in the margin where you 
won't notice them.

I haven't used MS Word in over a year... and that was Word 2000. What I remember
is you could pile up spaces in the right-hand margin. Another behavior I
remember about Word that is different than OO Write: When centering text Word
ignores trailing spaces on the line. So you cannot nudge your text to the left
by sticking extra spaces on the right. I prefer Word's handling of centered text.


@ barryii

Your proposal at "#desc52" is similar to mine, except that you "glue" the cursor
to the character that precedes it, while I propose "gluing" the cursor to the
character that follows it. Both have a certain logic and make sense.

In your method when a typist sticks a string of spaces at the end of the line,
the cursor (and presumably the pilcrow that follows it) gets pushed into the
margin, possibly quite far into the margin. From a user interface point-of-view
this will probably work best if you allow the window to scroll sideways so the
typist can always see the cursor in its correct position, relative to the spaces
typed.

In my method I wanted to snap the cursor down to the next line at the first
practical moment, in effect saying to the typist, "Put your text here." If he
continues to tap the space bar the cursor does not advance on the new line, but
spaces pile up in the margin of the previous line. Another message I wanted to
give the typist by this action is, "No matter how many spaces you stick in here,
they are not gonna go at the beginning of the new line." Another thing I was
trying to do with my method is to have a behavior that works without scrolling
sideways to see all those spaces. That is, the user knows there are bunches of
spaces (perhaps they can see only a dozen), but they don't always know exactly
how many.

When the typist has "show nonprinting characters" turned off, your method is
better. When the typist has "show nonprinting characters" turned on, both
methods are equally good.

Not quite, "six of one, half-dozen of the other," because the two methods
provide a different user experience. Perhaps a comparison. The setup: the user
has typed a word and the end of the word is right up against the margin. The
next character the user will type is a space. In all three methods, before the
user types the space the cursor is at the edge of the margin and the pilcrow is
in the margin.

Present method: After typing the space there is no visual change. The user must
type the first character of the next word to see any change. If the user types
another space, still no visible change (although both spaces are there).

Your proposed method: After typing the space, a visible space is in the margin
followed by the pilcrow with the cursor planted between them. To snap the cursor
down to the next line the user must type the first character of the next word.
If the user types another space a second space appears in the margin and pushes
the cursor and pilcrow deeper into the margin.

My proposed method: After typing the space, a visible space is in the margin
(but only visible if "show nonprinting characters" is on) and the cursor has
snapped down to the next line along with the pilcrow, waiting for the user to
type the first letter of the next word. If the user types another space a second
space appears behind the first in the margin of the previous line, and neither
cursor nor pilcrow moves.

I was trying to create a spec where horizontal scrolling was not necessary if
the user puts a zillion spaces on a line. However, with "show nonprinting
characters" turned off, my method has a distinct disadvantage for those who are
in the archaic habit of putting two spaces between sentences.

Personally, I could live with either technique.

It would probably be best to include the tab character along with the space
character when determining word-wrap. After all, a tab is basically a variable
width space.


@ barryii

For your new proposal of showing subsequent spaces on the new line (after two
spaces), I say, "Let's not."

We're talking about automatic word-wrap behavior here. To let someone diddle
formatting by dumping in a bunch of spaces in the middle of paragraphs is pure
trouble. Change the font, font size, margins, paper size, or just edit the
previous line, and all that manual formatting ends up as junk.

Then what do you do about the complication where the two spaces at then end of
the line are well within the text zone (not the margin). As you add spaces do
they pop down to the next line, or do they stay on the first line until you get
two in the margin?

The only time I can think of someone wanting to do something like this is if
they are trying to fake a block-quote by squeezing the margins of a paragraph.
What they *should* do is use an existing block-quote paragraph style or create a
custom paragraph style. Of course some people don't do styles (they haven't
figured them out yet). Most inexpert users can probably figure out how to select
a paragraph, grab the little margin handles, then slide the margins for that one
paragraph inward to squeeze it. For people who are too dumb for even that, they
could insert a soft-return at the end of each line, then insert their spaces or
tabs or whatever on the fresh line.

If someone wants to stick six spaces between two words in the middle of a
paragraph, let them. If those spaces happen to fall on the line such that
automatic word-wrap gets involved, then shove all those extra spaces in the
margin and start the next line with the first character of the next word. Let's
not mess around second-guessing what the user wants.

scottydm: Using your method, when the spaces are appearing in the margin of the 
previous line, maybe a dot should show for each space even when "show non-
printing characters" is off, then the dots could disappear when a non-space 
character is typed. Or if you want to be more literal with the "show 
nonprinting characters" setting and not reword it, then use notation in the 
margin to indicating the changing number of spaces. Notation would indicate the 
number of spaces in a compact way that requires little if any scrolling and 
would be one step farther away from showing nonprinting characters than if a 
dot per character were shown. Or indicate the number of dots in the toolbar.

Having "show nonprinting characters" off doesn't hide all the things that will 
be hidden in the finished document anyway, so it doesn't really need to do a 
perfect job except for semantic reasons. For example, if "show nonprinting 
characters" is off, with default settings, you can still see frame borders that 
don't show in the page preview or when printed, and you still won't see images 
that you've inserted. I think the purpose of having "show nonprinting 
characters" off is to make the document somewhat prettier and easier to read 
for the composer, not to do as good a job as will be done for the recipient of 
the document. The wording of the option could be changed to "show all 
nonprinting characters" if necessary.

Which raises my "edit mode" and "reader mode" idea, which I've discussed 
elsewhere. Reader mode would be what you get when you first open a document. 
Images would show, but no frame borders and no non-printing characters - like 
when previewing the page - until the document body is clicked, which would put 
you in edit mode in which the document would appear is it currently would. But 
that's off-topic.

My second proposal, which you didn't like, was just an easy way to eliminate 
the current bug. I mentioned it just in case people were scared off by my first 
proposal.

fme->scottydm/all: [...] In my method I wanted to snap the cursor down to the
next line at the first
practical moment, in effect saying to the typist, "Put your text here." If he
continues to tap the space bar the cursor does not advance on the new line, but
spaces pile up in the margin of the previous line. [...]

I don't think we can/should do this. This would allow you to create a new line
(that increases the paragraph height) by entering a couple of blanks. I don't
think that any other Word Processor behaves like that. Also this could break the
layout of existing documents.

I would prefer a simple solution that covers the most important use case over a
complex solution that covers all use cases. A simple solution would also
increase the probability that this gets implemented in the near future.

So the initial request is, that you cannot see the spaces at the end of a line
in case there's a line break. So my proposal is: Let's paint them. Nothing more,
nothing less. If you have more that one blank at the end of the line, you'll see
it, and that's the point, isn't it? What do you think?

[...] Unfortunately, I don't know a lick of Java. [...]

No Java, C++ ;-)

@ barryii: Interesting idea, but fme may have rendered it moot.

fme said:
[...]I don't think we can/should do this. This would allow you to create a new
line (that increases the paragraph height) by entering a couple of blanks. I
don't think that any other Word Processor behaves like that. Also this could
break the layout of existing documents.[...]

I hadn't thought of that. While I don't think it's good practice to leave spaces
dangling at the ends of our paragraphs, it happens.

It seems like the cleanest would be to let the cursor slide over into the margin
when someone types one or more spaces while at the end of the line and before
they type the first letter of the next word (as barryii suggested). Also when
editing within a paragraph if you're adding spaces before a word the word
following the cursor would snap down to the next line, but the cursor would not.

By, "simple solution that covers the most important use case," I assume you mean
that if a user types scads of spaces within a paragraph, they pretty much
deserve whatever ugliness they get. I can live with that.

Give me about a day and I'll install MS Word and WordPerfect on my machine, then
report back what they do. My wife probably has a newer copy of MS Office than 2000.


It's really C++? Hmmm, I though I read somewhere it was Java, and with Sun's
involvement Java makes sense. I know ANSI C, but haven't bothered to learn any
of the ++ constructs. Sheesh, I don't think I have a C/C++ compiler newer than
six years old. I'm on Windowz 2000.

The current behaviour annoyes me most when after typing a non-space-character
the previos unvisible spaces will result in a line break and I see that there
are accidentally many of them.

There are already good detailed proposels (barryii, scottydm) and I am
interested if I summarize them correct when saying:
1) If there is a serie of at least two spaces show them all independend of the
"show nonprinting characters" setting (with a may be new indicator like a
special form of a dot)
2) For wrapping at the end of the line handle the second (and following) space
like a non-space character, so snapping to the next line occurs in an expected
manner. May be I should say: tread the _last_ of a sequence of (more than one)
spaces like a non-space character to allow a serie of spaces to stay in one
line, but at the end of the line (where the spaces reach the margin) snap to the
next line to indicate to the writer where following input will happen.
And to be nitpicking: This should "start new" after snapping to the new line so
that it is possible to insert multiple lines that consist only of spaces.

fme said:
[...]I don't think we can/should do this. This would allow you to create a new
line (that increases the paragraph height) by entering a couple of blanks. I
don't think that any other Word Processor behaves like that. Also this could
break the layout of existing documents.[...]

Though I am astonished I have to say you are perfectly right (at least for
ms-word 2000) so forget point 2) of my previous posting, because in the long run
it would result in an incompability issue. Someone who has ms-word newer than
2000 should check this.

This is the first time that the absence of a current ms-word installation
affects me ;-)))

Hi - I just wanted to say thanks to everyone for their contribution to this
issue. I would say more but am moving flat and have only just assembled my
computer temporarily to read my email...

My only quick comment is that 'I assume you mean that if a user types scads of
spaces within a paragraph, they pretty much deserve whatever ugliness they get'
sums it up very well for me. It is in fact the essence of wysiwyg.

As a naive user when I type a space I expect to see it at the cursor, not at the
end of the previous line, or anywhere else. When I type a character, space or
otherwise, up against the margin, I expect it to wrap to the next line not carry
on into the margin. The result may be dreadful to the purists, but there are no
surprises for me and if I don't like it I can correct it until I do. Or ask
someone more knowledgeable for guidance on a better way of achieving my aims.

I don't think it's the job of the software to save the user from himself, rather
it is to present the simplest behaviour that meets his expectations. When I get
settled in a day or two I'll look more at this but would recommend looking very
carefully at ms word - when I still used it I was never aware of the end of a
line as a concept so it's obviously doing something right.

Anyway, thanks again.

An alternative to having the cursor drop while spaces are added above would be 
to put a down-arrow between lines (slightly overlapping characters if 
necessary) that points to where the next non-space character will appear, if it 
will appear on the next line. That wouldn't exactly say to the typist, "Put 
your text here" as scottydm wanted, but at least it would show that the next 
non-space character will show on the next line. The down-arrow would appear 
even when a word is being entered at the end of a line (if the next letter 
would appear below), but with word wrapping the entire word would drop (snap 
down?), so the arrow wouldn't always point to the first space of the next line. 
The down-arrow would not cause a new line to appear. It would just point to a 
possible future new line.

There have been times when I wanted to fit everything on one page, and I'd type 
part of the last word and all in a sudden a new page appears. I'd have a 
warning of that with this idea. The arrow would appear on the current page and 
point down to let me know that a new page will begin if I enter another 
character.

This is mostly a report of the results of my experiments with MS Word XP and
WordPerfect 10. These are probably not the very latest versions, but they’re
pretty new.

First, WordPerfect has some seriously convoluted and complex behavior. I think
part of the problem is they don't have a soft-return (shift-return). At least
not one I could easily find. Therefore, besides the really complex stuff they do
to you when you stick more than two spaces between words, they also need two
kinds of full justification. Also, when you have "show nonprinting characters"
turned on, the last space on the line is only half a floating dot rather than a
whole floating dot. I have no idea why they did this. The full dot and the half
dot mean exactly the same thing (a space character) and I feel it's a mistake to
complicate the UI in this way. Since I do not advocate the WordPerfect method, I
decline to provide any screen shots.

In contrast, MS Word XP is dead simple and very easy to understand. I made four
identical paragraphs and diddled the line wraps within the paragraph so everyone
could see how it behaves. Paragraphs are 4 lines each, 1st paragraph has extra
spaces at the word-wrap site, 2nd paragraph has only single spaces, 3rd
paragraph has single spaces but with soft-returns to break the paragraph up, and
4th paragraph is broken into four paragraphs using hard-returns (this affects
justification). I used 12 pt "Courier New" font with a 6.52 inch wide text area.

http://www.skunkwks.com/web/hidden/OOo/MSWordXP_word-wrap1.png  This is the
right-hand side of the four paragraphs. 2nd line of 1st paragraph has a whole
bunch of spaces, but they are not all visible because some have "fallen off" the
edge of the "paper"; if you happen to put your cursor out there (using the arrow
keys) the cursor is not visible either; however, the cursor and the spaces exist
and are out there, somewhere. The 1st line of the 4th paragraph has extra spaces
before the hard-return; both hard and soft-returns can live in the margin, and
even in the gray zone off the edge of the "paper".

http://www.skunkwks.com/web/hidden/OOo/MSWordXP_word-wrap2.png  Here I've
selected all the text so you can see what Word's select box encompasses. This is
very different than OO's current behavior. OO now simply makes a reverse-video
box that fills up the text zone from left to right. Note that the extra-long
line in the 1st paragraph is only reversed out to the edge of the "paper". I
suppose it would be extra work to do a select box this way, but I feel the MS
method is superior from UI point of view because it shows the actual selected
text. However, the select box is not the real issue, and it's probably different
code.

http://www.skunkwks.com/web/hidden/OOo/MSWordXP_word-wrap3.png  I've justified
the text so that both margins are lined up. As you can see justification ignores
the "dangling spaces" and goes off the last non-space character in each line.
The last paragraph with hard-returns is not justified because each line is
really a paragraph; the lesson is that if you feel you must insert returns, make
them soft-returns so the system recognizes the lines belong in a single
paragraph. You'll be happy to know that OO Write behaves like MS Word... almost;
the exception is that when using soft-returns, if there is a space before the
soft return, OO puts the space *inside* the text area. I feel MS Word's method
is the correct one. For the 1st paragraph: OO Write justifies strings of spaces
the same way MS Word does, which I feel is correct.

http://www.skunkwks.com/web/hidden/OOo/MSWordXP_word-wrap4.png  Here I've
centered all the paragraphs. I've also turned off "show nonprinting characters"
so you can see how MS Word ignores the dangling spaces and those hard and
soft-returns when it figures out how to center the lines. It looks beautiful,
doesn't it? OO Write does pretty good here, except when there is a return (of
either type) and there is a space at the end of the line before the return, then
it shoves the line over to the left... sometimes. I feel that nudging text with
extra spaces is the wrong method to use in a word processor. A text editor,
sure, but not a word processor. Personally, I'd rather see the MS Word method of
*always* ignoring the width of dangling spaces and any returns when justifying
text. It's simple and easy to understand.

http://www.skunkwks.com/web/hidden/OOo/MSWordXP_word-wrap5.png  Same view, but
with all text selected. Both MS Word and OO Write treat the first two paragraphs
the same and give perfectly centered lines. However, the paragraphs with
inserted returns (hard or soft) behave very differently. MS Word *always*
ignores the width of trailing spaces and returns, OO Write sometimes ignores
them but usually not. For the 1st line of the paragraph, where the text exactly
fills the text zone, if there is no space but only a hard or soft-return, the
line is centered correctly and the return is in the margin. If you add any
spaces between the last word and the soft-return, the line is centered properly,
but the soft return is shoved down to a new line (and centered), thus you get a
blank line. If you add any spaces between the last word and a hard-return, the
line is centered properly and the hard-return remains glued to the end of the
line (and the spaces don't show, although they are there). Consider the 2nd line
of the paragraph, where the line does not fill up the text zone. As you add
spaces between the last word and the return the line is shoved a bit to the left
until it fills with spaces, then they suddenly vanish and the line pops back to
being centered again. Now with a soft-return the soft-return character is shoved
down to its own line, but with a hard-return it stays on the original line and
snuggles up against the last character of the last word. Of course the spaces
are there in both cases, but we can't see them.


To answer some of the more recent comments:

Should we have a "magic mode" where spaces in the margin are always shown,
irregardless of the state of the "show nonprinting characters" button?
Absolutely not! Why? Because when I want to see the spaces (or other nonprinting
characters) I'll turn on that mode. And when I turn that mode off I don't want
to see nonprinting characters. No exceptions, ever. It breaks the WYSIWYG
paradigm to do otherwise.

Should we have more than one type of character to show spaces (when the "show
nonprinting characters" is on)? If we're talking one space = one character, no!
The WordPerfect paradigm is just plain weird and seems senseless, plus someone
has to write and maintain extra code. If you mean a "fat space" to show a gob of
spaces, maybe. However, consider the MS Word paradigm where you just let single
spaces dribble off the edge of the "paper". Sure, it might be inconvenient if
you've got 7,000 spaces in the middle of your paragraph, but how often will that
happen?

Should we wrap after typing two spaces, then allow new spaces to go on the next
line? Absolutely not! WordPerfect does that, sort of, but then it provides
several tricks to get around it (e.g. type three spaces, then backspace, type
three more spaces, then backspace, etc.). First, throwing a string of spaces
into a paragraph is going to almost never be a requirement as long as the user
is using OO Write like it's a word processor and not a text editor. I think MS
Word has the right approach: If for some bizarre reason there happens to be a
bunch of spaces in a paragraph, and they run into the word-wrap area, stick them
at the end of the line. *If* the user really does intend to manually monkey with
formatting (maybe they are trying to stick spaces at the beginning of lines in a
paragraph) then they should insert soft-returns at the end of each line. It'll
be far less trouble for them to maintain the document that way. Besides, OO
Write now sticks the extra spaces at the end of the line--the issue is that it
doesn't show them.

About barryii's down arrow widget. I'm not sure that's needed. First, as fme has
rightly pointed out, my idea to snap the cursor and pilcrow down to the next
line before the user types a non-space character, sucks. So I've abandoned the
idea. It isn't that your down arrow widget is a bad idea, but I don't think it's
needed to fix this particular problem.


About MS Word and cursor position while entering fresh text/editing existing text:

When entering new text, that is there is a pilcrow just to the right of the
cursor, you can push the cursor and the pilcrow into the margin by inserting a
bunch of spaces. In fact, you can push the pilcrow and cursor right off the edge
of the "paper" and into the gray "never never land" that exists somewhere to the
right of your monitor. As soon as you type your first non-space character the
new character, cursor, and pilcrow all pop down to the next line. Clean, simple,
intuitive. And best of all, you don't start sticking blank lines below paragraphs.

When editing an existing paragraph, you can set your cursor at the beginning of
a line, just in front of the first character. However, you cannot set your
cursor at the end of a line after the final space on that line. It really is the
same place in the string of text, so pick a spot. Normally this is fine if you
decided you needed to insert a word. You'd start by typing a non-space character
and all behaves as expected. BUT if for some weird reason you try to type a
space at the beginning of a line, it flies up and sticks to the end of the
previous line (and the space already there). Some may find that a bit weird, but
it does fit the simplified rules of word-wrap that MS Word seems to use.


MS Word and tabs:

You cannot stick tabs in the right margin in MS Word. I know, I suggested it a
couple of days ago, calling a tab nothing more than a variable width space.
However, it probably wouldn't hurt to mimic MS Word behavior. So, when you push
the cursor into the margin by typing a few spaces, you can hit tab and the tab
will fly down to the new line. For those who feel they must manually diddle
format with characters (perhaps they miss edlin (which is vi for DOS, but far
more primitive)). This could be an alternative to inserting soft-returns.


Thoughts on justification and text centering, mentioned above:

Everything is deeply intertwingled. Based on my brief experiments with OO Write
and centering text, I'm going to make wild guess that text justification and
centering *relies* on visually hiding the spaces at the end of lines. So when
someone unhides those spaces, all kinds of ugly is gonna happen to people's
documents. Therefore, the justification and centering routines will probably
need to be tweaked too. For consistent and robust behavior, the MS Word model is
hard to beat: Always ignore the width of dangling spaces and returns when doing
justification and centering calculations.

Mostly this will work, even with old documents. Where it fails is where some
people have jammed a few spaces at the end of a short paragraph they wanted
centered. Example: Let's say I'm writing a novel. I have a custom paragraph
style called "manuscript" and this style includes a first-line indent. When I
get to a scene break, I type "# # #" in a new paragraph by itself, and I want it
centered on the line. If I was a newbie I might select the paragraph then click
the "center text" button. Except it wouldn't be quite centered because of the
first-line indent. One newbie way to fix this is to put a few spaces after the
last "#", to shove the whole mess over to the left a bit. Of course the best way
to fix it is to create a new style and maybe call it "manuscript centered".

Now using that newbie method to tweak centering, we could break those tweaks if
OO Write v3.0 starts ignoring dangling spaces. How bad does this hurt the user?
Well, the information is all there and all visible. It's just not quite as
pretty as it was before. And the reason it's not quite as pretty is the user
used a poor technique in the original document. If it were up to me, I'd say,
"Go for it. Don't look back, and don't create exception code." The cost of
failure is low.


That's about it, I think.

Legal stuff: I'm not even gonna mess with a CC license on those screen shots.
They are public domain, but please don't hot link. The text is a mashup of
Kennedy quotes and an old nursery rhyme.

I agree that OO Writer should ignore trailing spaces as you describe even if it 
breaks some people's hacky centering of indented lines, but I'm not against a 
OOo 2.0 mode in which people's code wouldn't break but new features aren't 
available.

scottydm wrote:

"When editing an existing paragraph, you can set your cursor at the beginning of
a line, just in front of the first character. However, you cannot set your
cursor at the end of a line after the final space on that line."

I think it should be allowed. Let's take advantage of every easy improvement 
over MS Word that we could make that has no bad side. The first place I'd think 
of to put the cursor if I want to delete the last character of a line is at the 
end of the line. Having the cursor jump down to the beginning of the following 
line if someone tries to put their cursor at the end of the previous line (I 
don't know whether MS Word does that) is OK because the letter would be 
inserted down there anyway, but with spaces it would be weird, as you said. It 
breaks WYSIWYG.

scottydm wrote:

"2nd line of 1st paragraph has a whole bunch of spaces, but they are not all 
visible because some have "fallen off" the edge of the "paper"; if you happen 
to put your cursor out there (using the arrow keys) the cursor is not visible 
either"

It's kind of like MS Word is in viewer mode by default and OO Writer is in edit 
mode by default (with OO Writer not showing images, etc). I'm more of an MS 
Word person, but I also like to know exactly what's happening to the document 
I'm editing and where it's happening. If the cursor is going to "fall off" like 
that, then at least have some information in the toolbar about where the cursor 
is. I'd prefer the information in the margin, on the line of the cursor, 
whether or not "show nonprinting characters" is on. Remove the information when 
the cursor gets out of the invisible area.

I'm still digesting scottydm's very interesting post.

In the meanwhile, I wonder whether this approach isn’t over-complicating the
matter? My assumption was always that the margin is inviolate. When I hit it,
it’s a brick wall and I have to start again at the next line. This is surely
what the naïve user would expect?

To add to that I would say that having space characters in the margin, and even
worse, invisible space characters in the limbo of the ‘grey area’ is another
fundamental breakdown in wysiwyg. How are you supposed to edit them?

I would do it like this:

1: the cursor is at the end of the line ie against the margin, after typing a space.
a) the next character is non-space: move to the next line, and show the non-space
b) the next character is a space: move to the next line, and show the space.

2: the cursor is at the end of the line after typing a non-space
a) the next character is non-space: restart the whole word on the next line,
leaving the last space dangling on this line. If the word is longer than the
line, just split it before this character.
b) the next character is space: leave it dangling at the end of the line and
move the cursor to the start of the next line.

If in the 1b case the user continues typing spaces, you continue showing them -
just as many as he wants. I can't see any good reason to do otherwise, and all
the alternatives I can see ultimately result in a wysiwyg failure. 

Hyphenation occurs when this word is completed and obviously may result in
different line endings.

This approach seems to me to avoid all questions of what you do with the margin
(which of course may not even exist) and the grey area; to make it immediately
and intuitively obvious to a user what is happening; and to be very simple to
implement. You (and I!) may not like the user typing spaces at the start of a
line, but that’s his choice – we can’t know in advance all possible formats he
wants to achieve – what is important is that he should be able to see everything
he’s done and edit it in a completely predictable manner.

On a couple of other points raised:
- positioning the cursor at the end of the line: I think this is fine, but it
should be treated in all respects as though it were actually positioned at the
start of the next. [I think that's what scotty said.]
- justification: here I think the basic principle is that all leading and
trailing spaces are hidden - they should take no part in the calculation.
Similarly with centred text. [Ditto]

Oh well, that’s my twopennyworth... off to bed!

For clarification, my previous post, #desc76, was mostly a discussion of how MS
Word XP behaves. As I remember, MS Word 2000 behaved the same way.

barryii said: [...]
scottydm wrote:

"When editing an existing paragraph, you can set your cursor at the beginning of
a line, just in front of the first character. However, you cannot set your
cursor at the end of a line after the final space on that line."

I think it should be allowed. Let's take advantage of every easy improvement 
over MS Word that we could make that has no bad side. The first place I'd think 
of to put the cursor if I want to delete the last character of a line is at the 
end of the line. Having the cursor jump down to the beginning of the following 
line if someone tries to put their cursor at the end of the previous line (I 
don't know whether MS Word does that) is OK because the letter would be 
inserted down there anyway, but with spaces it would be weird, as you said. It 
breaks WYSIWYG.
[...]

I didn't say it broke WYSIWYG, I said some people may find it weird. If you
think about it, it makes sense.

Here's the deal: You have a long string of text, words with spaces. This string
is too long to fit within the text area so the word processor word-wraps the
string so that it takes two lines. Click on the string somewhere to insert the
cursor and use the left/right arrow keys to move the cursor along the line. When
you get to the word-wrap place, where do you *show* the cursor? Should it be at
the beginning of the second line or the end of the first line?

That's the essence of it. Logically there is one place, but visually there are
two. MS Word happens to always put the cursor at the beginning of the second
line. If you think about deeply about it, attempting to create a system where
you can visually have the cursor in either location creates a pile of weird
paradoxes. The good news is, pick one place or pick the other place, either one
is correct.


barryii said: [...]
scottydm wrote:

"2nd line of 1st paragraph has a whole bunch of spaces, but they are not all 
visible because some have "fallen off" the edge of the "paper"; if you happen 
to put your cursor out there (using the arrow keys) the cursor is not visible 
either"

It's kind of like MS Word is in viewer mode by default and OO Writer is in edit 
mode by default (with OO Writer not showing images, etc). I'm more of an MS 
Word person, but I also like to know exactly what's happening to the document 
I'm editing and where it's happening. If the cursor is going to "fall off" like 
that, then at least have some information in the toolbar about where the cursor 
is. I'd prefer the information in the margin, on the line of the cursor, 
whether or not "show nonprinting characters" is on. Remove the information when 
the cursor gets out of the invisible area.
[...]

That's a good idea. It is extra visual widgets though. This is a real problem
with MS Word and the vanishing cursor. Another approach would be to give the
user a horizontal scroll bar when this happens and show the spaces and cursor
out in the (now very wide) gray area.


redi2go said: [...]
In the meanwhile, I wonder whether this approach isn’t over-complicating the
matter? My assumption was always that the margin is inviolate. When I hit it,
it’s a brick wall and I have to start again at the next line. This is surely
what the naïve user would expect?

To add to that I would say that having space characters in the margin, and even
worse, invisible space characters in the limbo of the ‘grey area’ is another
fundamental breakdown in wysiwyg. How are you supposed to edit them?
[...]

I think "nonprinting character" is a misnomer. We should call them "characters
that don't take any ink when you print them out", except that's long and sort of
dumb sounding (but true). The margin is inviolate in that you can't put any ink
there. Characters which don't use ink are: space (in topography they come in
several widths), return (hard and soft), tab, the non-breaking space, the
vertical tab (not quite sure what that is in terms of a word processing
document), and page and column breaks. There are probably others. Now the
non-breaking space contains mojo because you are to treat it like an ordinary
inky character, and as an ordinary inky character you may not put one in the
margins.

If I justify both sides of my text, I want my inky letters snuggled up against
the margins. I do not want to see any gaps between between the printed words and
the margins. Nor do I want to see any ink in the margins. Therefore, I must
allow at least one space in the margin... and I must allow the pilcrow in the
margin (hard return)... and I must allow the cursor in the margin so I may edit
the non-inky characters who live there. MS Word does exactly this, and
WordPerfect does this too (to a degree).

The question has become, how many non-inky characters do we let into the margin
(one of several questions, but this is the basic one). Let's talk spaces because
they are the universal non-inky character.

WordPerfect will allow two (normally). Then it will snap down to the next line
and if you keep inserting spaces it will put them on the next line -- unless you
do some fancy key strokes, or move your cursor up to the previous line and
insert spaces before your spaces. It's complex and nonintuitive. The word
processor sometimes does stuff you don't necessarily expect it to do.

MS Word lets you put as many spaces as you want into the margin. In fact, it
refuses to let you put them at the beginning of the line *unless* you stick in
some sort of return first. I only tried sticking in 40 or so, and I don't know
if there is a limit. MS Word even shows you those spaces (normally) and you can
move your cursor around the margin and delete or add more spaces. However, as
barryii pointed out, not showing the spaces in the gray area (off the edge of
the page) means you can "lose" your cursor out there, and that's not cool.
However, the MS method is dead simple and very easy to understand: The cursor
does not snap down to the next line unless you type in an inky character OR you
tell it to go there by typing in a return (hard or soft). There never a mystery
about when it will snap because you control when it snaps.

OO Write hides the spaces (the whole point of this bug report) and as hidden
spaces you can put in gobs and gobs of them. They don't seem to live anywhere.
They are there, but they are not there. Like MS Word this is simple because
there is no mystery about when the cursor will snap to the new line -- it does
so when you tell it to do so. The problem is that you can't see these spaces so
you can't edit them other than to blindly pick away at them with backspace or
delete (or, for the perverse, pile in more spaces).


Back in the day of the Underwood,
http://www.typewritermuseum.org/collection/index.php3?machine=underwood5&cat=kf
the user had to think about content AND presentation at the same time. It was a
mechanical process. If you wanted your first line to start one-inch down the
page, you had to manually insert paper then roll it up one inch before you
started typing. And heaven help the poor user who had to insert a long word in
the middle of a paragraph!

We have computers now, but a TEXT EDITOR is still a very mechanical experience.
To indent the first line of a paragraph, hit the space bar five times; to put
extra spaces between paragraphs, hit the return key twice; etc.

To truly disconnect the content from the presentation, use a WORD PROCESSOR. OO
Write is a word processor. Users should not be mucking about with strings of
spaces to try to tweak the look (presentation) of their document. That's why
they're using a word processor, or it should be why they're using a word
processor. Hopefully no one using OO Write is building tables with hyphens,
vertical bars, and strings of spaces (as you'd be forced to do in a text
editor), they should know enough to insert a table. Likewise with other nits of
presentation -- learn to use the formatting and styles tools.

Now some users are in the habit of typing two spaces at the end of each
sentence. They were taught to do that (despite the fact it's a very "Underwood"
sort of thing to do), and some will defend the practice. Other users are
converting old text documents and they will have strings of spaces to deal with.
And still others are confused by OO Write and slip an extra space in here and
there. So while the ideal is no more than one space at a time, the reality is
that sometimes spaces come in packs, flocks, herds, and occasionally swarms.

So with that in mind -- redi2go said: [...]
I would do it like this:

1: the cursor is at the end of the line ie against the margin, after typing a space.
a) the next character is non-space: move to the next line, and show the non-space
b) the next character is a space: move to the next line, and show the space.

2: the cursor is at the end of the line after typing a non-space
a) the next character is non-space: restart the whole word on the next line,
leaving the last space dangling on this line. If the word is longer than the
line, just split it before this character.
b) the next character is space: leave it dangling at the end of the line and
move the cursor to the start of the next line.

If in the 1b case the user continues typing spaces, you continue showing them -
just as many as he wants. I can't see any good reason to do otherwise, and all
the alternatives I can see ultimately result in a wysiwyg failure.
[...]
#1b: This violates the word processor paradigm; it encourages and/or forces the
user to think about presentation issues; it mucks things up for those who insist
on typing two spaces after each sentence; and it is different behavior than MS
Word, OO Write, and even WordPerfect; which will change the appearance of older
documents or imported documents.

#2b: Are you saying to put the space in the margin? Assuming so, then do not
move the cursor until the user types an inky character or a return (hard or soft).

Final paragraph: Putting non-inky characters in the margin in no way breaks the
WYSIWYG paradigm. Just show them there and allow editing.

Overall: Some of what you propose is text editor behavior. If someone wants the
behavior of a text editor then they use a text editor. OO Write, or any word
processor, is the wrong tool for them.


redi2go said: [...]
On a couple of other points raised:

- justification: here I think the basic principle is that all leading and
trailing spaces are hidden - they should take no part in the calculation.
Similarly with centred text. [Ditto]
[...]
"Hidden" is exactly the sort of behavior we are trying to solve with this issue
report. I hope you meant "ignored". Show the spaces, but ignore them when
calculating where to put the words on the line.

However, this is a special case. Creating a paragraph indent by typing spaces or
hitting tab is a mechanical and archaic way to solve a presentation issue. It's
wrong, but it's not a mistake. Now a web browser will ignore leading spaces and
tabs, but MS Word and OO Write do not. It's one of the differences between the
web paradigm and the word processor paradigm. It's ugly, but I say pay attention
to the leading whitespace and ignore the trailing whitespace.


Scotty

Hi!
Seems the problem exists since 2003, now it's 2008 and in Version 2.3.1 the
problem still exists?!?

But it _is_ a problem:
If formatting or text changes, wordwrap happens at another position and then I
have multiple, visible spaces in my text.

Otherwise it would be no problem, if multiple Spaces at the end of a
soft-wrapped line were visible (only one Space should be ommited).

yours 
hr

Changed title.

Created attachment 52996 [details]
Justified paragraph showing n spaces at the end

Created attachment 52998 [details]
Left aligned paragraph one space at the end. None printing characters off.

Created attachment 52999 [details]
Left aligned paragraph n spaces at the end. None printing characters on.

FL->FME: As discussed. The following should solve this issue and considers
technical issues and ressource limitations we have.

- All spaces are shown (clipped by the page, cell, frame border), if none
printing characters (NPC) are turned on.
- But only the first space can be traveled. So the cursor can be placed behind
the first space (please see attached "Adjusted_NPC_n_spaces.png"). This allows
the user to detect a space at the end of a line even if NPCs are turned off.
- The user can eat spaces by hitting Del key or via Backspace at the beginning
of the following line.

Since I'm not going to keep "show non-printing characters" on, that solution 
won't help me, but I can't argue with the "resource limitations" argument. I 
don't know anything about that.

Wow, fl, are those actual screen shots? That's awesome!

Not allowing the cursor past the first space isn't ideal, but it's an acceptable
way to solve the problem of keeping the cursor out of the gray area past the
edge of the page. Unlike barryii, I usually input text with "show non-printing
characters" turned on.

From these screen shots I can't tell the behavior of the cursor when it's
between the last space and the inky character at the start of the next line. If
it were at the start of the next line, then the behavior shown in the
screenshots should also be acceptable to folks who keep "show non-printing
characters" turned off. That is, while in the middle of a paragraph if you see
the cursor floating out in the margin, you know there must be at least one space
after it.

I usually run only the released code, but I'd love to get my hands on this and
try it. What version should I download?

Thanks!

Yeah, I see now that it would work for me, normally. Are the spaces at the end 
of the line selectable by left clicking and dragging the cursor from the end of 
a line to the beginning of the next line, then deletable by hitting backspace?

3.0 beat is near, time to change the target to 3.1 as we haven't started the
implementation.

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

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

Hello.
I just tried v3 beta and still no change: Spaces at the end of a line are still
not indicated!! I have seen that a fix is expected for 3.1, but excuse me, that
problem exists for 5 years now!! And it is not a small thing, it is a major,
major, major bug!! I don't understand: what is the problem of putting a dot
instead of a space? Can someone please explain why this takes longer than one hour?
I don't mean to be impolite, but I am a little bit surprised about it.

J.

fme->healtheworld:

[...] just tried v3 beta and still no change: [...]

Of course not, the state is still 'new' and not 'fixed' or 'verified'

[...] I don't understand: what is the problem of putting a dot
instead of a space? Can someone please explain why this takes longer than one hour?
I don't mean to be impolite, but I am a little bit surprised about it. [...]

Get the code, fix it and send us the patch ;-) First please read all the
comments in this issue carefully. This will take a while. You'll see, there has
been quite some discussion about how this is expected to work. But finally, on
20080-05-18 UX came up with a decision of how to implement this. Now I dare to
say that chances are good that we'll have this for OOo 3.1.

Cannot be implemented for OOo 3.1. Sorry, but our resources are limited.

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

The problem is not only, that the spaces aren't shown nor, that they appear,
when the linebreak later changes to another place of the text, so that e.g.
several spaces appear, which haven't been shown at all before.

There is even another problem: a space can cause a linebreak and create a whole
empty line.
See 2 attachements.

Created attachment 57124 [details]
file showing an unwished linebreak

Created attachment 57125 [details]
file showing an unwished linebreak

This is one of the biggest problems I have had with Openoffice. Notice that when
you add a bunch of spaces it goes to the right margin and then jumps back as if
the spaces have been deleted!? Also, when you are typing and the cursor is near
the right margin, when you press the spacebar it doesn't show the space at all.

Any chance of bumping this up to a P2 and/or changing the issue type to a 
DEFECT instead? This single issue seems to be a major ongoing irritant for 
much of the OOo user base. Also, if it's just an issue of human resources, 
perhaps a lead implementor can be appointed and issue a call for developers on 
this one. It's been almost 5 years since I did any development/integration 
work with OOo -- pretty much because none of the issues I've reported have 
been dealt with (I've even given up reporting new defects I've found) -- so 
I'd need guidance on what part(s) of the code to chomp on (I've forgotten more 
than I ever knew about the code structure), but my offer of assistance remains 
open.

The problem with this issue is that too many people have expressed too many
different views and requirements. I still don't see a solution that addresses
them all, so the question is if any partial solution does make a big difference.
But even a partial solution has a lot of impact on the text formatting code
(means: brings a regression risk) and needs quite some work to do.

The complexity (and thus the effort) could be reduced if we could avoid cursor
travel into trailing blanks. But this would mean that you still can see these
blanks only when non printing characters are "on". And there already have been
comments that this is not an acceptable solution.

Well, there's no denying this is a tough nut to crack, but it sounds like things
are wedged into a corner with little hope of being extricated at this point. I
am reluctant to stick my nose too far into this, but I am even more reluctant to
sit by for another few years. To that end, might I suggest that this thread be
wrapped up (with further input by anyone who wants to contribute here) and a new
thread be created with a final feature specification for implementation? Once
that's done, it'll just be a matter of rounding up a development team (or
individual... as I said, I don't have enough code knowledge to make an estimate)
to implement the specification. As I have said, I can only code OOo if given
guidance by someone familiar with the source and structure; however, I do have
plenty of experience with software requirements analysis and writing feature
specifications. As I have said, I'd be happy to help in any way I'm capable of,
please let me know if you want me to run with my suggestion. Obviously, the main
design team will get the final say, but I might be able to do some of the up
front work.

@mru, jbotte:  If I can help, just ask. It will be some months, at least, before
I can do any development on OOo, but I'd like a project to focus on.  And if
someone else does it meanwhile, the effort won't be wasted.

IMHO, you are absolutely right that some good paperwork is needed before coding
can begin. 1's and 0's are more my speed, but I guarantee to read what anybody
writes. /tj/

I still care about this issue. It is my #1 irritant about OO Write.

mba has suggested that one contribution to implementation paralysis (Feb 2,
2009) is too many suggestions by too many people. Let's go with fl's screen
shots (Apr 18, 2008).

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

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

Issue 98566 sounds similar?

OK, so let's go for fl's suggestions. I will put this issue on the list of
possible features for 3.2 (planned community review).

Are any news?

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

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

7 years?
About time this was fixed, please!

I have a use-case where this defect has caused considerable trouble. My task was
very simple. A non-technical manager developed a variable length form using MS
Word. Some of the content of the form will be modified three times a year by the
manager. There are 10 blank areas at the end of the form where the person
receiving the form will type in several paragraphs of text. In addition to the
three times a year customization, the manager customizes each instance of the
form by filling in six fields at the top of the form with information that
defines the status of a specific item that is to be reviewed by the person
filling out the remainder of the form. There are over 100 unique forms emailed
to reviewers for each meeting. The fields for the form will be defined in a
spreadsheet. 

I wrote a short Python script to do the text substitution using the UNO API. I
put substitution strings, e.g. $SchoolName and $Reviewer, where I wanted the
content to be replaced. It took about 30 minutes to write and it worked great.
It took the script about three minutes to generate all 100+ forms. Each form was
in a file with a unique name as defined by the manager. 

The top of the form looks like a typical old fashioned data gathering form that
could have been typed on a  typewriter. Each field is preceded by a text
description and the area where the field is to be filled in is a blank line on
which the text was to be written. The form will be filled out using MS Word so
the blank line that is suppose to have the custom content is just a string of
spaces written with the underline attribute turned on. In MS Word the line will
be drawn to the end of the text area on the page even if there are more spaces
than will fit in that space. 

The underlined spaces for the fields at the end of the line do not work the same
in OpenOffice Writer. If the underlined spaces would fit in the space available
then the line is drawn. If there are too many underlined spaces the underline
disappears. (Actually, there will be one space underlined following the text.) 

The trouble I encountered with this bug made it look like the form substitution
script was not working consistently. The underlined spaces following text at the
end of a line disappeared on some of the forms. The appearance depended on the
length of the substituted text. A short string would fit, but if the substituted
string was too long the trailing underlined spaces disappeared. My 30 minutes
script writing exercise turned into hours as I tried to track down the cause of
the disappearing line. 

Oddly, the trailing blank line did appear when the forms were opened by MS Word.
I could use my script, in spite of the defect in Writer, but I wasted quite a
bit of time because of a defect in how Writer handles underlined spaces that
extend past the end of the text area. 

->mclay:

Sounds like your issue is exactly related to this bug, so you've come to the
right place.

There seem to be a lot of deeply intertwingled code issues with this bug, even
so it'd be insanely great if someone on the development team could fix it.

>>mclay:

>Sounds like your issue is exactly related to this bug, so you've come to the
right place.

>There seem to be a lot of deeply intertwingled code issues with this bug, even
so it'd be insanely great if someone on the development team could fix it.

I am the original poster.  Don't hold your breath.  Open Office only fixes bugs
that interest them or block some new feature bloat they want to add.  Check out
when I opened this bug:  "Opened: Wed Oct 8 11:23:00 +0000 2003"  This bug is
over SEVEN years old and they still do not care.  Very frustrating.  And very
bizarre for an open source project: OO is the only open source I know of that
acts this way.  Maybe they all used to work for Microsoft.

-T

-> toddandmargo

Yeah. This issue is older than the hills. Although not an early poster, this
coming Saturday will be my 4-year anniversary posting to this issue #.

Back in my almost 4-year-old post I wrote that I didn't think it was a bug per
se, but a poor design decision. Someone chose to _not_ show the visible version
of the space characters at the end of lines, or to allow the cursor to be shown
anywhere but smack up against the last printable character on the line.

A possible related issue is the decision to show the background of selected text
as a simple rectangle, rather than show the outline of the selected characters
(as the Big Boys do: MS Word and Word Perfect).

Yet another related issue is the behavior of centered text when you add spaces
to either end of that text, which is related to the behavior mclay observed.

It's all deeply intertwingled. I do not know the skill level of individuals on
the team, but could it be that the person assigned this bug feels overwhelmed by
the complex interdependencies? Or maybe this issue touches so many bits of code
that fixing it is a moving target, and the person assigned to this feels
overwhelmed for that reason.


Microsoft...

I was under the impression they all worked for Sun Microsystems. I mean,
Microsoft has a "real" word processor and therefore an ex-MS programmer should
know how to design a word processor without having to reinvent the whole UI. The
OO team seems like they just made up a pile of "stuff" and threw it into the UI.


I'm an ex chip designer, and spoiled by the hardware paradigm I'm crap as a
programmer (although I've had a touch of ANSI C in my day). I can't help but
wonder if an outsider tried to turn in code with a fix for this bug, would the
team accept it?

Hi All,

I reopened this over in Libre Office (what a beautiful clean up of OO!):

https://bugs.freedesktop.org/show_bug.cgi?id=33167

-T

Where is located function/code responsible for displaying <text:s text:c="19"/>
space content?

I think this function/code must be changed to proper handle of the split.

Hi guys.

After long time (about 2 moths !) of analyzing/hacking the code, I have finally found solution for this very annoying bug.

Unfortunately I see the risk that this solution will change the text formatting of the existing ODF files.

Please look at the screenshots of the same file, on OO.o with fix and without:

ooo_with_fix.png - the first line is finish with spaces and the second line starts from spaces

ooo_with_fix.png - the first line is finish with spaces(which is not displayed and it is hard to remove them) and the second line starts directly from the letters.

I think it is not so easy to fix it, because it could completely change current formatting.
What is your opinion?

Created attachment 76239 [details]
screenshot of the ooo with fix

Created attachment 76240 [details]
screenshot of the ooo without fix

Created attachment 76241 [details]
test file

Nice work. Would it be possible to just show the spaces past the line, like Abiword does? Abiword doesn't have problems with spaces trailing off the edge, it just displays them as is, without reformatting. See attached pic.

Created attachment 76242 [details]
Abiword, correct formatting with show-special-characters turned on.

@gang65: +1 for your fix. Yes, it will change the display (and printing?) of some files, but not the file contents. These are problems that users can easily fix for themselves, now that they can see what's going on—thanks to you!

Please attach the screenshot of the dupa.odt file, after opening it in MS Word and KOffice.

gang65:

I am thrilled that someone is finally looking into this bug.

From your screen shots I'm going to make the guess that OO Write originally showed the behavior of wrapping spaces down to the following line. In fact I bet if your printable characters were just right, a single space would wrap down to the next line. My guess is that rather than code up a proper way of handling this, someone just killed the display of any and all spaces where lines would wrap within a paragraph.

The key may be to think of characters that use ink, and characters that don't. In this second case that would be the space (in its various flavors) and maybe the tab. Although the non-breaking space doesn't use ink, by its very nature it will not appear where a line wraps.

Unless it's preceded by a newline (CR-LF or LF) a no-ink character must never appear at the beginning of a line, even if that means it ends up on the previous line several inches off the right edge of the virtual paper.

A good general rule is: A line may wrap just before the start of the first inky character after any no-ink character.

Exception to the good general rule: If the line would otherwise be too long, it may wrap between any two inky characters.


Now how do we show these no-ink characters (specifically spaces) when they appear outside the boundary of the text zone? If they're still within the boundary of the virtual paper, I'd say go ahead and show them (if show non-printing characters is enabled) as those dots. If they're outside the boundary then maybe don't show anything but the cursor stuck at the right-hand edge of the paper.

Starting with comment 81, fl dummied up some screenshots of what extra spaces might look like. See: http://openoffice.org/bugzilla/show_bug.cgi?id=20878#c81

It's been suggested the cursor should not be able to travel out where these extra spaces are. If that means while the spaces are within the text zone (for example with a non-justified paragraph style), then I suggest not. If that means outside the text zone but still on the virtual paper (right-hand margin) then that's debatable. But if that means not showing the cursor if it'd be off the right-hand edge of the paper, then I completely agree. Keep the cursor on the paper.

Maybe a few of us could photoshop some screenshots to show desired behavior.

S~

Created attachment 76276 [details]
OO.o with second version of the patch

Created attachment 76277 [details]
test file 2

I have updated the patch, to correctly display Left Aligned text. The nonprinting characters is displaying till the end of page.

Take a look at ooo_with_fix2.png file.
Is it what you want?

@gang65: thanks for your effort, we will have a look and give feedback

Created attachment 76297 [details]
Screeshot of MS Word XP, left-aligned paragraphs

This screenshot shows the actual behavior of MS Word XP with left-aligned paragraphs. All paragraphs are four lines.

P1: Too many spaces at line ends. 1st line is exact width of printable area. 2nd line has even more spaces than shown (they've "fall off" the edge of the virtual paper).

P2: Exactly the right number (1) of spaces everywhere.

P3: Exactly the right number of spaces, but line wrap manually managed by inserting line breaks.

P4: Similar to P3, but with paragraph breaks on every line.

Created attachment 76298 [details]
Screeshot of MS Word XP, justified paragraphs

Here's the same paragraph data, but with paragraphs set to justified.

Note that because P4 is four individual paragraphs, justification has no effect.

----

The way Word does it is exactly what I'd love to see. It's intuitive and works for a large number of cases.

S~

Comment was deleted by admin

Created attachment 76416 [details]
Final , tested patch 

Feel free to test the patch.

blank5.patch is implement the display of the the non printable characters till the end of right margin. 
It works only with left align (the rest aligns was unchanged)

One of the most big benefits of blank5.patch, is possible to edit non printable character at the end of line (for example inserting new characters).

svn commit -m "i20878 - Q-PCD shows spaces at end of a wrapped line in Writer." sw 
Sending        sw/inc/paratr.hxx
Sending        sw/source/core/text/guess.cxx
Transmitting file data ..
Committed revision 1244232.

Thanks to tj@ for pointing out this issue a while ago.

Thanks Pedro for pushing the patch.
I'm glad that this long time issue was solved. Soon I would like to contribute more patches to OpenOffice

I spend a lot of hours to fix this issue.

Could you please add my name to the list of contributor?

(In reply to comment #137)
> Thanks Pedro for pushing the patch.
> I'm glad that this long time issue was solved. Soon I would like to contribute
> more patches to OpenOffice
> 
> I spend a lot of hours to fix this issue.
> 
> Could you please add my name to the list of contributor?

Absolutely .. You deserve all the credit.  HUGE thanks!

Now, I am somewhat new to crediting conventions; 

Can you point me out where you want me to add your name? Send me the URL and or location in the SVN and the name you want to appear.

Also please note that email forwarding for openoffice.org will be shutdown eventually so it would be good to update the address in bugzilla.