Description: When I try to fix a caption in Calc, the caption jumps to the right and does not start from the same rectangle I clicked. Or it goes down, instead of the same line that is written on it. on that video: (Those bugs appear from the beginning of the video until 3:10) https://youtu.be/1wxdP4XnbAg Steps to Reproduce: 1. see on the video 2. same 3. same Actual Results: see video: Expected Results: see video: Reproducible: Always User Profile Reset: Yes Additional Info: see video:
Ori, could you eliminate the confidential info from your file and upload here?... In order to test on it.
(In reply to BogdanB from comment #1) > Ori, could you eliminate the confidential info from your file and upload > here?... > In order to test on it. i'm sorry but i'm not following. what file exactly?
When you have created the video you have played on a file. That file could be useful to test your results. But if there are confidential data eliminate that data and let just the minimum of text.
Created attachment 165707 [details] Test file
I uploaded the file like you asked
Confirmed. The choice of where to overflow text outside of a cell is inconsistent: When just viewing the spreadsheet, an RTL cell on an RTL sheet overflows to the left; but when editing, it overflows to the right. If we're on the cell of the sheet, then overflowing to the right is not an option, and instead of properly overflowing to the left, the cell text will be wrapped ("overflow down", if you will). Also, it will be left-aligned within the edit box rather than right-aligned, which is inappropriate and confusing but is probably a different bug.
Created attachment 169711 [details] A reduced testcase with integrated explanation A reduced testcase. Just edit any of the cells with Hebrew text. And note that there is nothing special about this document - this bug manifests ubiquitously whenever you enter RTL-language text in an RTL sheet, whose length exceeds the width of the column.
Confirmed on 6.3.6.2
I should also mention that when these cells overflow "due down" (are displayed wrapped for editing) - the wrapping's alignment does not respect the cell being RTL, i.e. the wrapping is left-aligned even though the cell is not explicitly left-aligned. That's a secondary bug.
Dear ori, 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
Comment on attachment 165707 [details] Test file Use the newer test document.
Created attachment 185405 [details] A reduced testcase with integrated explanation Edited the text in the reduced testcase and added a link back to this page.
Created attachment 185406 [details] A reduced testcase with integrated explanation
Sorry for the spam :-) Anyway, bug still manifests with: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ad387d5b984c6666906505d25685065f710ed55d CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: he-IL (en_IL); UI: en-US Calc: threaded
Per the posted reproducer, this was fixed by the following commit. The bug description differs somewhat from the other bugs, so I'm closing as FIXED rather than DUPLICATE. Jonathan Clark committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/057a333d62abd60006434d72c98bbc2cf704f4c4 tdf#65563 sc: Use correct horizontal adjust for cells during editing
(In reply to Jonathan Clark from comment #16) Ok, but - note that, in the reproducer, when we switch directions, the visible part of the text in A6 is not the beginning of the text, nor the end of it (nor the middle). And thus when we double-click to edit, in the LTR sheet, you get a shifting/jerking effect