Description: I always thank you for your contribution. macOS's JapaneseIME provides a function to reconversion text by pressing twice 'かな (kana)' key (Or control+shift+R). But In LibreOffice, I cannot use this function. See also "Undo conversion": https://support.apple.com/en-al/guide/japanese-input-method/jpim10263/6.2.1/mac/10.15 Steps to Reproduce: 1. Input Japanese Text 2. Select It 3. press kana-key twice (or control+shift+R) Actual Results: Nothing happend. Expected Results: appear reconversion text candidates. Reproducible: Always User Profile Reset: Yes Additional Info:
Thank you for reporting the bug. it seems you're using an old version of LibreOffice. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Thank you for giving me an advice. I have updated LibreOffice and checked its behavior. But it was same as before. So, I turned status "UNCONFIRMED". And change version from "6.2.0.3 release" to "6.3.3.2 release". Thanks.
Hi Shibata, the version field is supposed to be the earliest affected version. I take it the bug is still there since you set it to 6.4.0.3? I'm resetting it I'm adding it to the meta bug for Japanese CJK issues, as that hopefully raises visibility for others to confirm If you can give step by step instruction on what keys I should hit on a qwerty-keyboard I could also try to replicate (from the input text step ;))
> the version field is supposed to be the earliest affected version. Ok :) > I take it the bug is still there since you set it to 6.4.0.3? Yes, It still remains. > I'm resetting it Ok. > I'm adding it to the meta bug for Japanese CJK issues, as that hopefully raises visibility for others to confirm Thank you. > If you can give step by step instruction on what keys I should hit on a qwerty-keyboard I could also try to replicate (from the input text step ;)) 1, Open System Preference on macOS 2, Add "Japanese" at "Input Source" in "Keyboard" 3, choose Japanese (icon of 「あ」) at input language in menu bar 4, Copy strings of "オフィス" and paste it into Writer. 5, Select pasted strings and control+shift+R and you will see nothing happened 6, If you do same thing by Textedit, JapaneseIME shows us a reconversion candidates. Thanks.
Thanks! I can confirm it. JapaneseIME is not supported by LO currently. That has also never been the case as far as I can tell in LO 3.3 Version: 7.0.0.0.alpha0+ Build ID: 0cb4f304abf6f8dd6b40eb800788d2fe80581813 CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
> Thanks! I can confirm it. JapaneseIME is not supported by LO currently. OK. I can understand. I hope someday it will be working. Thanks.
Created attachment 200943 [details] Test file Adding test file to reproduce this bug quickly: switch macOS to the Japanese - Kana keyboard, open the attached file in Writer, double-click within the 4 Japanese characters, and press Shift-Control-R (or select the equivalent menu item if the keyboard menu is displayed in the macOS menubar).
So I did some debugging to see if I could figure out why reconversion doesn't work in LibreOffice. What I found is that I was finally able to get it to work with attachment #200943 [details] and the following debug patch. The following debug patch is hardcoded to match the text in attachment #200943 [details] so it isn't a solution but does highlight what would need to be done to fix this bug. Basically, the native "glue" code needs to be wired up to get a native copy of whatever the selected text currently is in the LibreOffice application code. Not sure when I'll have time to figure out how to do that, but leaving this debug patch here so that I don't forget what I've found: diff --git a/vcl/osx/salframeview.mm b/vcl/osx/salframeview.mm index 7ea26a3d4fad..07408d5fa976 100644 --- a/vcl/osx/salframeview.mm +++ b/vcl/osx/salframeview.mm @@ -2305,7 +2305,8 @@ - (NSRange)selectedRange // NSNotFound, -[NSResponder interpretKeyEvents:] will not call // [self firstRectForCharacterRange:actualRange:] and will not display the // special character input method popup. - return ( mSelectedRange.location == NSNotFound ? NSMakeRange( 0, 0 ) : mSelectedRange ); + // Hardcoded selected range as 4 characters for testing tdf#128600 + return ( mSelectedRange.location == NSNotFound ? NSMakeRange( 0, 4 ) : mSelectedRange ); } - (void)setMarkedText:(id)aString selectedRange:(NSRange)selRange replacementRange:(NSRange)replacementRange @@ -2446,7 +2447,8 @@ - (NSAttributedString *)attributedSubstringForProposedRange:(NSRange)aRange actu (void) actualRange; // FIXME - Implement - return nil; + // Hardcoded selected string as for testing tdf#128600 + return [[[NSAttributedString alloc] initWithString: @"オフィス"] autorelease]; } - (NSUInteger)characterIndexForPoint:(NSPoint)thePoint
Created attachment 200944 [details] Snapshot immediately after pressing Shift-Control-R with Japanese - Kana keyboard This snapshot was taken using the debug patch in comment #8 with the test file in attachment #200943 [details].
I have submitted a patch that mostly fixes this bug: https://gerrit.libreoffice.org/c/core/+/185741 However, it has the following limitations that I was unable to implement so I would like some feedback on whether my patch is still useful despite the limitations: 1. "Reverse Conversion" with Japanese keyboards only edits the first non-whitespace chunk of selected text but I don't know how to adjust LibreOffice's selected range to match the substring that the input method will edit. This causes the entire LibreOffice selection to be overwritten by the substring so return nil if there is any whitespace in the selection. 2. "Reverse Conversion" with Japanese keyboards when there is no text selected should select the convertible text chunk nearest to the cursor but I don't know how to retrieve unselected text and set the selection to a chunk of text.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/07f1edfe9d2dd6aaf9c50fdb680f55ddecb96f38 tdf#128600 Implement handling of macOS "Reverse Conversion" menu item It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I have committed my partial fix and the fix should be in tomorrow's (04 June 2025) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS testers: the nightly master build installer does not overwrite any LibreOffice official versions. Instead, it will be installed as a separate application called "LibreOfficeDev" in the /Applications folder. Because this is a "test" build, you will need to do the following steps before you launch the LibreOfficeDev application: 1. Go to the Finder and navigate to the /Applications/Utilities folder 2. Launch the "Terminal" application 3. Paste the following command in the Terminal application window and press the Return key to execute the command: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app