<div dir="ltr"><div><div>Hi Yoshiki,<br></div>I also note that there is a presentation and presentationLine in MultiCharacterScanner, could you tell a word about theses inst. vars.?<br><br></div>Nicolas<br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">2013/9/6 Yoshiki Ohshima <span dir="ltr"><<a href="mailto:Yoshiki.Ohshima@acm.org" target="_blank">Yoshiki.Ohshima@acm.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Thu, Sep 5, 2013 at 5:21 PM, tim Rowledge <<a href="mailto:tim@rowledge.org">tim@rowledge.org</a>> wrote:<br>
><br>
> On 05-09-2013, at 4:59 PM, Yoshiki Ohshima <<a href="mailto:Yoshiki.Ohshima@acm.org">Yoshiki.Ohshima@acm.org</a>> wrote:<br>
><br>
</div><div class="im">>>> What is the intent of MultiXXXXX ? What is CombinedChar for? Are they, honestly, still needed? Or should the older versions be removed instead? Who wrote the new classes and is that person still maintaining them? Is he/she still around here?<br>
>><br>
>> This kind of stuff touches the part of Squeak that *has to* work.<br>
>> Once the "MultiCharacterScanner" worked and people were confident, it<br>
>> was in theory possible to ditch the old implementation; but I did not<br>
>> think back then that it (replacing fundamental code with a<br>
>> "work-in-progress" version) was acceptable to the community. IF there<br>
>> was enough man-power, there would have been more variation of such<br>
>> scanners implemented for different writing systems; keeping the<br>
>> original version that works for byte strings would have been useful<br>
>> under that light.<br>
><br>
> So if I understand you correctly, there *should* be no particular differences in what the two types of scanner do? You made a parallel set in order to insulate your work from the tools that you needed to keep working in order to keep making the i18n stuff?<br>
<br>
</div>Not quite. The analogy for WideString and String was like<br>
LargeInteger and SmallInteger, and CharacterScanner was like a<br>
different implementation of #+. MultiCharacterScanner handles<br>
WideStrings, especially when there are characters with different<br>
leading chars are involved. So the functionality is different.<br>
<div class="im"><br>
> I've worked through several of the scanners without finding any major differences, but not yet all of them. It certainly looks to me that there is nothing to stop us having only one set. I suspect there may be some bug fixes in the more recently created classes, though I did notice at least a couple of places where the method in the old scanner class was actually newer than its equivalent in the new scanner. Do you recall any serious changes made to support multi-byte strings?<br>
<br>
</div>The serious change was for handling leading char, and also the<br>
different line breaking rules for different languages.<br>
<div class="im"><br>
>> CombinedChar creates a precomposed character from a sequence of<br>
>> decomposed form of Unicode when possible. For a certain keyboard, it<br>
>> was needed.<br>
><br>
> Ah, yes now I see . Should CombinedChars ever exist outside that very narrow area of reading the keyboard and then copying out the results to the paragraphs? I didn't see any use beyond that but it can be hard to trace everything.<br>
<br>
</div>Whenever you want to find out a sequence is composable, it is<br>
potentially useful.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
-- Yoshiki<br>
<br>
</font></span></blockquote></div><br></div>