Created attachment 59635 [details] Focus the cell and a number on the bar. I have more screenshots if you want. I have experienced <LibreOffice on Ubuntu> and <OpenOffice.org on Windows> for some time. I have to work on the same documents and there was no problem in use. But today, I removed OpenOffice.org from Windows and replaced with the latest LibreOffice. I opened many documents for testing. It was almost okay like the old one. The problem appears when I open an ODS (Calc spreadsheet) about daily accounting. All cells containing POSITIVE number in CURRENCY format are BLANK! Any pages, any sheets are blank! Currency formulae that result in positive number are also blank too. It shows only negative currency in red. As shown in attachment. I have checked cell format settings but there is no unusual things. However, the blankened numbers are still displayed on the top editting bar. That means the numbers are still there but not to be shown. This is not good if I cannot see any positive money in accounting sheet. Please resolve this severe bug. Secondary issue: why almost text cells are right-aligned by default? The version on Ubuntu nor OpenOffice.org have never occured such issue. Thai language is left-to-right writing like English, so this odd should not have happened. FYI: My files are in Thai language and my computer is set under Thai locale.
Created attachment 59636 [details] My statistical money for years is blank!
Created attachment 59637 [details] I feel frustrated with this sever bug.
Created attachment 59638 [details] This is my original file (.ods) about accounting.
Installed from LibO_3.5.2_Win_x86_install_multi.msi Thai
Reproduced on Linux master 3.6 en_US locale.
@kohei: This regression was introduced with 66778dd58d69426d527edd6ea5d847ce62c950ac as an attempt to fix bug 32530. It happens if the output string for a numeric value starts with a Baht symbol (or any other Thai character for that matter) and the script type of that first character is taken to determine the horizontal alignment.
*** Bug 48372 has been marked as a duplicate of this bug. ***
*** Bug 47541 has been marked as a duplicate of this bug. ***
Eike, is there an easy way to determine the language of an arbitrary string?
I might try i18n::XCharacterClassification::getCharacterDirection() to see if a given string is RTL or LTR, instead of getting its script type. That method might be more reliable.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e57525b61af70a6ee33c26f979e724740cca8655 fdo#48431: More reliable way to check for RTL text.
I used the method I mentioned in comment 10 to determine proper horizontal alignment in case the cell contains RTL text (either full or partial). I've verified that the test document is now rendered correctly, and all the cells that were invisible are now visible.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7a028f6c1e7fb80a22002ad6fed1604dab327e36&g=libreoffice-3-5 fdo#48431: More reliable way to check for RTL text. It will be available in LibreOffice 3.5.3.
*** Bug 48597 has been marked as a duplicate of this bug. ***
Yes, using getCharacterDirection() should be correct.
Fixed.