Apache OpenOffice (AOO) Bugzilla – Issue 23333
Handling wrong for non-breaking, en- and em-space characters
Last modified: 2013-08-07 14:38:26 UTC
OOo's handling of non-breaking space, en-space, and em-space are wrong. OOo currently does not treat non-breaking space (U+00A0) specially. When a piece of text is justified and contains one of more non-breaking spaces, it is easy to see that OOo will not modify the width of non-breaking spaces even when it has to modify the width of normal spaces on the same line. This behaviour makes non-breaking spaces useless in justified environments in OOo. For the en-space and em-space, OOo also does not recognize them. With some fonts (e.g., Lucida Bright from the Java JRE), OOo will display en-spaces and em-spaces correctly, but when printed, apparently-random characters (e.g., "A" or "w" characters) appear instead of the en- or em-spaces.
HI->PL: The behavior in upper paragraph is like it is in our big competitor. The print problem in the paragrah below is reproducible with the font "Lucida Bright" also in Windows.Set OS from Linux to ALL.
pl->hdu: sounds like a font problem to me
Yes, of course it (except for non-breaking space handling) is a "font problem" (in the sense that the characters are missing), but that's not really relevant from a user's point of view. OOo should not do something on the screen to lead the user to believe that there is no problem, and then do something else at printing time that would screw the user up unexpectedly. When composing the document on the screen, the user does not see any problem, or any hint that there would even be a potential problem. Whatever OOo is doing on the screen side that would work around such "font problems", it should also do the same thing on the printing side. Space handling is very important, and for a lot of these special spaces, OOo do not need to have a glyph in a font (e.g., non-breaking space = stretchable normal space width, en-space = width of en-dash, em-space = width of em-dash). If there were some way of inserting more kinds of spaces into OOo (e.g., if X keysyms supported them), I would routinely insert zwj, zwnj, left-to-right override, and right-to-left override into my documents. If a random user sees that the spaces are processed correctly on the screen, he/she would naturally believe that the spaces would be identically processed (correctly) when printed.
HDU->FME: Getting equal justification adjustments for U+0020 and U+00A0 is something for you. I also suggest to use a width-adjusted U+0020 instead of the original U+200x codes.
reassigning.
.
*** Issue 45840 has been marked as a duplicate of this issue. ***
This is an important issue, especially when justifying narrow columns. A non-breaking space is the same as a regular space, except that it does not break at the margin. If justification is turned on, non-breaking spaces should be expanded or contracted to justify the line, just like ordinary spaces. A non-breaking space is not a fixed width space like en-space, em-space, figure- space, etc. WordPerfect has done this right for years, with the additional benefit of micro- justification (expanding or contracting space between individual letters when the word-spacing limits are reached). There is an option to adjust the word/letter spacing limits. The default word-spacing is compress to 60% and expand to 400% of the default space width. After those limits, letter-spacing (tracking) is applied.
This problem makes polish writers unable to automatic remove prepositions from the end of line when text is justified. More about: http://www.oooforum.org/forum/viewtopic.phtml?t=45151
*** Issue 94522 has been marked as a duplicate of this issue. ***
*** Issue 108043 has been marked as a duplicate of this issue. ***
*** Issue 84374 has been marked as a duplicate of this issue. ***
Example iWork Pages text processor from Apple is interpretating the no-break space (U+00A0) correctly – an evidence that it is able. Unfortunately, the developers of OO neglect this bug (and so the defect described) since 2003.
Created attachment 70066 [details] Handling of non-breaking spaces