Bug 82116 - CJK: Font change does not update composition string immediately
Summary: CJK: Font change does not update composition string immediately
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other macOS (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: CJK
  Show dependency treegraph
 
Reported: 2014-08-04 04:40 UTC by Matthew Francis
Modified: 2025-04-04 21:53 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Francis 2014-08-04 04:40:29 UTC
On OSX 10.9.4 / LO 4.3.0.4 release:

Steps to reproduce:
1. Create a new Writer document
2. Start typing any Japanese text with the 'Kotoeri' - 'Hiragana' input method. For instance, 'aaaaaaaaaaaaaaaaa' (which will produce the text 'ああああああああああああああ')
4. Without confirming the input conversion (i.e. without pressing 'Return'), select a new font from the font dropdown

Expected result:
The new font is immediately applied to the selected mid-conversion text

Actual result:
The new font is applied to the selected mid-conversion text *only after another character is entered*


This was discovered while reporting bug 82115 - it seems like the issues are separate but I could be wrong about that

I have only observed this in Writer for the reason that changing the font mid-conversion in a spreadsheet or presentation appears to have no effect at all on the selected text. Should this inconsistency be yet another bug?
Comment 1 Yousuf Philips (jay) (retired) 2014-08-05 05:48:00 UTC
Hi Matthew,

Thanks for another bug and the simple instructions. Mac team added.
Comment 2 Alex Thurgood 2014-10-15 15:18:32 UTC
Confirming on OSX 10.9.5

There always seems to be one character extra, no matter what the font. This might have something to do with the input checking code which has to decide whether the combination of letters entered is a valid character ?
Comment 3 Matthew Francis 2015-01-19 05:35:05 UTC
Occurs all the way back to 3.3.0 (and still in 4.4.0.2)

Setting Version to "Inherited from OOo"
Comment 4 QA Administrators 2016-02-21 08:38:13 UTC Comment hidden (obsolete)
Comment 5 QA Administrators 2017-03-06 16:11:16 UTC Comment hidden (obsolete)
Comment 6 QA Administrators 2019-12-03 14:18:15 UTC Comment hidden (obsolete)
Comment 7 QA Administrators 2021-12-03 04:31:47 UTC Comment hidden (obsolete)
Comment 8 QA Administrators 2023-12-04 03:16:23 UTC Comment hidden (obsolete)
Comment 9 Jonathan Clark 2025-04-04 21:53:35 UTC
Note that the Kotoeri IME was discontinued with OS X Yosemite (10.10.5).

I cannot reproduce this bug with

Version: 24.8.1.2 (AARCH64) / LibreOffice Community
Build ID: 87fa9aec1a63e70835390b81c40bb8993f1d4ff6
CPU threads: 12; OS: macOS 15.4; UI render: default; VCL: osx
Locale: en-CA (en_CA.UTF-8); UI: en-US
Calc: threaded

It seems any action that would change the font or style now automatically dismisses the candidate list.