[Libreoffice-bugs] [Bug 69109] Editing: RTL character string causes (left to right) numerics to flip order to also be RTL

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=69109

braunmax at yahoo.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|NOTABUG                     |---

--- Comment #11 from braunmax at yahoo.com ---
Dear Khaled Hosny,
Thank you for giving attention to this bug, which I highly appreciate.

I unfortunately need to add the following, which may allow the status to be
changed back to an active bug:
(i) All editing is done with an LTR keyboard (English (US) keyboard, English
(UK) as prime language). The only secondary keyboard is the English (UK)
keyboard. I have set no secondary keyboard and CTL enabling changes little of
this behaviour, in fact. Some value is obtained by Insert->RTL (or LTR) code.
(ii) Even worse than the simple form of the bug I have registered is the effect
that if spaces between the numerals are removed, except for a space placed as
thousand marker between 123 and 456 the behaviour on deleting the "I" is even
more inconsistent, and the number changes to 456 123.... the meaning thus
changes due to the flip. This cannot be anything but a bug.
(iii) The call to limit the correction/fix to "standard" of unicode is a
divergence, with this argument notepad would be the only editor, ascii or
ebcdic code our only character lists.
(iv) The conflation of what is expected of a WYSIWIG editor, and the properties
of a character set is unhelpful. With a pointer device like a mouse, one
expects an insertion point to be transparently placeable, and with the LTR
keyboard one expects to be able to insert or delete a character as needed,
without changing the visual rendition of other characters which are already
present. WYSIWIG editors DO insert formatting codes and overrides
transparently, and must do so. A hex level editor of course is something
different, as one had in the "code view" of wordperfect. The only final
limitation is open document text format type 1.2.
(v) One cannot rely on the keyboard choice only to affect behaviour either,
what about Japanese, which functions both LTR horizontally, and Vertically
downwards, left to right wrapping, often uses arabaic numerals etc.
(vi) The left and right pointer keys, and the backspace and forward delete keys
should not switch around in a single keyboard [alternate keyboards specific to
a language may be different]- the danger is that a single character in a
complex string or paragraph may not then be reachable and deletable... I can
also produce even that faulty behaviour.

Thus - not only does this bug (which affects all RTL/LTR/CTL algorithms) open a
can of worms (as you have warned) - it has opened a veritable plague of
parasites. And a solution may be found as we progress further in language and
character flexibility... as perhaps LO 6.1 may induce.

For now this bug should remain as needing attention, and potentially be
elevated to a higher priority. It is either an implementation flaw, or violates
a design assumption, in both cases a bug.

I hope this reply does gain your support.    

Regards,

Max

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20180428/96e42296/attachment-0001.html>