Description: On LibreOffice calc, All Korean Numeric text and Japanese Modern Numeric text. There is a string display error with numbers above 10 about All Korean Numeric text and Japanese Modern Numeric text on LibreOffice. Such as 10, 11, 100, 101, 1000, 1001 For the example) 1. Korean (Lower) Normal(Excel and Hancell) - LibreOffice 10: 一十|一〇 11: 一十一|一一 100: 一百|一〇〇 101: 一百一|一〇一 1000: 一千|一〇〇〇 1001: 一千一|一〇〇一 2. Korean (Upper) Normal(Excel and Hancell)|LibreOffice 10: 壹拾|壹零 11: 壹拾壹|壹壹 100: 壹百|壹零零 101: 壹百壹|壹零壹 1000: 壹阡|壹零零零 1001: 壹阡壹|壹零零壹 3. Korean (Hangul) Normal(Excel and Hancell)|LibreOffice 10: 일십|일영 11: 일십일|일일 100: 일백|일영영 101: 일백일|일영일 1000: 일천|일영영영 1001: 일천일|일영영일 4. Japanese Modern Numeric text 10: 十|一〇 11: 十一|一一 100: 百|一〇〇 101: 百一|一〇一 1000: 千|一〇〇〇 1001: 千一|一〇〇一 Steps to Reproduce: 1. check calc 2. 3. Actual Results: Such as 10, 11, 100, 101, 1000, 1001 1. Korean (Lower) 10: 一〇 11: 一一 100: 一〇〇 101: 一〇一 1000: 一〇〇〇 1001: 一〇〇一 2. Korean (Upper) 10: 壹零 11: 壹壹 100: 壹零零 101: 壹零壹 1000: 壹零零零 1001: 壹零零壹 3. Korean (Hangul) 10: 일영 11: 일일 100: 일영영 101: 일영일 1000: 일영영영 1001: 일영영일 4. Japanese Modern Numeric text 10: 一〇 11: 一一 100: 一〇〇 101: 一〇一 1000: 一〇〇〇 1001: 一〇〇一 Expected Results: Such as 10, 11, 100, 101, 1000, 1001 For the example) 1. Korean (Lower) 10: 一十 11: 一十一 100: 一百 101: 一百一 1000: 一千 1001: 一千一 2. Korean (Upper) 10: 壹拾 11: 壹拾壹 100: 壹百 101: 壹百壹 1000: 壹阡 1001: 壹阡壹 3. Korean (Hangul) 10: 일십 11: 일십일 100: 일백 101: 일백일 1000: 일천 1001: 일천일 4. Japanese Modern Numeric text 10: 十 11: 十一 100: 百 101: 百一 1000: 千 1001: 千一 Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 157355 [details] Excel 2019 CJK Number[upper, lower, hangul] check Excel file Excel 2019 CJK Number[upper, lower, hangul] check Excel file check numbers above 10, CJK Numeric text.
Created attachment 157356 [details] CJK Numeric number text 10 to 22 on Excel 2019 CJK Numeric number text 10 to 22 on Excel 2019 (Korean, Japanese, Chinese)
Created attachment 157357 [details] CJK Numeric number text 100 to 1004 on Excel 2019 CJK Numeric number text 100 to 1004 on Excel 2019 (Korean, Japanese, Chinese)
Created attachment 157358 [details] CJK Numeric number text 1000 to 1trillion on Excel 2019 CJK Numeric number text 1000 to 1trillion on Excel 2019 (Korean, Japanese, Chinese)
Created attachment 157359 [details] CJK Numeric number text 10 to 32 on LibreOffice 6.3 CJK Numeric number text 10 to 32 on LibreOffice 6.3 (Korean, Japanese, Chinese)
Created attachment 157360 [details] CJK Numeric number text 100 to 1003 on LibreOffice 6.3 CJK Numeric number text 100 to 1003 on LibreOffice 6.3 (Korean, Japanese, Chinese)
Created attachment 157361 [details] CJK Numeric number text 1000 to 1trillion on LibreOffice 6.3 CJK Numeric number text 1000 to 1trillion on LibreOffice 6.3 (Korean, Japanese, Chinese)
With regard to tdf#130193, JA community are discussing the specs of native numbers (or full-width numbers), so this issue would be discussed also.
@DaeHyun Sung -san, let me confirm, you mean this is an import issue from XLSX file? At least in Japanese, LibO unable to recognize Excel's format sub-modifier (I'm not sure this is the right word, though), such as "[DBNum1]Standard" or [DBNum1]0". We have to choose which option should be assumed. In Japanese Excel, Arabic: 1 10 11 [DBNum1]Standard: 一 十 十一 [DBNum1]0: 一 一〇 一一 LibO always choose [DBNum1] to [NatNum1], which has: [NatNum1]:一 一〇 一一 or we can say LibO always assumes "[DBNum1]0" with some historical reason I guess), this is currently design decision. But you expect "一 十 十一", which is from "[DBNum1]Standard". Do you want to claim to change this behavior? NOTE: Now Excel can select "漢数字" as the number format, which always use "[DBNum1]Standard", so the current design seems incompatible with Excel. At least in Japanese, it is a considerable option to change it.
As described in tdf#130193, this issue will be solved in Japanese.
(In reply to Naruhiko Ogasawara from comment #10) > As described in tdf#130193, this issue will be solved in Japanese. I checked the Japanese issue. Now, I'll try to fix the Korean issue,
Ok, If the Korean problem will be solved only with remapping, please tell me the right specification, then I could change my patch. Or you can do by yourself just after my patch will be submitted, or of course, there will be another way.
(In reply to Naruhiko Ogasawara from comment #9) > @DaeHyun Sung -san, let me confirm, you mean this is an import issue from > XLSX file? > > At least in Japanese, LibO unable to recognize Excel's format sub-modifier > (I'm not sure this is the right word, though), such as "[DBNum1]Standard" or > [DBNum1]0". We have to choose which option should be assumed. > > In Japanese Excel, > > Arabic: 1 10 11 > [DBNum1]Standard: 一 十 十一 > [DBNum1]0: 一 一〇 一一 > > LibO always choose [DBNum1] to [NatNum1], which has: > > [NatNum1]:一 一〇 一一 > > or we can say LibO always assumes "[DBNum1]0" with some historical reason I > guess), this is currently design decision. > But you expect "一 十 十一", which is from "[DBNum1]Standard". > Do you want to claim to change this behavior? Yes. I think It seems to be necessary for compatibility both LibreOffice and MS Office. > > > NOTE: Now Excel can select "漢数字" as the number format, which always use > "[DBNum1]Standard", so the current design seems incompatible with Excel. At > least in Japanese, it is a considerable option to change it. I checked both LibreOffice and OpenOffice. Both have 한글숫자 bugs and 漢数字 bugs for Korean. I think that Korean spreadsheet's bug inherited from OOo.
(In reply to Naruhiko Ogasawara from comment #12) > Ok, If the Korean problem will be solved only with remapping, please tell me > the right specification, then I could change my patch. > Or you can do by yourself just after my patch will be submitted, or of > course, there will be another way. Unlike Japanese and Chinese[Simplified, Traditional] environment on Excel, In Korean Situation, Excel exist DBNum1~4. I checked DBNum1~4 series on Excel. DBNum1 1234567890 一十二億三千四百五十六万七千八百九十 DBNum2 1234567890 壹拾貳億參阡四百伍拾六萬七阡八百九拾 DBNum3 1234567890 十２億３千４百５十６万７千８百９十 DBNum4 1234567890 일십이억삼천사백오십육만칠천팔백구십 Also, I checked some Korean Number to Strings on LibreOffice. TEXT(B2;”[natnum1]#”) 123456789012 一二三四五六七八九〇一二 TEXT(B3;”[natnum2]#”) 123456789012 壹貳參四五六七八九零壹貳 TEXT(B4;”[natnum3]#”) 123456789012 １２３４５６７８９０１２ TEXT(B5;”[natnum4]#”) 123456789012 一千二百三十四億五千六百七十八万九千一十二 TEXT(B6;”[natnum5]#”) 123456789012 壹仟貳佰參拾四億五仟六佰七拾八萬九仟壹拾貳 TEXT(B7;”[natnum6]#”) 123456789012 １천２백３십４억５천６백７십８만９천１십２ TEXT(B8;”[natnum7]#”) 123456789012 千二百三十四億五千六百七十八万九千十二 TEXT(B9;”[natnum8]#”) 123456789012 仟貳佰參拾四億五仟六佰七拾八萬九仟拾貳 TEXT(B10;”[natnum9]#”) 123456789012 일이삼사오육칠팔구영일이 TEXT(B11;”[natnum10]#”) 123456789012 일천이백삼십사억오천육백칠십팔만구천일십이 TEXT(B12;”[natnum11]#”) 123456789012 천이백삼십사억오천육백칠십팔만구천십이 As a result, 1. from DBNum to NatNum (import): - DBNum1 -> NatNum4 (Korean Hanja text 한자숫자) - DBNum2 -> NatNum5 (Korean Upper Hanja text 갖은자) - DBNum3 -> NatNum6 (fullwidth Arabic digits with Korean hanja unit of Numbering) - DBNum4 -> NatNum10 (Korean Hangul text) I found the Bug for NatNum6 (I'll change Korean Hangul to Hanja for compatibility) 2. From NatNum to DBNum - NatNum1 -> DBNum1 - NatNum2 -> DBNum2 - NatNum3 -> DBNum3 - NatNum4 -> DBNum1 - NatNum5 -> DBNum2 - NatNum6 -> DBNum3 - NatNum7 -> DBNum1 - NatNum8 -> DBNum2 - NatNum9 -> DBNum4 - NatNum10 -> DBNum4 - NatNum11 -> DBNum4 I'll submit the new mapping rules.
Submitted and apply to LibreOffice core repo.