Description: After entering a text of Thai language into a cell, the cell needs higher row height but Calc doesn't increase cell's height to fit the Thai fonts. Steps to Reproduce: 1. Create a blank Calc file | Press F11 key | Right click on menu 'Default' of tab 'Styles' | Select 'Modify' 2. Select tab 'Font' on box 'Cell Style:Default' 3. Select Garuda/Regular/10 pt/ English(USA) > on 'Western Text Font' 3. Select Garuda/Regular/10 pt/ Thai > on 'CTL Font' 4. Click 'OK' button | Press F11 key 5. Click menu 'File' | Select submenu 'Template' | Select submenu 'Save As Template' 6. Enter 'GarudaEnglish10ptGarudaThai10pt' on Template Name box 7. Select 'My Template' for Template Category 8. Tick on 'Set as default template' 9. Click 'OK' button 10. Close such blank Calc file 11. Create a blank Calc file 12. Enter text with Thai font into cell A1 & A2 Actual Results: Thai font needs higher row, but Calc doesn't increase automatically. Expected Results: Calc must increase row height automatically to fit Thai fonts. Reproducible: Always User Profile Reset: No Additional Info: In order to make row height fit with Thai font text, double click on the bottom line of row name header is needed. Please see attached images.
Created attachment 174346 [details] Cell Style : Default
Created attachment 174347 [details] Enter Thai text into cell A1, the row height doesn't change.
Created attachment 174348 [details] Double click on the bottom line of row name to make cell's height A1 or cell A2 fit In order to make row height fit with Thai font text, double click on the bottom line of row name header is needed.
LibreOffice Community | Version Information : Version: 7.1.5.2 Build ID: 10(Build:2) CPU threads: 4; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 174349 [details] Thai fonts
This issue can be reproduced with simpler steps: 1. Open Calc 2. Change A1 font to e.g. Noto Sans Javanese 3. Write "test" in the cell, press Enter Result: about half the text is hidden. Row height does not adapt to show all the text. Changing vertical alignment to "top" will make it overflow at the bottom of the cell, as shown in bug 148316's attachment 179817 [details] Entering an extra line of text in the cell does adapt the row height somewhat suitably. Behaviour is inherited, but make sure to test with a word that does not trigger the spellcheck underline, as in my tests this _would_ trigger an increase on row height between OOo 3.3 and LO 4.1.6.2. Reproduced in recent trunk build: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5fe2bf914c251009ec4709fa8fdc45c3b53f676b CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
*** Bug 148316 has been marked as a duplicate of this bug. ***
I think this bug is broader than as described. See [this question](https://ask.libreoffice.org/t/adjust-row-height-to-row-cells-wrapped-content-height/59592) that has various duplicates, but no solution. Row heights do not reliably automatically adjust to wrapped plain text content edits even for the simplest default fonts. To reproduce in v24.2.0.3 (and versions going back forever): 1. In a new spreadsheet, add text on multiple columns of the same row. 2. Edit the text on multiple columns to increase their number of lines to various lengths. Row height responsively increases repeatedly. 3. Edit the text on the longer cells to decrease their number of lines. 4. Row height does not responsively decrease. You must double-click between the row number and the row+1 number to adjust the row height to fit.
Clarification: Use words and spaces only (no manual line breaks) to vary cell content lengths in reproducing this bug.
Dear Nukool Chompuparn, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug