[Libreoffice-commits] core.git: svl/qa svl/source
svl/qa/unit/svl.cxx| 91 ++
svl/source/numbers/zformat.cxx | 96 -
2 files changed, 111 insertions(+), 76 deletions(-)
New commits:
commit 9efd7cd637d9d882f2fc8277b657ec117c591e80
Author: Naruhiko Ogasawara
AuthorDate: Wed May 6 20:55:49 2020 +0900
Commit: Eike Rathke
CommitDate: Mon May 25 22:51:22 2020 +0200
tdf#130193: Asian Excel-Calc number format interop
remap NatNum - DBNum in Japanese/Chinese to improve
Excel interoprability
from DBNum to NatNum (import) in ja/zh:
- DBNum1 -> NatNum4 (modern long Kanji text)
- DBNum2 -> NatNum5 (traditional long Kanji text)
- DBNum3 -> NatNum3 (fullwidth Arabic digits)
from NatNum to DBNum (export) in ja:
- NatNum1 -> DBNum1
- NatNum2 -> DBNum2
- NatNum3 -> DBNum3
- NatNum4 -> DBNum1
- NatNum5 -> DBNum2
- NatNum6 -> DBNum3
- NatNum7 -> DBNum1
- NatNum8 -> DBNum2
- NatNum9 -> (DBNum0, as Arabic)
in zh, nothing change about export.
It also partially solves the issue tdf#130140
(about Japanese, not Korean)
To do this, more data-drivened MapDBNumToNatNum() and
MapNatNumToDBNum() in svl/source/numbers/zformat.cxx
By mapping "NatNum - DBNum" to a table using map and array, it
makes the specification for each language more understandable
The new test cases are also included in svl/qa/unit/svl.cxx
Change-Id: I34a70d970ef2e46c1b3db5db1c397ab89c056191
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94376
Tested-by: Jenkins
Reviewed-by: Eike Rathke
diff --git a/svl/qa/unit/svl.cxx b/svl/qa/unit/svl.cxx
index fc541861f182..80be2b2af79a 100644
--- a/svl/qa/unit/svl.cxx
+++ b/svl/qa/unit/svl.cxx
@@ -1453,6 +1453,97 @@ void Test::testUserDefinedNumberFormats()
checkPreviewString(aFormatter, sCode, M_PI, eLang, sExpected);
#endif
}
+{ // tdf#130193 tdf#130140 Native Number Formats mapping for Chinese
(Traditonal), Japanese, Korean
+// -- Traditional Chinese: DBNum1 -> NatNum4, DBNum2 -> NatNum5,
DBnum3 -> NatNum3
+
+// DBNum1 -> NatNum4: Chinese lower case text for 123456789
+// 一億二千三百四十五萬六千七百八十九
+sExpected =
u"\u4e00\u5104\u4e8c\u5343\u4e09\u767e\u56db\u5341\u4e94\u842c\u516d\u5343"
+u"\u4e03\u767e\u516b\u5341\u4e5d ";
+sCode = "[NatNum4][$-0404]General\\ ";
+checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
+sCode = "[DBNum1][$-0404]General\\ ";
+checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
+
+// DBNum2 -> NatNum5: Chinese upper case text
+// 壹億貳仟參佰肆拾伍萬陸仟柒佰捌拾玖
+sExpected =
u"\u58f9\u5104\u8cb3\u4edf\u53c3\u4f70\u8086\u62fe\u4f0d\u842c\u9678\u4edf"
+u"\u67d2\u4f70\u634c\u62fe\u7396 ";
+sCode = "[NatNum5][$-0404]General\\ ";
+checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
+sCode = "[DBNum2][$-0404]General\\ ";
+checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
+
+// DBNum3 -> NatNum3: fullwidth text
+// １２３４５６７８９
+sExpected = u"\uff11\uff12\uff13\uff14\uff15\uff16\uff17\uff18\uff19 ";
+sCode = "[NatNum3][$-0404]General\\ ";
+checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
+sCode = "[DBNum3][$-0404]General\\ ";
+checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
+
+// -- Japanese: DBNum1 -> NatNum4, DBNum2 -> NatNum5, DBnum3 -> NatNum3
+
+// DBNum1 -> NatNum4: Japanese modern long Kanji text for 123456789
+// 一億二千三百四十五万六千七百八十九
+sExpected =
u"\u4e00\u5104\u4e8c\u5343\u4e09\u767e\u56db\u5341\u4e94\u4e07\u516d\u5343"
+u"\u4e03\u767e\u516b\u5341\u4e5d ";
+sCode = "[NatNum4][$-0411]General\\ ";
+checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
+sCode = "[DBNum1][$-0411]General\\ ";
+checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
+
+// DBNum2 -> NatNum5: traditional long Kanji text
+// 壱億弐阡参百四拾伍萬六阡七百八拾九
+sExpected =
u"\u58f1\u5104\u5f10\u9621\u53c2\u767e\u56db\u62fe\u4f0d\u842c\u516d\u9621"
+u"\u4e03\u767e\u516b\u62fe\u4e5d ";
+sCode = "[NatNum5][$-0411]General\\ ";
+checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
+sCode = "[DBNum2][$-0411]General\\ ";
+checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
+
+// DBNum3 -> NatNum3: fullwidth Arabic digi
Re: C++ question: literal form of std::map
2020年5月15日(金) 15:36 Stephan Bergmann :
>
> On 14/05/2020 20:59, Naruhiko Ogasawara wrote:
> > 2020年5月14日(木) 22:37 Stephan Bergmann :
> >> On 14/05/2020 12:40, Naruhiko Ogasawara wrote:
> >>> --
> >>> static const std::map>
> >>> tblDBNumToNatNum
> >>> = { { primary(LANGUAGE_CHINESE),{ 4, 5, 6, 0 } },
> >>> { primary(LANGUAGE_JAPANESE), { 4, 5, 3, 0 } },
> >>> { primary(LANGUAGE_KOREAN), { 1, 2, 3, 9 } } };
> >>> --
> >>>
> >>> The compiler claimed:
> >>> --
> >>> Error (active) E0289 no instance of constructor "std::map<_Kty, _Ty,
> >>> _Pr, _Alloc>::map [with _Kty=LanguageType, _Ty=std::array >>> 4U>, _Pr=std::less,
> >>> _Alloc=std::allocator >>> std::array>>]" matches the argument list
> >>> --
> >>
> >> There should be no reason that that does not work. Probably an issue
> >> with whatever specific compiler you are using?
> >>
> >
> > I'm not sure but I'm using latest LODE in Windows 10, with Visual Studio
> > Community 2019 V16.5.5, with MSVC v142 + Clang 9.0.0.
> > And my build has branched from master:
> > 0b81aaa36b5b78e208c5cc2cd36b4906b8d636a6
>
> Works fine for me with VS 2019 16.5.4. Maybe you should upload your
> full change to Gerrit.
>
Not sure this is a right way to do, anyway I uploaded my commit into Gerrit
as work in progress:
https://gerrit.libreoffice.org/c/core/+/94354
The last commit there breaks my build...
I am guessing that this issue is coming from my environment, so I tried
to re-install my VS2019 community, but no lack for now.
Best regards,
--
Naruhiko NARU Ogasawara (naru...@gmail.com)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: C++ question: literal form of std::map
Hi Stephan, *
2020年5月14日(木) 22:37 Stephan Bergmann :
>
> On 14/05/2020 12:40, Naruhiko Ogasawara wrote:
> > --
> > static const std::map>
> > tblDBNumToNatNum
> > = { { primary(LANGUAGE_CHINESE),{ 4, 5, 6, 0 } },
> > { primary(LANGUAGE_JAPANESE), { 4, 5, 3, 0 } },
> > { primary(LANGUAGE_KOREAN), { 1, 2, 3, 9 } } };
> > --
> >
> > The compiler claimed:
> > --
> > Error (active) E0289 no instance of constructor "std::map<_Kty, _Ty,
> > _Pr, _Alloc>::map [with _Kty=LanguageType, _Ty=std::array > 4U>, _Pr=std::less,
> > _Alloc=std::allocator > std::array>>]" matches the argument list
> > --
>
> There should be no reason that that does not work. Probably an issue
> with whatever specific compiler you are using?
>
I'm not sure but I'm using latest LODE in Windows 10, with Visual Studio
Community 2019 V16.5.5, with MSVC v142 + Clang 9.0.0.
And my build has branched from master:
0b81aaa36b5b78e208c5cc2cd36b4906b8d636a6
Best regards,
--
Naruhiko NARU Ogasawara (naru...@gmail.com)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
C++ question: literal form of std::map
Hello,
I'm a not good C++ programmer so I want to ask you.
Now I'm trying to resolve tdf#130140 and tdf#130193, both of them
relate to the mapping between NatNum of Calc and DBNum of Excel.
Before that, I want to refactor current switch-and-if nesting
implementation of MapDBNumToNatNum() and MapNatNumToDBNum() to easy to
understand how to map these. I thought it would be nice if we can
write as:
--
static const std::map> tblDBNumToNatNum
= { { primary(LANGUAGE_CHINESE),{ 4, 5, 6, 0 } },
{ primary(LANGUAGE_JAPANESE), { 4, 5, 3, 0 } },
{ primary(LANGUAGE_KOREAN), { 1, 2, 3, 9 } } };
sal_uInt8 SvNumberNatNum::MapDBNumToNatNum( sal_uInt8 nDBNum,
LanguageType eLang, bool bDate )
{
...
if (tblDBNumToNatNum.count(eLang) != 0)
{
nNatNum = tblDBNumToNatNum.at(eLang)[nDBNum - 1];
}
else
{
nNatNum = 0;
}
}
return nNatNum;
}
--
The code above works fine in my local build, but the " {4, 5, 6, 0}"
or else has a constant length, so I thought it is better to use
std::array instead of std::vector, but I couldn't write:
--
static const std::map> tblDBNumToNatNum
= { { primary(LANGUAGE_CHINESE),{ 4, 5, 6, 0 } },
{ primary(LANGUAGE_JAPANESE), { 4, 5, 3, 0 } },
{ primary(LANGUAGE_KOREAN), { 1, 2, 3, 9 } } };
--
The compiler claimed:
--
Error (active) E0289 no instance of constructor "std::map<_Kty, _Ty,
_Pr, _Alloc>::map [with _Kty=LanguageType, _Ty=std::array, _Pr=std::less,
_Alloc=std::allocator>>]" matches the argument list
--
I may do a very easy mistake, so could you give me a hint?
Best,
--
Naruhiko NARU Ogasawara (naru...@gmail.com)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-qa] Linux and Mac testers needed for 91574
Hi Tommy, * the current bug situation in Windows is described here: https://bugs.documentfoundation.org/show_bug.cgi?id=91574#c5 https://bugs.documentfoundation.org/show_bug.cgi?id=91574#c52 Thanks, understood. I suppose you don't see that blank white screen instead of the correct grey presenter console interface. You're right, I don't see the blank white screen. I hope the screenshot (link attached) taken by me helps you. https://pbs.twimg.com/media/CJhHqENVEAARDNd.png Best, -- Naruhiko Ogasawara (naru...@gmail.com) -- -- Naruhiko Ogasawara (naru...@gmail.com) ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Linux and Mac testers needed for 91574
Hi Tommy, * Just a quick look, what should be checked is playing slideshow under the multi-window environment, as described in comment #3? I tried this reproduce steps with: Version: 5.1.0.0.alpha1+ Build ID: d3b6f3790953bdfeaeebcd3ba9ec370d94ca4ebf TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2015-07-09_00:10:08 under my OS X Yosemite (10.10.4) with multi-window, and the Presenter Console seems to work well. Best, -- Naruhiko Ogasawara (naru...@gmail.com) -- -- Naruhiko Ogasawara (naru...@gmail.com) ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Linux and Mac testers needed for 91574
Oops, sorry, I should say multiple monitors, not multi-window. 2015年7月9日(木) 18:38 Naruhiko Ogasawara naru...@gmail.com: Hi Tommy, * Just a quick look, what should be checked is playing slideshow under the multi-window environment, as described in comment #3? I tried this reproduce steps with: Version: 5.1.0.0.alpha1+ Build ID: d3b6f3790953bdfeaeebcd3ba9ec370d94ca4ebf TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2015-07-09_00:10:08 under my OS X Yosemite (10.10.4) with multi-window, and the Presenter Console seems to work well. Best, -- Naruhiko Ogasawara (naru...@gmail.com) -- -- Naruhiko Ogasawara (naru...@gmail.com) -- -- Naruhiko Ogasawara (naru...@gmail.com) ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: Writer : Undo problem(Japanese IME)
Hi Hidemune, *
Some additional information:
1. To make the bug be tracked easier, I filed the bug:
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=87500
2. in Japaese ML:
http://listarchives.libreoffice.org/ja/discuss/msg03302.html
Hidemune said that BreakIteratorImpl::nextCharacters() handle
the last control code incorrectly in Japanese Windows environment,
and there are several code to call BreakIteratorImpl::nextCharacters()
same way.
If so, I think we should be correct BreakIteratorImpl::nextCharacters()
(or its subclasses) instead of SwBreakIt::getGraphemeCount().
How do you think?
That's because the patch is in the ML, not in Gerrit.
Regards,
2014-12-18 20:26 GMT+09:00 TANAKA HY a...@kne.biglobe.ne.jp:
Hello,
The bug is in the Writer (Windows7 64bit).
1. After the English input, I was a Japanese input.
2. I have run several times Undo.
3. Then, Writer was hung up.
I was confirmed to work correctly when applying the following patch.
diff --git a/sw/source/core/bastyp/breakit.cxx
b/sw/source/core/bastyp/breakit.cxx
index bf468b9..55f3dec 100644
--- a/sw/source/core/bastyp/breakit.cxx
+++ b/sw/source/core/bastyp/breakit.cxx
@@ -191,8 +191,11 @@ sal_Int32 SwBreakIt::getGraphemeCount(const
OUString rText,
else
{
sal_Int32 nCount2 = 1;
+sal_Int32 nPosOld = nCurPos;
nCurPos = xBreak-nextCharacters(rText, nCurPos,
lang::Locale(),
i18n::CharacterIteratorMode::SKIPCELL, nCount2, nCount2);
+if (nPosOld == nCurPos)
+break;
}
++nGraphemeCount;
}
Best regards,
TANAKA Hidemune
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
--
Naruhiko Ogasawara (naru...@gmail.com)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-commits] core.git: pyuno/source
pyuno/source/module/pyuno.cxx |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
New commits:
commit 922f2005f34589e60969be3f2bf74e4af58e2e69
Author: Naruhiko Ogasawara naru...@gmail.com
Date: Sat Oct 25 17:54:22 2014 +0900
fdo#43157 - Clean up OSL_ASSERT, DBG_ASSERT
- Clean up OSL_ASSERT
Change-Id: I1f3a5dcfe08876da9bb4a8486311eb0ca9bab215
Signed-off-by: Stephan Bergmann sberg...@redhat.com
diff --git a/pyuno/source/module/pyuno.cxx b/pyuno/source/module/pyuno.cxx
index f468149..065513a 100644
--- a/pyuno/source/module/pyuno.cxx
+++ b/pyuno/source/module/pyuno.cxx
@@ -66,7 +66,7 @@ void PyUNO_del (PyObject* self)
OUString val2str( const void * pVal, typelib_TypeDescriptionReference *
pTypeRef , sal_Int32 mode )
{
-OSL_ASSERT( pVal );
+assert( pVal );
if (pTypeRef-eTypeClass == typelib_TypeClass_VOID)
return OUString(void);
@@ -124,7 +124,7 @@ OUString val2str( const void * pVal,
typelib_TypeDescriptionReference * pTypeRef
buf.append( { );
typelib_TypeDescription * pTypeDescr = 0;
TYPELIB_DANGER_GET( pTypeDescr, pTypeRef );
-OSL_ASSERT( pTypeDescr );
+assert( pTypeDescr );
typelib_CompoundTypeDescription * pCompType =
(typelib_CompoundTypeDescription *)pTypeDescr;
sal_Int32 nDescr = pCompType-nMembers;
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
Naruhiko Ogasawara license statement
All of my past future contributions to LibreOffice may be licensed under the MPLv2/LGPLv3+ dual license. -- Naruhiko Ogasawara (naru...@gmail.com) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-commits] core.git: Changes to 'refs/changes/61/7161/1'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
