2010/6/30 Denis Kudriashov <[email protected]>:
> 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
> <[email protected]> написал:
>>
>> 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
>
> _______________________________________________
> 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
