Strange behavior (bug) of wrapping text with TTFont (russian text) in TextMorph

2010/6/30 Denis Kudriashov <[hidden email]>:

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

No. #isSeparator message not used for wrapping. Wrapping logic implemented in MultiCompositionScanner and dont use #isSeparator

2010/6/30 Igor Stasenko <[hidden email]>

2010/6/30 Denis Kudriashov <[hidden email]>:

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
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 <[hidden email]>:
> 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 <[hidden email]>
> написал:
>>
>> No. #isSeparator message not used for wrapping. Wrapping logic implemented
>> in MultiCompositionScanner and dont use #isSeparator
>>
>> 2010/6/30 Igor Stasenko <[hidden email]>
>>>
>>> 2010/6/30 Denis Kudriashov <[hidden email]>:
>>> > 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
>>> > [hidden email]
>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>> >
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2010/6/30 Denis Kudriashov <[hidden email]>:

> 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
> <[hidden email]> написал:
>>
>> 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 <[hidden email]>:
>> > 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
>> > <[hidden email]>
>> > написал:
>> >>
>> >> No. #isSeparator message not used for wrapping. Wrapping logic
>> >> implemented
>> >> in MultiCompositionScanner and dont use #isSeparator
>> >>
>> >> 2010/6/30 Igor Stasenko <[hidden email]>
>> >>>
>> >>> 2010/6/30 Denis Kudriashov <[hidden email]>:
>> >>> > 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
>> >>> > [hidden email]
>> >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Best regards,
>> >>> Igor Stasenko AKA sig.
>> >>>
>> >>> _______________________________________________
>> >>> Pharo-project mailing list
>> >>> [hidden email]
>> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >>
>> >
>> >
>> > _______________________________________________
>> > Pharo-project mailing list
>> > [hidden email]
>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project