Issue 78466 - Default currency list box in Arabic localized version dn't display '(' correctly
Summary: Default currency list box in Arabic localized version dn't display '(' correctly
Status: CLOSED FIXED
Alias: None
Product: Internationalization
Classification: Code
Component: BiDi (show other issues)
Version: OOo 2.2.1 RC3
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: stefan.baltzer
QA Contact: issues@l10n
URL:
Keywords:
: 32179 (view as issue list)
Depends on: 32179
Blocks: 79434
  Show dependency tree
 
Reported: 2007-06-14 14:35 UTC by Joost Andrae
Modified: 2013-08-07 15:02 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description Joost Andrae 2007-06-14 14:35:00 UTC 
JA->HDU: this is a duplication of iBIS 111789

Please check the attached snapshot, you will notice:
The ")" in the default currency list box is not displayed correctly.

Karl->HDU: Bidi issue. I could see the problem in Currency list in 'Format
Cells' on SRX645m15 English version (Solaris).

HDU: I have the suspicion that (iBIS) 110225 111760 111777 111789 all have the
same core reason: ICU Bidi vs. Uniscribe Bidi, need to analyze
Comment 1 hdu@apache.org 2007-06-29 16:13:06 UTC 
.
Comment 2 hdu@apache.org 2008-06-04 15:53:44 UTC 
No time till OOo3 => retargeting
Comment 3 Joost Andrae 2008-07-09 11:28:21 UTC 
retarget to 3.1
Comment 4 hdu@apache.org 2009-01-22 11:42:00 UTC 
@tl: SvtLanguageTable::GetString() returns a string that is sensitive to its BiDi context, e.g. "Arabic (Egypt)". This 
name seems to be generated somehow. The problem is that such names do not always look properly in both RTL- 
and LTR-contexts. And for the user of SvtLanguageTable::GetString() there is no way to know in which context it 
would look as expected.

So I suggest to make the string context independent (e.g. by using a different string, or by adding LRE or RLE 
marks). At least the info, for which BiDi context the string is intended, should be available.

I suggest to work with the owner of svx/source/dialog/optgdlg.cxx's OfaLanguagesTabPage class once the problem 
of the context-sensitivity of the returned string is solved.
Comment 5 hdu@apache.org 2009-01-23 10:13:28 UTC 
There seems to be general problem with code which just composes strings by adding other strings 
together (just like in this case where the currency-string, some spaces and the language-string get 
glued together). There are probably many parts of OOo where such compositions have just been 
designed and tested for LTR-strings.

Before the strings got merged into the bigger composition they looked good individually, because they 
often assumed "natural layout" (the first strong character defines the default direction).

I suggest to add a String helper method which adds LRE/RLE...PDF (U+202A/U+202B...U+202C) pairs 
to strings that assume natural layout.This would help owners of string compositing code to keep the 
fixes for the problems simple, unless the composition itself requires reordering of parts.
Comment 6 thomas.lange 2009-01-27 14:42:10 UTC 
*** Issue 32179 has been marked as a duplicate of this issue. ***
Comment 7 thomas.lange 2009-01-27 15:51:51 UTC 
.
Comment 8 thomas.lange 2009-01-27 15:57:24 UTC 
Fixed in CWS vcl99.

Files changed:
- svtools/inc/svtools/langtab.hxx
- svtools/source/misc/langtab.cxx
- svx/source/dialog/optgdlg.cxx
Comment 9 thomas.lange 2009-01-28 10:47:42 UTC 
Now fixed for language list boxes as well.
See the other list boxes in the same dialog or the ones in the
"Format/Character" dialog for example.

Files changed:
- svx\source\dialog\langbox.cxx
Comment 10 thomas.lange 2009-01-29 10:20:04 UTC 
.
Comment 11 stefan.baltzer 2009-01-30 17:04:48 UTC 
Verified in CWS vcl99.
Comment 12 stefan.baltzer 2009-04-27 09:26:04 UTC 
OK in OOO310_m11. Closed.