W3C home > Mailing lists > Public > www-amaya@w3.org > October to December 2006

Re: Bug report: Keep multiple spaces not quite right

From: Robin Whittle <rw@firstpr.com.au>
Date: Fri, 20 Oct 2006 15:40:10 +1000
Message-ID: <4538613A.5080207@firstpr.com.au>
To: Amaya Discussion List <www-amaya@w3.org>

Here are some further bugs with the current "Keep multiple spaces" code.

1 - Backspace or delete from right
----------------------------------

If we have:

<p>abc~~~ def</p>

and the cursor is located to the left of 'd', then backspace removes the
space and leaves just three non-breaking spaces, when it should leave
two non-breaking spaces followed by a space.

The same thing happens if Delete is pressed when the cursor is between
the space and the rightmost non-breaking space.

This may not be a problem, since Amaya and the browser will display the
right number of spaces.  However it has two repercussions, including:

1 - There is undesired, arguably invalid XHTML/HTML code being generated
    invisibly.

2 - The two words will not be broken with soft line-wrap either in Amaya
    or the browser.


2 - Insert on left
------------------

If we have:

<p>abc def</p>

and have the cursor to the right of 'c', pressing Space will create:

<p>abc~ def</p>

which is fine.  If, again, the cursor to the right of 'c', pressing
Space will create:

<p>abc ~ def</p>

which is not what we want, but it is probably not a major problem.

I think that every time a space is inserted or deleted, there needs to
be a system to look at the whole situation, find out how many spaces are
intended by the user and produce the correct XHTML/HTML code.  This
needs to operate differently at the start and end of a line than between
words.


As noted in "Re: Bug report: Copy and paste under Debian", I now have a
Debian version of 9.52 with paste working (at least sometimes).  It's
paste of text with single and multiple spaces behaves the same way as I
described for the Windows version 9.52.

  - Robin
Received on Friday, 20 October 2006 05:40:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:30:52 UTC