Hi Denis, My understanding of endOfRun is that the end of a run has been reached. An end of run mark a change of emphasis (think of Text string:runs:) or the end of the text to be rendered.
stops endOfRun always return #endOfRun (the method to be executed when an endOfRun condition occurs is programmable, but a single usage is done across the image). You'll see that most CharacterScanner & subclasses will send a #setStopConditions, that will send a #setFont. That is the main purpose, when a change of emphasis (like bold or italic) occurs, font must be changed. The code is like this for ages (already in st80 ASCII times). Multilingual additions do also consider a change of leadingChar as a special case of endOfRun because current font must be changed too. Also, presumably it did not hurt to split text here because a change of leadingChar corresponds to a change of language. I don't think we changed this behaviour. We just used a message ^(stops endOfRun) instead of (stops at: EndOfRun), because previous implementation (along with CrossedX) did consume two character slots (256 257) which are valid Unicode (they were previously unused in ASCII times and previous Multilingual implementation because unicode leadingChar was 255). However, what changed is that less endOfRun are detected than before because Unicode leadingChar is now zero... I unfortunately don't eat my own dog food because I'm a native latin speaker, so maybe I just should stop touching the Multilingual code... But my understanding is that code needed (and still need!) to be cleaned up... ... and also that leadingChar is not really usefull for rendering Russian now that there are more and more fonts with good Unicode support... Would it be possible to change russian environment to use Unicode with a good font support? Nicolas 2010/6/30 Denis Kudriashov <[email protected]>: > I found solution. > > I comment line of code in scanning loop in > MultiCharacterScanner>>scanMultiCharactersFrom: startIndex to: stopIndex in: > sourceString rightX: rightX stopConditions: stops kern: kernDelta > > ... > "encoding ~= startEncoding ifTrue: [lastIndex := lastIndex - 1. ^ > stops endOfRun]." > ... > > Without this commenting scanning process not register breakage at space when > scanning russian text. (because encoding is differ from startEncoding. > Encoding for space is 0 but for startEncoding is leadingChar of not ascii > russian text). > > I dont now meaning of this code line. But now I have correct wrapping > behavior. > > I know that multilingual package have many newly versions. All containes > that strange code line. > > I open Issue http://code.google.com/p/pharo/issues/detail?id=2608 > > 30 июня 2010 г. 9:55:37 UTC+4 пользователь dionisiydk <[email protected]> > написал: >> >> No. #isSeparator message not used for wrapping. Wrapping logic implemented >> in MultiCompositionScanner and dont use #isSeparator >> >> 2010/6/30 Igor Stasenko <[email protected]> >>> >>> 2010/6/30 Denis Kudriashov <[email protected]>: >>> > I use Pharo 1.1 rc2 10.06 >>> > >>> > I found strange behavior of wrapping text with TTFont (russian text) in >>> > TextMorph. >>> > >>> > I dont know how to reproduce it. But I see it in my application. >>> > >>> > I have prototype button with TextMorph as it label. And I do many of: >>> > >>> > aPanel add: prototype veryDeepCopy contentsWrapped: someRussianText. >>> > >>> > And I see that text on label dont wrapped by words. It is wrapped only >>> > by >>> > label bounds. And words in text became break. >>> > Example. I expect >>> > >>> i think it wraps text based on #isSeparator test. >>> And any russian (as well as any other non-ascii characters), afaik is >>> treated as separators. >>> That's why it wraps on any letter. >>> >>> > "one two >>> > three" >>> > >>> > But I see >>> > >>> > "one two th >>> > ree >>> > " >>> > >>> > Its work correct for english text. But for russian not. >>> > >>> > And I cant reproduce it by execution code separetelly from my >>> > application >>> > (aPanel add: prototype veryDeepCopy contentsWrapped: someRussianText). >>> > >>> > I try many experiments with debuger and inspector. But I cant fix that. >>> > Wrapping text code is not simple. >>> > Maybe somebody tell me what place I need learn/inspect for fixing this >>> > bug? >>> > >>> > And I found that If I insert char by keyboard at the end of word "two" >>> > (see >>> > example) text wrapped correctly: >>> > "one twoNEW >>> > three >>> > " >>> > >>> > And this behavior correct in Pharo 1.0. >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > Pharo-project mailing list >>> > [email protected] >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> > >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
