[Pharo-project] Strange behavior (bug) of wrapping text with TTFont (russian text) in TextMorph
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 "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.
2010/6/30 Denis Kudriashov <dionisiydk@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
No. #isSeparator message not used for wrapping. Wrapping logic implemented in MultiCompositionScanner and dont use #isSeparator 2010/6/30 Igor Stasenko <siguctua@gmail.com>
2010/6/30 Denis Kudriashov <dionisiydk@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <dionisiydk@gmail.com>напиÑал:
No. #isSeparator message not used for wrapping. Wrapping logic implemented in MultiCompositionScanner and dont use #isSeparator
2010/6/30 Igor Stasenko <siguctua@gmail.com>
2010/6/30 Denis Kudriashov <dionisiydk@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <dionisiydk@gmail.com>:
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 <dionisiydk@gmail.com> напиÑал:
No. #isSeparator message not used for wrapping. Wrapping logic implemented in MultiCompositionScanner and dont use #isSeparator
2010/6/30 Igor Stasenko <siguctua@gmail.com>
2010/6/30 Denis Kudriashov <dionisiydk@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hello, Nicolas. 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.
LeadingChar is abount string encoding. Font is about string displaying. Why leadingChar changing should raise font changes? I can have string with russian and english chars and they all displayed by Arial font for example. I really not understand meaning of code that I comment. For english text its condition never executed. And for non english text I think its should be truth too. Why It not should be truth for text with english and non english chars? Would it be possible to change russian environment to use Unicode with
a good font support?
What you mean? I just want my application work with russian label, texts with regular TrueType fonts. Now I use DejaVu Regular font 30 иÑÐ½Ñ 2010 г. 23:35 полÑзоваÑÐµÐ»Ñ Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> напиÑал:
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 <dionisiydk@gmail.com>:
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 < dionisiydk@gmail.com> напиÑал:
No. #isSeparator message not used for wrapping. Wrapping logic
implemented
in MultiCompositionScanner and dont use #isSeparator
2010/6/30 Igor Stasenko <siguctua@gmail.com>
2010/6/30 Denis Kudriashov <dionisiydk@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/6/30 Denis Kudriashov <dionisiydk@gmail.com>:
Hello, Nicolas.
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.
LeadingChar is abount string encoding. Font is about string displaying. Why leadingChar changing should raise font changes? I can have string with russian and english chars and they all displayed by Arial font for example. I really not understand meaning of code that I comment. For english text its condition never executed. And for non english text I think its should be truth too. Why It not should be truth for text with english and non english chars?
I think that was not true in the past : there was a font for latin, a font for russian, a font for greek.... Now we can work with a single encoding (unicode) and a single font supporting unicode... If you look at character encoding in a Russian squeak/pharo String, you will just find it is a combination of unicode + leadingChar bits...
Would it be possible to change russian environment to use Unicode with a good font support?
What you mean? I just want my application work with russian label, texts with regular TrueType fonts. Now I use DejaVu Regular font
I mean just change: RussianEnvironment>>leadingChar ^0 and see what happens Nicolas
30 иÑÐ½Ñ 2010 г. 23:35 полÑзоваÑÐµÐ»Ñ Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> напиÑал:
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 <dionisiydk@gmail.com>:
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 <dionisiydk@gmail.com> напиÑал:
No. #isSeparator message not used for wrapping. Wrapping logic implemented in MultiCompositionScanner and dont use #isSeparator
2010/6/30 Igor Stasenko <siguctua@gmail.com>
2010/6/30 Denis Kudriashov <dionisiydk@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I try it. Its work same as with 15 leading char. All good. I found another issue without this change (clean Pharo 1.1 rc2 10.06). Just open workspace and write and edit non latin (russian) multiline text. You will see strange happens. In Pharo 1.0 It works good 1 иÑÐ»Ñ 2010 г. 11:56 полÑзоваÑÐµÐ»Ñ Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> напиÑал:
2010/6/30 Denis Kudriashov <dionisiydk@gmail.com>:
Hello, Nicolas.
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.
LeadingChar is abount string encoding. Font is about string displaying. Why leadingChar changing should raise font changes? I can have string with russian and english chars and they all displayed by Arial font for example. I really not understand meaning of code that I comment. For english text its condition never executed. And for non english text I think its should be truth too. Why It not should be truth for text with english and non english chars?
I think that was not true in the past : there was a font for latin, a font for russian, a font for greek....
Now we can work with a single encoding (unicode) and a single font supporting unicode...
If you look at character encoding in a Russian squeak/pharo String, you will just find it is a combination of unicode + leadingChar bits...
Would it be possible to change russian environment to use Unicode with a good font support?
What you mean? I just want my application work with russian label, texts with regular TrueType fonts. Now I use DejaVu Regular font
I mean just change:
RussianEnvironment>>leadingChar ^0
and see what happens
Nicolas
30 иÑÐ½Ñ 2010 г. 23:35 полÑзоваÑÐµÐ»Ñ Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> напиÑал:
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 <dionisiydk@gmail.com>:
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 -
^ 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 <dionisiydk@gmail.com> напиÑал:
No. #isSeparator message not used for wrapping. Wrapping logic implemented in MultiCompositionScanner and dont use #isSeparator
2010/6/30 Igor Stasenko <siguctua@gmail.com>
2010/6/30 Denis Kudriashov <dionisiydk@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (3)
-
Denis Kudriashov -
Igor Stasenko -
Nicolas Cellier