Summary: | Improve the method for calculating Optimal Row Height for vertical text/Japanese | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Saburo <yosi3260+libre> |
Component: | Calc | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED DUPLICATE | ||
Severity: | enhancement | CC: | himajin100000, jo3emc, stephane.guillou |
Priority: | medium | ||
Version: | Inherited From OOo | ||
Hardware: | All | ||
OS: | All | ||
URL: | https://ask.libreoffice.org/t/calc-noto-sans-cjk-jp/75663 | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 108364 | ||
Attachments: |
sample file
sample image Comparison_AOO_LibO_MSExcel_Gnumeric |
Description
Saburo
2022-04-02 06:38:31 UTC
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 *** |