Bug 114899 - VIEWING: smarter positioning of deleted text in track changes mode (considering word boundaries)
Summary: VIEWING: smarter positioning of deleted text in track changes mode (consideri...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Track-Changes
  Show dependency treegraph
 
Reported: 2018-01-07 19:35 UTC by Jaka
Modified: 2019-09-01 11:35 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
How LibO, GDocs, and MSO shows changes (18.78 KB, image/png)
2018-01-08 10:03 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jaka 2018-01-07 19:35:55 UTC
Editing in track changes mode can be quite annoying, since the mishmash is hard to read (cf. bug 46188). One small improvement would be to avoid word "splitting" when rewriting them. 

When a user selects some text and types in something new, the cursor position depends on the side she made the selection from (left: end, right:start of the selection). This is fine if you are replacing anything but the start (left sel.) or end (right sel.) of the string. So no problem if you're changing the middle of the string.

Example: rewriting the "ban" in a RTL selected "banana" with "Hav" will produce: "Hav-ban-ana". Since the two surviving parts are now split, the resulting word is harder to read.

My suggestion is to add a heuristic, wherein the cursor position is overriden (flipped) if it was placed at a word boundary. That would make the example turn out as "-ban-Havana". 

No idea if this is truly appropriate for a VIEWING tag.
Comment 1 Heiko Tietze 2018-01-08 10:03:45 UTC
Created attachment 138949 [details]
How LibO, GDocs, and MSO shows changes

Attachment shows how LibO. GDocs, and MSO handles changes (second line for LibO shows how the actual request could be improved).

Your banana/havana is only part of the question. We should consider addition/deletion/replacement of single/multiple letters at the beginning/middle/end of a word. And the question is also where the changed letter is placed - before or after the new.

My take considering readability and least changes to the text:

Beginning, single & multiple letters: just add, or insert right of the replaced letters (He -> -H-She)
End, single & multiple letters: just add, or insert left of the replaced letters (him -> her-im- | steps -> stepz-s- compare GDocs and LibO in the attachment)
Middle, single letter: insert and place the new letter right of the replaced (behind -> be-h-kind)
Middle, multiple letters: replace the full word and show the new right-hand (queit -> -queit-quiet | quite -> -quiet-quite) (here I would go further than MSO just to make the algorithm simpler)
In case of addition/deletion of single and multiple contiguous letters I would just do the changes but when more than one letter is changed on different positions the full word should be replaced (Havana -> Havan+n+a | Hawana -> Ha-w-vana vs. Hawana -> -Hawana-Havanna 

On the other what we have works not that bad for me. We should also consider the input that might become strange; that needs some testing.
Comment 2 Jaka 2018-01-08 14:54:32 UTC
Well, you're not describing that much more, besides the complete replacement handling, which I agree with. Replacing stuff in the middle of a word is agnostic to cursor position, as one part will look worse in either case.