173 			break;	

   173 			// Begin defect fixing for case ou1cimx1#475636.

   174 			// The defect: Popup panic 12 (ECharPosBeyondDocument) when display special Arabic

   175 			//             text string.

   176 			// The direct reason: in function RTmGraphemeInTextChunkIterator::Next(),

   177 			//                    iFont->Font().GetCharacterPosition2() returns with

   178 			//                    iPosition.iPosInText equal to iPosition.iText.Length(),

   179 			//                    so that iPosition.iPosInText is an invalid document position.

   180 			// The root cause: When call GetCharacterPosition2(), FORM gives a text string,

   181 			//                 which contains characters to check, and the context characters.

   182 			//                 GetCharacterPosition2() handles the whole string from sub index

   183 			//                 1 (given by FORM). But actually, each text string has two context

   184 			//                 characters, one leading and one trailing. That is to say, the

   185 			//                 trailing context character is incorrectly taken as normal text in

   186 			//                 GetCharacterPosition2(). It's fine normally, since

   187 			//                 GetCharacterPosition2() handles ONE glyph. Unfortunately, if the

   188 			//                 trailing context character is special, such as 0x644,

   189 			//                 GetCharacterPosition2() will try to composite 0x644 with the text

   190 			//                 character before it. If the composition success (like this defect),

   191 			//                 FORM will receive invalid document position.

   192 			// Solution: Never take 0x644 as context character.

   193 			if (iContextCharPerChunk == 0x644)

   194 				{

   195 				iContextCharPerChunk = 0x643;

   196 				}

   197 			// End defect fixing for case ou1cimx1#475636.

   198 			break;