To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=93503





------- Additional comments from e...@openoffice.org Tue Nov 16 00:06:26 +0000 
2010 -------
@tantai_thanakanok:

1. What exactly does this change in SvNumberformat::ImpGetLanguageType()
   attempt to fix?

-    return (nNum && (cToken == ']' || nPos == nLen)) ? (LanguageType)nNum :
+    return ((cToken == ']' || nPos == nLen)) ? (LanguageType)nNum :


2. I don't like the change made to SvNumberformat::ImpNextSymbol()

+    xub_StrLen pos;
+    if ( ( pos = rString.SearchAscii( "[$-", 0 ) ) != STRING_NOTFOUND )
+    {
+        if ( rString.GetChar(pos+10) == ']' )
+        {
+            if ( rString.GetChar(4) == '0' && rString.GetChar(5) == '7' )
+            {
+                rString.InsertAscii( "[~buddhist]", pos+11 );
+            }
+            if ( rString.GetChar(3) == 'D' )
+            {
+                rString.InsertAscii( "[NatNum1]", pos+11 );
+            }
+        }
+    }

because it tries to search for the "[$-" substring upon each and every call of
the method, completely ignoring the state machine used otherwise in the
method. The case of "[$-" is already detected with case SsGetBracketed and
cToken case '$' and rString.GetChar(nPos) == '-' where eSymbolType
= BRACKET_SYMBOLTYPE_LOCALE is set.

Furthermore, since it always searches from position 0, it detects the
condition multiple times and could insert the new strings each time the
subconditions are met, which currently is not the case because the
LanguageType value is only 16 bit and not a full LCID, hence the result the
calling method reinserts (the scanned value in proper case) is shorter than
the scanned D07xxxx (might in fact be considered a bug) and the problem
doesn't occur.

Anyhow, using the number formatter dialog and setting the Language to Thai and
trying to use the code
[$-D07041E]0
and pressing the green check mark button does not accept the code. If
I understood correctly that should result in
[$-41E][~buddhist][NatNum1]0


3. I still don't agree to the removal or conversion of

-        // The Thai T NatNum modifier during Xcl export.
-        if (rNum.IsSet() && rNum.GetNatNum() == 1 &&
-                rKeywords[NF_KEY_THAI_T].EqualsAscii( "T") &&
-                MsLangId::getRealLanguage( rNum.GetLang()) ==
-                LANGUAGE_THAI)
-        {
-            aPrefix += 't';     // must be lowercase, otherwise taken as 
literal
-        }

This condition happens only if either the user did input such a format or,
more likely, the document was imported from a file originating from a Thai
Excel version. For the latter case in round trip scenarios the 't' has to be
preserved for older Excel versions. This was a requirement of the Thai user
community.

A conversion of NatNum==1 in LANGUAGE_THAI _without_ NF_KEY_THAI_T being set
to "[$-D00041E]" may be fine though.


---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@sc.openoffice.org
For additional commands, e-mail: issues-h...@sc.openoffice.org


---------------------------------------------------------------------
To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org
For additional commands, e-mail: allbugs-h...@openoffice.org

Reply via email to