Description: When using Google Japanese Input as the input method and composing a vertically written document in Writer, kanji conversion candidates are no longer displayed. Steps to Reproduce: 1.Create New Text Document. 2.Format - Page Style - Page tab. Sets the text direction to right-to-left (vertical). 3.Enter characters using Google Japanese Input. Actual Results: No suggestions are displayed Expected Results: Suggestions are displayed Reproducible: Always User Profile Reset: No Additional Info: Version: 25.2.3.2 (X86_64) / LibreOffice Community Build ID: bbb074479178df812d175f709636b368952c2ce3 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: en-US Calc: CL threaded GoogleJapaneseInput-2.30.5620.0+24.11.9
When you display a dialog that allows text input (for example, search and replace), suggestions will be displayed, and when the focus moves to a search combo box (ctrl+F) that is not a dialog, the suggestions will no longer be displayed. The version where this issue was first noticed: LibreOffice 6.7.6 and 24.2.3 Google Japanese Input 2.29.5370 I don't know what version number was used at the time of 147299, but it worked in 7.4, so there may be a problem with Google Japanese Input. When bisected in the current environment, the following commit was created author Mark Hung commit 5686c1aca40beb9514d40c86b4a3780a8a1334ba vcl: use DWriteTextRenderer for vertical writing. It's really not possible to support vertical writing with old ExTextOutW API, use DWriteTextRenderer in this case. This also get rid of the hacks to prepend '@' in front of the font name when it's for vertical writing. Change-Id: Icf594dd248be35fb101d6c1e296971f1acf56e39 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115017
(In reply to Saburo from comment #1) > LibreOffice 6.7.6 and 24.2.3 Google Japanese Input 2.29.5370 Correctly 7.6.7
Not Reproducible with Version: 7.1.8.1 (x64) / LibreOffice Community Build ID: e1f30c802c3269a1d052614453f260e49458c82c CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL Reproducible with Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 923da8a3855afae1f3f3a5f50d1fec08bbc02438 CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL threaded GoogleIMEJaConverter Version 2.30.5620.0 --- Relevant Ask posts https://ask.libreoffice.org/t/google/118480 --- Below are the conditions that I am aware of for this bug to occur at startup. The Formatting toolbar is displayed. Or Properties in the sidebar is selected. (Even if the sidebar is closed, Properties was selected last.) --- Therefore, the workaround to prevent the failure at startup is the reverse of the above. The Formatting toolbar is hidden. And Properties in the sidebar is not selected. (Even if the sidebar is closed, Properties was not selected last.)
Reproduced. Version: 25.2.4.2 (X86_64) / LibreOffice Community Build ID: 508ff62361999404a9d3590fe47df713b5888744 CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 26100); UI render: default; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: threaded GoogleJapaneseInput-2.30.5620.0+24.11.9 --- Not reproduced. Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: ca6b1677cc3d923f0c13b2253b48a0ea90485b41 CPU threads: 8; OS: Windows 11 X86_64 (build 26100); UI render: default; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: threaded GoogleJapaneseInput-2.30.5620.0+24.11.9 Maybe... fixed??? I don't know...
I have confirmed that it has been fixed. Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: a7f0e7b40fff2238a5cb2bfac750b22d8d5ee15d CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: en-US Calc: CL threaded Thank you, Jonathan Clark Thank you for letting me know, Yasuda-san