[upstream] white spaces disappear beyond right margin

[MagicNeophyte]

Binary package hint: openoffice.org

When the very end of a line (right margin) is reached, white spaces entered are not moved to the second line, but hidden from view. (Switch on non-printing characters to view.)
White spaces entered at the very beginning of an automatically line-wrapped second line are hidden beyond the end of the right margin of the previous line, only to reappear when the previous line is broken manually by a hard or soft return. When navigating with the arrow keys at the end of a line, the unseen presence of hidden white spaces may be noticed (You have to tap the arrow key as many times as there are spaces, in order to get the cursor to visibly move again).

To reproduce: Switch on non-printing characters. Enter a full line of text, right up to the right margin. Press enter to go to the line below. Input ten white spaces. Move to the beginning of the second line and press backspace. The spaces will disappear beyond the right margin, but you can still navigate them with the arrow keys.

This bug has been in previous versions of OO, and I have reported it before to the Open Office bugzilla site, a year or so ago. There turned out to be, I believe, five different related bug reports in the Open Office bug database. This bug breaks the WYSIWYG principle and also affects Tables. When a series of white spaces fill up more than one line in a table cell, they become invisible, beyond the right boundary of the cell.

Unfortunately, I do not have the knowledge to fix this bug. I think it has something to do with the line wrapping functions in OO. When more than one consecutive white space is detected, they should be put on the next line. A single space at the end of a line may conveniently be hidden when it cannot be displayed before the margin, but multiple spaces must be detected and moved to the second line.

Thanks for taking the time to read this. I know you are probably doing this on a voluntary basis, and I am grateful for that. But maybe this very basic text input bug can be given slightly higher priority. I would think many users run into problems with this, especially in large manually input documents (theses) it can be a real pain.

[Frank-loehmann (frank-loehmann)]

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

[lcn (lcn)]

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.

[Frank-loehmann (frank-loehmann)]

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

[lcn (lcn)]

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

[Lars-o-hansen (lars-o-hansen)]

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

[Lutz-hoeger (lutz-hoeger)]

added keyword Q-PCD

[Alex Brooks (askoorb)]

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

[lcn (lcn)]

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

[Alex Brooks (askoorb)]

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

[Lohmaier (lohmaier)]

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

[Michael-cziebalski-d (michael-cziebalski-d)]

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

[James-botte (james-botte)]

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

[Lohmaier (lohmaier)]

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

[Alex Brooks (askoorb)]

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

[MagicNeophyte (magic-neophyte)]

I found the bugzilla.openoffice.org bug number, which is 20878

see: http://qa.openoffice.org/issues/show_bug.cgi?id=20878

There are tons of comments that more narrowly define the problem!

Another issue that is claimed to be related is 64201

see: http://qa.openoffice.org/issues/show_bug.cgi?id=64201

Hope this helps.

[James-botte (james-botte)]

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.

[Mathias-bauer (mathias-bauer)]

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.

[James-botte (james-botte)]

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.

[Tj-o (tj-o)]

@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/

[NoBugs! (luke32j)]

Very annoying bug, I hope it can be fixed soon.

[Swink (tomabray)]

I reported this too. You're right. Enabling the non-printing
characters is a good way to see it. If I make a line of type and then
near the end of the line start hitting the space bar, a few space
characters appear but then after about 5, they all disappear and the
cursor will not move until I hit a letter, which then appears at the
left-most margin on the next line, even if I have hit 20 spaces.

Or try this: Open a new doc and hit the space bar. You will be stopped
when you hit the end of the line. Actually the cursor bounces back to
the beginning of the line.

Peace,
Tom

On Wed, Mar 4, 2009 at 12:47 PM, NoBugs! <email address hidden> wrote:
> Very annoying bug, I hope it can be fixed soon.
>
> --
> [Upstream] [hardy] white spaces disappear beyond right margin
> https://bugs.launchpad.net/bugs/129403
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in The OpenOffice.org Suite: Confirmed
> Status in “openoffice.org” source package in Ubuntu: Triaged
>
> Bug description:
> Binary package hint: openoffice.org
>
> When the very end of a line (right margin) is reached, white spaces entered are not moved to the second line, but hidden from view. (Switch on non-printing characters to view.)
> White spaces entered at the very beginning of an automatically line-wrapped second line are hidden beyond the end of the right margin of the previous line, only to reappear when the previous line is broken manually by a hard or soft return. When navigating with the arrow keys at the end of a line, the unseen presence of hidden white spaces may be noticed (You have to tap the arrow key as many times as there are spaces, in order to get the cursor to visibly move again).
>
> To reproduce: Switch on non-printing characters. Enter a full line of text, right up to the right margin. Press enter to go to the line below. Input ten white spaces. Move to the beginning of the second line and press backspace. The spaces will disappear beyond the right margin, but you can still navigate them with the arrow keys.
>
> This bug has been in previous versions of OO, and I have reported it before to the Open Office bugzilla site, a year or so ago. There turned out to be, I believe, five different related bug reports in the Open Office bug database. This bug breaks the WYSIWYG principle and also affects Tables. When a series of white spaces fill up more than one line in a table cell, they become invisible, beyond the right boundary of the cell.
>
> Unfortunately, I do not have the knowledge to fix this bug. I think it has something to do with the line wrapping functions in OO. When more than one consecutive white space is detected, they should be put on the next line. A single space at the end of a line may conveniently be hidden when it cannot be displayed before the margin, but multiple spaces must be detected and moved to the second line.
>
> Thanks for taking the time to read this. I know you are probably doing this on a voluntary basis, and I am grateful for that. But maybe this very basic text input bug can be given slightly higher priority. I would think many users run into problems with this, especially in large manual...

