[upstream] ibus-cangjie in libreoffice cannot type Chinese character at end of line

[Bo-Yin Yang]

I am using LibreOffice Version: 6.0.7.3, in particular I am using LibreOffice Writer.

I am using ibus-cangjie to input Chinese.

I cannot input any Chinese characters when I reach the end of a line on the screen.

The expected behavior is that the typed Chinese character simply spills over to the next line and I can continue to type without a problem.

If I reach the end of the line with half a space (of full-sized Chinese character) available, then I could insert a punctuation mark like 。 or 、 even if I use cangjie codes to input them (and then I can continue normally).

if I reach the end of the line with no space available, then I cannot insert 。 or 、 when I use cangjie codes to input them (in the ibus-cangjie standard input table, 、 = XI)

In neither case I can type a Chinese character like 日, all the typed characters simply disappears from the input queue and is not typed at all. Note that as I type I can see that the candidate Chinese characters according to the cangjie codes I input, they just don't get sent to the application.

when I am at the end of the line, I can type as many spaces as I want and the problem of being unable to type a Chinese character persists.

Finally, the bug only triggers when I am at the end ​of text; if I am inserting in the middle of text, even if I am at the linebreak, I can type normally and naturally.

the attached screenshot shows where I am getting my cursor stuck.

[Marcus Tomlinson (marcustomlinson)]

Hi Bo-Yin Yang, I've just tried this on Bionic using 6.0.7.3 and can't seem to reproduce the issue you're describing (see attached).

Could you please upload the troublesome document here so that I can try reproduce the issue with it.

Thanks!

[Bo-Yin Yang (moscito)]

H​ello, Marcus,

I repeated your actions and can confirm that the same error doesn't occur on a blank document.
If it helps, I am using 18.04 LTS (XUbuntu not regular Ubuntu). I am also using X11, not Wayland.

I attach the problematic document.

Bo-Yin Yang

[Marcus Tomlinson (marcustomlinson)]

Unfortunately I'm still unable to reproduce this (see attached).

Please let me know if there's something specific I need to do.

[Bo-Yin Yang (moscito)]

Hello Marcus,

I am perplexed by the pattern I am getting. On the attached document there is a gray shaded area in item 2. When I open the document, I can't insert Chinese characters on the paragraph at the shaded point. But I could do it at other places. Could you check to see if the same pattern repeats?

[Bo-Yin Yang (moscito)]

my bug occurs at the paragraph, marked "2." and which has a strange gray square in the midst.

[Bo-Yin Yang (moscito)]

I add a screen recording ... somehow sound does not work.

[Marcus Tomlinson (marcustomlinson)]

Hi Bo-Yin, could you please show me the same character sequence working correctly on gedit / Text Editor, and not working on LibreOffice?

[Marcus Tomlinson (marcustomlinson)]

Description:
When at the end of a line in Writer, spaces seem to get inserted with zero width rather than wrapping over to the next line. I.e. x number spaces at the end of a line requires x number of backspaces to move the cursor backward again.

Steps to Reproduce:
1. Open Writer
2. Hold down the spacebar

Actual Results:
When the cursor hits the end of the line, subsequent spaces are entered invisibly at the end of that line.

Expected Results:
When the cursor hits the end of the line it should wrap over to the next.

Reproducible: Always

User Profile Reset: No

Additional Info:

[Marcus Tomlinson (marcustomlinson)]

I'm still unable to reproduce this issue unfortunately, however, in testing this I did stumble across a bug which may actually be the root cause: https://bugs.documentfoundation.org/show_bug.cgi?id=126068

I've linked the upstream bug to this one. Let's give this another try once that is resolved.

[Vstuart-foote (vstuart-foote)]

Confirmed on Windows 10 Home 64-bit en-US with
Version: 6.2.4.2 (x64)
Build ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win;
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

STR

1. New Writer document
2. Page properties, set left & right margins to 3" reduce to a narrow column
3. change font for Paragraph to Liberation Mono
4. enter sequence of spaces to fill to the reduced margins (24 on US 8.5x11 in page)
5. notice the count of characters in the status bar shows 24
6. keep entering spaces, count goes up but text cursor remains at right margin
7. back space will reduce the count of characters, untill cursor starts moving left into paragraph again. Enter additional spaces, text cursor again stops a right margin.
8. save file to Flat XML .fodt
9. open the .fodt in a text editor

Examine the <text:p> and note that the text spans are <text:s text:c "25"> or more, so this looks to be correct ODF 1.2 recording of spaces. And, they are legitimate Unicode U+0020 (not assigned any other glyph with an <Alt>+X toggle)

However with a second paragraph, placed after the first, text cursor movement will pass from the right margin of the first directly to the left margin start of the next paragraph. Ignoring the text span's <text:s text:c> "spaces" beyond the end of the margin.

Not clear it is incorrect (from ODF perspective) but it is weird UX.

@Regina?

[Rb-henschel (rb-henschel)]

I think it is a deficit in the UI, that spaces in the margin are not shown. Word shows all spaces, SoftMaker shows one space in the margin.

[Vstuart-foote (vstuart-foote)]

(In reply to Regina Henschel from comment #2)
> I think it is a deficit in the UI, that spaces in the margin are not shown.
> Word shows all spaces, SoftMaker shows one space in the margin.

So which is wrong, that there is no string wrap to the following line with a text run of spaces reaching the margin--allowing spaces to enter the margin, or that spaces extend beyond the margin and are not show--where all other mixed text spans will wrap.

Wonder what happens with a text run of <text:t>?

[Rb-henschel (rb-henschel)]

I'm not sure about wrapping of spaces. Of cause an editor, which wraps at the window edge, will put the spaces to the new line. But Word and OpenOffice.org had always wrapped so, that the first non-space content is at the starting of the next line. I haven't got Wordperfect and have not used Latex. Perhaps someone knows, how they handle such spaces.

But as long as the line break works as it is now, the spaces should be displayed to make it clear to the user why the cursor and delete key behave like this.

[Vstuart-foote (vstuart-foote)]

(In reply to V Stuart Foote from comment #3)
> Wonder what happens with a text run of <text:t>?

So checked, and a run of <text:tab> are entered one at a time and will be wrapped onto vcl canvas. So just the <text:s> with <text:c> attribute for a text run of spaces is not wrapped--but also it is not visualized to canvas, and we can not advance text cursor into the margin.

Checked and LO wrap behavior matches the MS Word 2016 wrap behavior--that is the wrap will not occur until some non-space text is added, and that text then becomes the start of the next line. Spaces show into the margins, and then after the text causing the wrap.

So our behavior is the same as MS Word, but we don't visualize the additional spaces outside the margins and we can not manipulate the text cursor which holds stuck against the right margin.

[Marcus Tomlinson (marcustomlinson)]

Synchronising bug status with upstream.

[Stephane-guillou-i (stephane-guillou-i)]

Cursor now follows the spaces in the margin and beyond the page with fix for bug 43100, so marking as a duplicate.
Formatting marks don't show beyond the page, but that could be a follow-up bug report if it is considered to be lacking.

*** This bug has been marked as a duplicate of bug 43100 ***