Apache OpenOffice (AOO) Bugzilla – Issue 6546
can't bracket an epsilon
Last modified: 2013-08-07 14:56:16 UTC
If I write langle %épsilon rangle (note the é because I'm using spanish version of oo), or angle, brace, dline, lline, dbracket with %épsilon enclosed, or %épsilon outside the langle rangle but after them, the editor shows correctly the form, but when I save, quit, and reload the document, %épsilon has changed to epsilonn (without %, without the accent ´, and with an extra n at the end), and obviously, doesn't shows an epsilon, but epsilonn. It doesn't happen if I use %épsilon alone without the commands mentioned above, or if the %épsilon is before the langle rangle command.
Workaround. I use the greek letter copied from "Character Map" in XP. I guess this will render the document not portable to other plataform.
Please check if it is a file format problem. That is check if this happens also if you save in "Star Writer 5.0" or "Star Math 5.0" format. You may also check if thi still happens in OO 1.0.1 (I only could reproduce it twice and not at all after that).
I've checked saving in "Star Writer 5.0" and it works ok. The problem seems to be, as you said, in the format. I can't test on 1.0.1 'cause spanish version isn't available yet.
TL->CMC: To you to check because I cannot reproduce this regularly. Please have a look.
Hmm, under linux with 1.0.0 in parse.cxx... while (UnicodeType::SPACE_SEPARATOR & rCC.getType( BufferString, BufferIndex )) ++BufferIndex; Is not skipping normal leading spaces for me under linux with OOo, but rCC.parseAnyToken is skipping them. This means that BufferIndex is not pointing to the first nonwhitespace character after the parse and so the replacing of épsilon with epsilon occurs at the wrong point. The attached patch to make BufferIndex point to nRealStart makes this work correctly. But the real question is still why does the getType work on for other combinations of platforms, and why did it happen for me under windows in 1.0.0 as well originally and then stop happening.
Index: parse.cxx =================================================================== RCS file: /cvs/sw/starmath/source/parse.cxx,v retrieving revision 1.17.2.1 diff -u -r1.17.2.1 parse.cxx --- parse.cxx 15 Feb 2002 17:02:04 -0000 1.17.2.1 +++ parse.cxx 31 Jul 2002 09:13:25 -0000 @@ -513,7 +520,11 @@ ++BufferIndex; bCont = TRUE; } + else + BufferIndex = nRealStart; } + else + BufferIndex = nRealStart; } while (bCont);
cmc->tl: Back to you for integration. Attaching a file seems to be broken at the moment, so I'm inlining the suggested patch. Assuming that the CJK spacing issue is fixed and so is safe to be removed then the following should be equivalent to the normal expected case where using rCC.getType actually worked. Patch works for me in an othewise unchanged 1.0.1 fr under linux getType doesn't work for the OOo 1.0.1 series because it appears getType wasn't fully implemented then and is a stub that always returns 0 regardless of the character. In the OOSRC642 series the new version should have it implemented, so this problem should go away on its own in one of those versions even without this patch. Index: parse.cxx =================================================================== RCS file: /cvs/sw/starmath/source/parse.cxx,v retrieving revision 1.19 diff -u -r1.19 parse.cxx --- parse.cxx 6 Feb 2002 12:37:27 -0000 1.19 +++ parse.cxx 31 Jul 2002 13:24:43 -0000 @@ -479,17 +479,12 @@ const CharClass& rCC = SM_MOD1()->GetSysLocale().GetCharClass(); do { - //?? does parseAnyToken handles Japanese (CJK) spaces correct ?? - // seems not to be so... - while (UnicodeType::SPACE_SEPARATOR == - rCC.getType( BufferString, BufferIndex )) - ++BufferIndex; - aRes = rCC.parseAnyToken( BufferString, BufferIndex, coStartFlags, aEmptyStr, coContFlags, aEmptyStr ); nRealStart = BufferIndex + (xub_StrLen) aRes.LeadingWhiteSpace; + BufferIndex = nRealStart; bCont = FALSE; if ( aRes.TokenType == 0 &&
Unfortunately the work around for the iseographic space can not yet be removed since the problem in parseAnyToken is still unsolved. Although it should work for a long time by now... Thus since CMC stated the problem with the getType function implementation will be solved with the next OOSRC642 build we will just wait for that and remove the work around later when parseAnyToken is fixed.
There needs to sth put here...
Should be fixed by now in OO 643 E. At least I could not reproduce it in my installation, but I only could seldom before. Please check. TL->CMC: It would be great if you could just have a look and confirm that it does not occur on your system anymore too.
Must be checked with a localized version.
*** Issue 10774 has been marked as a duplicate of this issue. ***
*** Issue 10644 has been marked as a duplicate of this issue. ***
Setted a suitable Target. The bugfix will be included in OO 1.1 Beta.
Closed.