Issue 23333 - Handling wrong for non-breaking, en- and em-space characters
Summary: Handling wrong for non-breaking, en- and em-space characters
Status: ACCEPTED
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: OOo 1.1
Hardware: PC All
: P3 Trivial with 37 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
: 45840 84374 94522 108043 (view as issue list)
Depends on:
Blocks:
 
Reported: 2003-12-09 08:14 UTC by acli
Modified: 2013-08-07 14:38 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Handling of non-breaking spaces (12.70 KB, application/pdf)
2010-06-18 00:12 UTC, dohnp5a1
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description acli 2003-12-09 08:14:02 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.
Comment 1 h.ilter 2003-12-09 11:51:01 UTC
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.
Comment 2 philipp.lohmann 2004-01-14 17:31:41 UTC
pl->hdu: sounds like a font problem to me
Comment 3 acli 2004-01-14 17:48:47 UTC
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.
Comment 4 hdu@apache.org 2004-01-15 09:10:55 UTC
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.
Comment 5 hdu@apache.org 2004-01-16 11:22:37 UTC
reassigning.
Comment 6 frank.meies 2004-01-19 08:16:26 UTC
.
Comment 7 lohmaier 2005-06-08 19:28:14 UTC
*** Issue 45840 has been marked as a duplicate of this issue. ***
Comment 8 pesala 2006-10-10 20:39:36 UTC
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.
Comment 9 pmad 2006-10-11 15:15:30 UTC
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
Comment 10 Regina Henschel 2008-10-01 11:05:12 UTC
*** Issue 94522 has been marked as a duplicate of this issue. ***
Comment 11 Regina Henschel 2010-01-03 11:22:01 UTC
*** Issue 108043 has been marked as a duplicate of this issue. ***
Comment 12 Regina Henschel 2010-01-03 11:23:29 UTC
*** Issue 84374 has been marked as a duplicate of this issue. ***
Comment 13 dohnp5a1 2010-01-07 21:22:16 UTC
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.
Comment 14 dohnp5a1 2010-06-18 00:12:44 UTC
Created attachment 70066 [details]
Handling of non-breaking spaces