[upstream] white spaces disappear beyond right margin

(EaseOfUse-FL-03)

Source
User

Category
Text displaying

Product Requirement
Show space at end of line

Customer Need/Problem
Writer: User does not know if there is already a space entered at the end of a line.

Comment
OOo ID 2197

Eng Effort
-

Eng Owner
Frank Loehmann / Frank Meies

Product Concept
Show spaces at the end of a line.

Functional Specification
-

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 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
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
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.

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...

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 th...

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 b...

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-compli...

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
Justified paragraph showing n spaces at the end

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

Created attachment 52999
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
file showing an unwished linebreak

Created attachment 57125
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,

This is an EIGHT year old bug that got carried over from Open Office:

http://www.openoffice.org/issues/show_bug.cgi?id=20878
Opened: Wed Oct 8 11:23:00 +0000 2003

Basically, Writer does not show/allow spaces at the end of a line on text. It does not wrap spaces either.

Please fix this!

Many thanks,
-T

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

Platform / OS due to OOo report.

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.

It problem is on windows and linux, 32 and 64. Last tested on Libreoffice 3.3.0.

on LibreOffice 3.3.1 still exist

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
screenshot of the ooo with fix

Created attachment 76240
screenshot of the ooo without fix

Created attachment 76241
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
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
OO.o with second version of the patch

Created attachment 76277
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
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
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 45888
Patch to display non printable characters

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).

(In reply to comment #4)
> Created an attachment (id=45888) [details]
> Patch to display non printable characters

Please drop a note on the developer mailing list of this patch. Otherwise it won't reach the right developer. Thanks!

Created attachment 76416
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).

Pushed in master (target 3.5):
http://cgit.freedesktop.org/libreoffice/writer/commit/?id=4ee4892968d3e42efc03c1158bebfcdd7bb3249e

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.

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