You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@openoffice.apache.org by bu...@apache.org on 2015/11/25 04:41:41 UTC
[Issue 126695] New: Tabs that bisect words and result in a new line
result in wonky drag-selection of text.
https://bz.apache.org/ooo/show_bug.cgi?id=126695
Issue ID: 126695
Issue Type: DEFECT
Summary: Tabs that bisect words and result in a new line result
in wonky drag-selection of text.
Product: Writer
Version: 4.2.0-dev
Hardware: PC
OS: Windows 10
Status: UNCONFIRMED
Severity: Normal
Priority: P5 (lowest)
Component: editing
Assignee: issues@openoffice.apache.org
Reporter: pcanseco2011@my.fit.edu
Environment:
Windows 10 64-bit
AOO420m1(Build:9800) - Rev. 1692551
Issue:
If I use the tab key to bisect a word (press tab with the cursor in the middle
of a word), and the tab results in a newline being created, trying to use
drag-selection of the left word segment results in the right-most letter not
being highlighted. Drag-selecting leftwards or rightwards both have the issue.
Animation showing the behavior in action: http://i.imgur.com/knCGqgD.gifv
I press tab in the middle of "maecenas" and try to highlight "maec" but it
gives me issues with the letter c.
Steps to replicate:
- Go to tools > Options > OpenOffice Writer > General
- Set tab stops to something large like 2,50" (inches) to facilitate tabs that
result in new lines.
- Press OK
- Use the tab key to bisect a word (so "elephant" becomes "elep hant" for
example) but the tabbing action has to result on "hant" being on a new line.
- Attempt to highlight "elep" using dragging left or right.
- It will behave oddly during the highlighting process and not quite work
right.
- Attempt to put the cursor after the letter p by clicking to the right of it
- It will place the cursor immediately to the left of the letter p.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126695] Tabs that bisect words and result in a new line
result in wonky drag-selection of text.
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126695
orcmid <or...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |orcmid@apache.org
--- Comment #5 from orcmid <or...@apache.org> ---
Created attachment 85319
--> https://bz.apache.org/ooo/attachment.cgi?id=85319&action=edit
Selecting the tab-preceding text includes the tab
This screen capture of the demonstration test file shows that successfully
selecting the last character before the "cat|tle" tab produces a selection
that ends with the cursor at the beginning of the next line. This is
conceptually in front of the tab, which is what causes the "tle" to be
intended.
This is an odd case. For tabs in the middle of words that do not cause part of
the word to go to a new line, there is a separate wide space that corresponds
to the tab-induced separator between the separated parts of the word. That
separating "space" is independently selectable. In this odd case, the
tab-induced spacing is revealed as the indentation of the second line.
Note that this much, by itself, would not be a significant defect, if the
selection was really "cat" (i.e., everything actually in the text, up to the
but not including the inserted tab. But there's more ...
Demonstrated here also with AOO 4.1.2 on Windows 10. The same behavior is
exhibited with LibreOffice 5.0, indicating that this is a very old behavior
that has been in the code base for many years.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126695] Tabs that bisect words and result in a new line
result in wonky drag-selection of text.
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126695
--- Comment #8 from orcmid <or...@apache.org> ---
Created attachment 85320
--> https://bz.apache.org/ooo/attachment.cgi?id=85320&action=edit
Cut and Paste of the Selection
I did not try dragging the selection anywhere. What I did do was cut the
selection shown in attachment 85319 and paste in front of the "tle" text on the
second line.
Notice that the tab is not part of that selection. The tab is still at the
beginning of the second line. However, a space is brought into the word,
giving us "cat tle". Furthermore, the last work on the first line now has the
problem. The word "word" is only fully selected if the selection extends to
the end of the line, with cursor at the beginning of the second line.
CONFIRMATION: What we have is that a tab insertion that cannot be satisfied
without going to a new line always has the described impact on the character
immediately before the tab insertion. It would obviously be beneficial if
spacing induced by the insertion were separately selectable as it is when the
tab-induced separation is all on a single line. (I did not check what happens
if it is the second of two tab insertions that takes the second insertion to a
new line.)
COLLATERAL PROBLEM: When the word preceding a tab insertion having the
identified behavior is cut/copied and pasted, a blank space is inserted.
Confirmed with AOO 4.1.2 on Windows 10 and also LibreOffice 5.0.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126695] Tabs that bisect words and result in a new line
result in wonky drag-selection of text.
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126695
--- Comment #1 from Pablo Canseco <pc...@my.fit.edu> ---
I tested my same issue in Microsoft Word 2013 and found that this behavior does
not occur there. Selecting tabbed words resulting in a new line behaves as
expected and the cursor can be placed where I click.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126695] Tabs that bisect words and result in a new line
result in wonky drag-selection of text.
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126695
--- Comment #6 from orcmid <or...@apache.org> ---
(In reply to orcmid from comment #5)
> Created attachment 85319 [details]
> Selecting the tab-preceding text includes the tab
That attachment title is incorrect. The tab is not included in the selection,
but the stepping to the next line is.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126695] Tabs that bisect words and result in a new line
result in wonky drag-selection of text.
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126695
Pablo Canseco <pc...@my.fit.edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pcanseco2011@my.fit.edu
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126695] Tabs that bisect words and result in a new line
result in wonky drag-selection of text.
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126695
orcmid <or...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |CONFIRMED
Ever confirmed|0 |1
--- Comment #9 from orcmid <or...@apache.org> ---
The behavior described in this issue statement is confirmed.
1. Meanwhile, it is possible to work around this case so long as the user is
observant.
2. It would also be useful if the handling of tabs in Writer (and probably
everywhere else that paragraph formatting is provided) were clearly identified
in some form of documentation, with some sort of caveat about line-breaking
cases.
3. The inducement of a trailing space as part of the selection is a defect
that is likely curable by not treating soft line breaks as extensions of the
final character on the line before the break of a tab to the next line. There
is no estimate of how much effort or time that might take and when a developer
might turn attention to it.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126695] Tabs that bisect words and result in a new line
result in wonky drag-selection of text.
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126695
--- Comment #4 from Mike Tishman <mt...@my.fit.edu> ---
Created attachment 85316
--> https://bz.apache.org/ooo/attachment.cgi?id=85316&action=edit
Picture snapshot from the document
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126695] Tabs that bisect words and result in a new line
result in wonky drag-selection of text.
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126695
--- Comment #7 from orcmid <or...@apache.org> ---
(In reply to orcmid from comment #6)
> (In reply to orcmid from comment #5)
> > Created attachment 85319 [details]
> > Selecting the tab-preceding text includes the tab
> That attachment title is incorrect. The tab is not included in the
> selection, but the stepping to the next line is.
as if the letter before the tab is extended to where the tab is moved to the
new line along with the remainder of the word.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126695] Tabs that bisect words and result in a new line
result in wonky drag-selection of text.
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126695
Mike Tishman <mt...@my.fit.edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mtishman2013@my.fit.edu
--- Comment #2 from Mike Tishman <mt...@my.fit.edu> ---
Environment used:
Windows 10 64-bit
OpenOffice version 4.1.2
build: AOO412m3(Build:9782) - Rev. 1709696
Configuration:
Tab spacing : Default (0.49''-inch)
I was able to successfully replicate the bug using the steps provided.
Here are the steps I took to replicate the bug.
1. Open a blank document.
2. Type a sentence that reaches at least the end of the page.
3. At the last word on the first line, hit the tab key anywhere in that word.
For example, splitting the word
“cattle” into “cat” and “tle”.
4. Place cursor after the last character on the first line and drag left to
select the last word. The result of this should be everything in the last word
except the last character should be selected. (See attachments.)
5. Similarly, place the cursor in front of the last word and drag right to
select the last word.The result should be the same as the previous step.
The failure looks like OpenOffice does not place the input cursor in the
correct location, resulting in partial
highlighted selections. If you open the attached .odt file and try to move the
cursor to the end of the last letter
on the splitted line, the cursor will go infront of the last letter rather than
behind.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126695] Tabs that bisect words and result in a new line
result in wonky drag-selection of text.
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126695
--- Comment #3 from Mike Tishman <mt...@my.fit.edu> ---
Created attachment 85315
--> https://bz.apache.org/ooo/attachment.cgi?id=85315&action=edit
OpenOfficeWriter test document
--
You are receiving this mail because:
You are the assignee for the issue.