[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?

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