Description: When writing vertically in Japanese, the character string is displayed on the left outside of the cell. In 7.1.3,these strings were displayed on the upper outside. This error was repaired in 7.2.0.0.alpha1. However, in 7.2.0.0.bata1, the string is now displayed on the left outside of the cell. Steps to Reproduce: 1.Read the attached ods file. 2.The string is displayed on the left outside of the cell. Actual Results: the character string is displayed on the left outside of the cell. Expected Results: The string is displayed on the inside of the cell. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.0.0.beta1 (x86) / LibreOffice Community Build ID: c6974f7afec4cd5195617ae48c6ef9aacfe85ddd CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: threaded
Created attachment 173025 [details] The string is displayed on the left outside of the cell.
Created attachment 173026 [details] SnapShot LO7.2.0Beta1
Created attachment 173027 [details] SnapShot
(In reply to qve00761 from comment #3) > Created attachment 173027 [details] > SnapShot LibreOffice 7.2.0 alpha1 (Normal Case)
When I was investigating this phenomenon on another Windows 10 terminal, the character string disappeared and it crashed. Bug 142950 - Crash in: mergedlo.dll (edit)
Opening your file, I see it on the cell of the top, not to the right. Disabling the option in cell format alignment for Asian layout mode, shows it right.
Created attachment 173037 [details] Vertical writing, with line breaks I want the character string to be displayed in the cell even when Asian layout mode is ON. The original data for attachment 173025 [details] was in xls format. When you read a cell that is set to be written vertically in xls format, Asian layout mode is turned on. In the xls format file, if the character string is broken in the cell in vertical writing, it cannot be displayed normally unless Asian layout mode is ON. For reference, I will attach the sample data of the case where the character string is broken in the cell in vertical writing. In LO7.2.0Beta1, the string is also displayed outside the left side of the cell in this file.
(In reply to m.a.riosv from comment #6) > Opening your file, I see it on the cell of the top, not to the right. > > Disabling the option in cell format alignment for Asian layout mode, shows > it right. If the string is displayed in a protruding state on the outside of the upper side of the cell, I think you are using LO7.1.3 or an earlier version. It have been solved in LO7.2.0Alpha1, but now it is displayed on the outside on the left side in LO7.2.0 Beta1.
Seems the import of xls is even worse with Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 5fb7f66d240fec32a4751d331a215307ad994cbb CPU threads: 4; OS: Windows 10.0 Build 21390; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: threaded. Only the arrow of rebasing the cell is showed. Changing alignment to right shows fine, but the left arrow persist.
Created attachment 173046 [details] Snapshot on 7.2.0.0.beta1 (x86) When you load a file with 7.2.0.0.beta1 (x86), it will be displayed on the outside of the left side of the cell. Reading a file with 7.2.0.0.beta1 (x64) causes the symptom of Comment # 9.
Many improvements have been made since June 2021. Can you try a 7.5 version of LibreOffice to test if you can see this problem?
We need more retesting here, after all this years.
Created attachment 188598 [details] Screnshoot with 7.6.0.1 Looks fine opening the original file without any modification. Version: 7.6.0.1 (X86_64) / LibreOffice Community Build ID: 776eaf34564cbf3f034a0ba1fd1d5c32ff9ccf1c CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
FWIW, I cannot repro in versions 7.1.0.3, 7.2.7.2, so it is no surprise I cannot repro in current Dev 24.2 either. Having said that, perhaps the specific (ja) fonts might be required in order to replicate the problem.
Dear qve00761, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear qve00761, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp