Apache OpenOffice (AOO) Bugzilla – Issue 9731
In spread sheet - BiDi text is incorrectly truncated
Last modified: 2013-08-07 15:02:26 UTC
When entering Right to Left text in a spreadsheet that is too narrow to display the entire text, the right thing to do is truncate the first logical part of the string that fits in the cell. Instead, the leftmost visual part is displayed. Logical: TEXT text full rendering should be text TXET truncated to 6 characters, this should be t TXET instead, what is actually displayed is text TX If the entire text is RTL, that leaves essentially only the END of the sentance: THIS IS A HEBREW SENTANCE Visual ECNATNES WERBEH A SI SIHT Truncated: ECNATNES WERBE Instead of: RBEH A SI SIHT
DL->NN: could you please takeover?
I don't quite understand. Do you mean the behavior while editing in the cell, or the display after cell input has been completed?
During the text entering and editing that can be claimed to be the correct behaviour, as you need to see where the cursor is. Once text editing is over, you normally expect to see the begining, rather than the end, of the string. That's when the issue should be considered a Bug. In general, once text editing is done, it is best to first truncate and line break, and only then do character reordering. This is also what the Unicode standard dictates. For text editing, I can refer you to a very good proposed standard at http://imagic.weizmann.ac.il/~dov/Hebrew/logicUI24.htm
Currently, all text that is wider than the cell is extended into the neighboring cells to the right. If those cells aren't empty, the text is truncated and only the left part of it is visible. I assume this is what happened in your case. The long-term solution will be to extend right-aligned text into the cells to the left, and if those aren't empty, truncate so that the right part is visible. This will be a major change and can't be done for version 1.1. For version 1.1, we will still extend only into cells to the right, but if the text has to be truncated because those cells aren't empty, the part of the text that is displayed will depend on the cell's text flow attribute (the right part for right-to-left).
That does not sound like the correct behaviour. In the following example: I WANT a, b, c, d (with uppercase being RTL, and lowercase being LTR) after rendering you will get a, b, c, d TNAW I and the flow direction will be right to left. With your suggestion I will wind up with ...c, d TNAW I while, conceptually and according to the reading order, the right thing is to have ...a, b TNAW I If that does not happen, the sentance gains words in its middle as the truncated area becomes longer and longer. To avoid that you need to change the order. First truncate, then reorder. Problem solved (and no need to depend on paragraph flow direction - it works equally well for both directions). Read two paragraphs above where the following link takes you: http://www.unicode.org/unicode/reports/tr9/tr9-10.html#L1
If you want line breaks at the end of the cell, you can activate the "Line break" flag in the cell attributes on the Alignment tab page. If that flag is not set, the cell content is regarded as one long line, of which only a part is visible. The handling has now been changed so the right instead of the left part is shown in that case, if the cell has the right-to-left writing direction attribute. Discussion with our Arabic testing people has shown that this is seen as an important improvement. The change is in the calc03 child workspace and will be in a future 644 build. Changed files: sc/source/ui/inc/output.hxx 1.6.26.1 sc/source/ui/view/output.cxx 1.17.2.1.2.1 sc/source/ui/view/output2.cxx 1.34.2.1.2.1 sc/inc/global.hxx 1.21.26.1 sc/source/core/data/attarray.cxx 1.10.26.1 sc/source/core/data/document.cxx 1.47.2.1 sc/source/ui/docshell/docsh3.cxx 1.15.28.1
Reopening to change owner.
Reassigning to QA for verification.
Restoring "fixed" state.
Verified in cws_calc03 (will be available as later OOo644)
As mentioned on the qa dev list on March 5th I will close all resolved <wontfix/duplicate/worksforme/invalid> issues. Please see this posting for details.