[Scotz-oo (scotz-oo)]

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

[Eric-savary (eric-savary)]

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

[NoBugs! (luke32j)]

I have this problem also
How can this be fixed?

[Chris Cheney (ccheney)]

NoBugs!

No one claimed it was fixed, perhaps you don't know how to read bug statuses?

[Eric-savary (eric-savary)]

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

[De-logics (de-logics)]

Issue 98566 sounds similar?

[Mathias-bauer (mathias-bauer)]

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

[Alter4 (alter4)]

Are any news?

[Jack Leigh (leighman)]

Yes! Really annoying, and has hung around far too long =D

[MagicNeophyte (magic-neophyte)]

Confirmed, not fixed in Open Office 3.1 from launchpad PPA (jaunty).

But I have the impression some cosmetic tweaks have made it easier to deal
with.

magic-neophyte

> NoBugs!
>
> No one claimed it was fixed, perhaps you don't know how to read bug
> statuses?
>
> ** Summary changed:
>
> - [Upstream] [hardy] white spaces disappear beyond right margin
> + [upstream] white spaces disappear beyond right margin
>
> --
> [upstream] white spaces disappear beyond right margin
> https://bugs.launchpad.net/bugs/129403
> You received this bug notification because you are a direct subscriber
> of the bug.
>
>

[Lohmaier (lohmaier)]

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

[Lohmaier (lohmaier)]

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

[Jack Leigh (leighman)]

7 years?
About time this was fixed, please!

[Sense Egbert Hofstede (sense)]

Thank you for taking the time to report this to the One Hundred Paper Cuts project. However, as you indicated yourself this issue is quite a complex bug report. A paper cut, in contrast, is a small usability issue that is easy to fix. This is most certainly not easy to fix, considering the first bug report on the OpenOffice tracker was from 2005. Therefore I'm marking this as Invalid for the One Hundred Paper Cuts project.

Don't worry, though, I'm NOT marking this Invalid as a bug report, I'm just declining it as a paper cut.

[mclay (michael-j-mclay)]

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.

[Scotz-oo (scotz-oo)]

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

[Toddandmargo-e (toddandmargo-e)]

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

[Scotz-oo (scotz-oo)]

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

[Toddandmargo-n (toddandmargo-n)]

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

[Toddandmargo-e (toddandmargo-e)]

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

[Libreoffice-z (libreoffice-z)]

Platform / OS due to OOo report.

[Gang65-x (gang65-x)]

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.

[Sasha-libreoffice (sasha-libreoffice)]

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

[Sasha-libreoffice (sasha-libreoffice)]

on LibreOffice 3.3.1 still exist

[Gang65-x (gang65-x)]

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?

[Gang65-x (gang65-x)]

Created attachment 76239
screenshot of the ooo with fix

[Gang65-x (gang65-x)]

Created attachment 76240
screenshot of the ooo without fix

[Gang65-x (gang65-x)]

Created attachment 76241
test file

[NoBugs! (luke32j)]

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.

[NoBugs! (luke32j)]

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

[Tj-o (tj-o)]

@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!

[Gang65-x (gang65-x)]

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

[Scotz-oo (scotz-oo)]

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~

[Gang65-x (gang65-x)]

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

[Gang65-x (gang65-x)]

Created attachment 76277
test file 2

[Gang65-x (gang65-x)]

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?

[Mathias-bauer (mathias-bauer)]

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

[Scotz-oo (scotz-oo)]

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.

[Scotz-oo (scotz-oo)]

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~

[853036708-5 (853036708-5)]

Comment was deleted by admin

[Bartosz Kosiorek (gang65)]

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

[Libreoffice-0 (libreoffice-0)]

(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!

[Gang65-x (gang65-x)]

Created attachment 76416
Final , tested patch

Feel free to test the patch.

[Gang65-x (gang65-x)]

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

[Cedric-bosdonnat-ooo (cedric-bosdonnat-ooo)]

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

[Marius B. Kotsbak (mariusko)]

This is now fixed upstream in commit 4ee4892968d3e42efc03c1158bebfcdd7bb3249. It is not in any releases yet, but it cherry-picks nice to 3.3.2 version, so producing a patch for Ubuntu should be trivial.

[Ahmed Shams (ashams)]

Fix Released in ​LibreOffice Productivity Suite as well as in HundredPaperCuts

[Marius B. Kotsbak (mariusko)]

Hmm, but it is not fixed in Ubuntu yet, right?

[Björn Michaelsen (bjoern-michaelsen)]

[This is an automated message.]
There are no new official OpenOffice.org releases in Ubuntu packaging anymore => Won't Fix

If the problem persists, please mark this bug as "also affects project Libreoffice" or "also affects distribution Libreoffice (Ubuntu)" if that has not happened already.

Please leave references to upstream OpenOffice.org bugs in place to allow cross pollination.

[Björn Michaelsen (bjoern-michaelsen)]

Fix commited upstream, will be released with 3.5 -- http://cgit.freedesktop.org/libreoffice/writer/commit/?id=4ee4892968d3e42efc03c1158bebfcdd7bb3249e

[Pfg (pfg)]

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.

[Gang65-x (gang65-x)]

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?

[Pfg (pfg)]

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

[Björn Michaelsen (bjoern-michaelsen)]

Fixed as per upstream 3.5.0 released with precise.

[Marius B. Kotsbak (mariusko)]

I still reproduce this in precise (LO 3.5.2.2).

[Marius B. Kotsbak (mariusko)]

Maybe this one: https://bugs.freedesktop.org/show_bug.cgi?id=48654

[Isokumma (isokumma)]

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