Description: If the font is set to [Noto Sans JP] and the Vertical of TextAlignment is set to Top and then the optimal row height is set(add 0.0mm), it will look as if it were placed below the row. If vertical alignment is set to bottom, the text will be placed above the Row. Steps to Reproduce: 1.Enter text in cell A1 and Set the font to [Noto Sans JP] 2.Set [Format Cells]-[Alignment]-TextAlignment Vertical: Top 3.Optimal height (add 0.0) Actual Results: The selected font creates a margin above the text, making it appear as if it were placed below Expected Results: Add features like HTML/CSS "line-height:0" Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.6.1 (x64) / LibreOffice Community Build ID: ce99d6a58f9368279ff1495b5b367eb64343b26c CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: threaded
Created attachment 179266 [details] sample file
Created attachment 179267 [details] sample image
This is a topic that was raised in the Japanese category of Ask. I have reprinted the image from there. https://ask.libreoffice.org/t/calc-noto-sans-cjk-jp/75663 The phenomenon itself is reproduced in my environment, but I am refraining from changing the status. Version: 7.3.2.2 (x64) / LibreOffice Community Build ID: 49f2b1bff42cfccbd8f788c8dc32c1c309559be0 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: default; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL Rather than implementing a feature that disables font margins, I think it would be better to improve the method of calculating "Optimal Row Height". Please see the attached image. As is pointed out, in Calc of AOO and LibreOffice, when "Vertical Text Alignment" is "Top" or "Bottom", characters may be out of the cell depending on the font. On the other hand, in MS Excel and Gnumeric, the height of the cell is sufficiently widened so that the contents fit inside the cell.. I think that the calculation method of "Optimal Row Height" is different, and Calc is worse.
Created attachment 179817 [details] Comparison_AOO_LibO_MSExcel_Gnumeric
Reproduced with many fonts, e.g. Noto Kufi Arabic, in a 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 Testing with the linux-64-releases bibisect repository, OOo 3.3 to libreoffice-4.1.6.2 would adapt the row height as expected. This behaviour started in libreoffice-4.2.0.0.beta.
(In reply to Stéphane Guillou (stragu) from comment #5) > Testing with the linux-64-releases bibisect repository, OOo 3.3 to > libreoffice-4.1.6.2 would adapt the row height as expected. This behaviour > started in libreoffice-4.2.0.0.beta. Actually, the difference between 4.1.6.2 and 4.2.0.0.beta1 is that it used to adapt the row height _only if there was a spellcheck underline_ in the text entered. So the behaviour is actually inherited. A bibisect for the 4.2 change would still be interesting, but less important.
Marking as duplicate of earlier bug 143917, I believe it's the same issue. *** This bug has been marked as a duplicate of bug 143917 ***