GNOME Bugzilla – Bug 122090
Broken for Japanese - Fix Italic algorithm in descriptions of function selector
Last modified: 2009-06-27 22:20:35 UTC
Gnumeric will show function selector and user can see the function description. It make the word after @ or # italic, but word recognization happen with ' '(space), so it's broken for Japanese. Normal Japanese sentence don't need space to cut words. For example, something like "* If@inumberisnotavalidcomplexnumber,IMCOTHreturns#VALUE!error.\n" is a valid Japanese sentence. At this time, all chars after @ will be italic. How to Fix: Gnumeric should analize Japanese context to recognize Japanese word when the locale is Japanese, or support <i></i> tag for explicit Italic word. Misc: This bug will also happen for and annoy Korean, Chinese(x2).
1) Yah, for 1.3 we're hoping to use a more coherent format specification for the function docs. 2) How would we analyze the string. Is there a function somewhere that could tell us 'guint8 *find_end_of_word (guint *utf8_text)' ? 3) failing that can you cheat and just stick a space in for now ? Would the resulting japanese be incorrect or just ugly ?
For 3) At this moment, we'll cheat with extra spaces. It's not so wrong but ugly. People will feel the reverse feeling which you have when you see no-space English text above. (drawling dialect) For 2) 1st idea is to use Japanese context analizer like ChaSen (http://chasen.aist-nara.ac.jp/index.html.en). It's big. And not 100% successful. 2nd idea is to try to cut Japanese text to word with character type, English alphabet, ideograph, number, hiragana, katakana, kanji. This is a wild, simple way. But not perfect either. For 1) Best idea.
Reopening -- we have the info needed. Fixing things will be painful, but long overdue.
Could this be worked-around by using unicode's zero-width space?
The new function format uses @{} to mark arguments and those are the only ones that are highlighted by style. So this problem will simply go away when we moved everything to the "new" (if by now old) function format.) *** This bug has been marked as a duplicate of 587156 ***