Description: I have entered 200 cells of Japanese/Unicode text. The default font is "Microsoft YaHei". It DOES NOT WRAP THE TEXT IN ANY CELL with "Wrap text automatically" selected. The text is all over itself, as if the line height is 1px. If I change the font to "Lucida Sans Unicode" or "Liberation Mono", the text displays OK, BUT THE NAVIGATION BECOMES SO SLOW... 20 SECONDS TO ARROW RIGHT 1 CELL!!!... that the spreadsheet is unusable. Steps to Reproduce: 1.entered 200 cells of Japanese/Unicode text 2.text is unreadable 3.change the font to "Lucida Sans Unicode" 4.navigation is unusable Actual Results: 2.text is unreadable 4.navigation is unusable Expected Results: Unicode text with "Wrap text automatically" is readable, not overlapping itself. Pressing an arrow key will select a neighboring cell in less than 1 second. Reproducible: Always User Profile Reset: Yes Additional Info: worked like normal software
Please attach a sample file.
Disclaimer: I don't speak Japanese, the following advice is from my experience using LibreOffice with Chinese content and very limited knowledge about Windows fonts for East Asian languages. In addition to Miguel's request for a sample file, I think you should also try the following steps: 1. Make sure your LibreOffice has CJK/Asian text support turned on: open Tools > Options dialog, check that "Asian" checkbox in "Language Settings > Languages > Default Languages for Documents" is enabled, and set to "Japanese". 2. Use a proper Japanese font. "Microsoft Yahei" is mainly designed for Chinese, and while it contains most characters used by Japanese, the display is probably going to be sub-optimal. Neither "Lucida Sans Unicode" or "Liberation Mono" contains any Han characters (called "kanji" in Japanese) AFAIK, so LibreOffice has to search in the system's font list to find a font that has them, which is likely the source of the slowness you see. On any ordinary Windows 7 or later (8, 8.1, 10) system, the "Yu Gothic"/"Yu Gothic UI" font that's designed for Japanese should be available, try find and use that one. 3. If you are using the dropdown list widget on the toolbar or sidebar to set the fonts, and things are still not working, try properly set the Asian font in detailed format/style configuration dialog. To do this, use "Format > Cells..." dialog, "Font" tab, you'll see a second "Asian Text Font" dropdown list if you enabled Asian text in step 1. Make sure it's set to "Yu Gothic (UI)". Style configuration dialog has a similar "Font" tab. Hope this helps.
I have found SOMETIMES the performance becomes very slow. I can't reproduce the bug every time, but only about 50% of the time. The UI slowness is when changing cell focus. There are 3 or 4 loops with "Adapting row height" shown in the status bar at the bottom.
(In reply to G from comment #3) > I have found SOMETIMES the performance becomes very slow. I can't reproduce > the bug every time, but only about 50% of the time. > > The UI slowness is when changing cell focus. There are 3 or 4 loops with > "Adapting row height" shown in the status bar at the bottom. The slowness related to not correctly setting a CJK/CTL font and LibreOffice trying to find a matching one for the displayed text is a known problem. See for example bug 131740. Though I haven't yet seen a comprehensive description of a reliably reproducible setup on this Bugzilla. If the QA people and developers can't reproduce the slowdown, we can't help much. Personally I'm more interested in your "text does not wrap in cell" problem described in comment #0. And ideally it should be separately discussed (i.e. separate bug reports). So again, please provide a sample file. I'm marked this bug as NEEDINFO. You can change it back to UNCONFIRMED once you've attached the sample file.
Sorry, I deleted the original file, and now can't reproduce the overlapping text. Possibly the problem only occurred when I upgraded to v 7.1.0.3 and disappeared after I Microsoftishly rebooted. You may as well close this call. I'll post again with evidence if the problem recurs.
(In reply to G from comment #5) > You may as well close this call. I'll post again with evidence if the > problem recurs. Alright, closed. Please don't hesitate to reopen if you encounter this problem again and can provide a sample file.