There seem to be several issues related to Character rendering since
(Unicode leadingChar = 0) change. 1) #scanMultiCharactersCombiningFrom:to:in:rightX:stopConditions:kern: looks like broken - it seems to miss-handle some #cr stopConditions - it does not have support for kerning pairs (unlike cousins #scanMultiCharactersFrom:to:in:rightX:stopConditions:kern:...) - it is strange that this message has to be redefined in every subclass (unlike cousins again) consequently, composing/displaying/selecting seems to each have their own behavior A good example is to evaluate this in a workspace: 'abc_' , (String with: 1105 asCharacter) , 'def_' , String cr , 'ghi_' 2) String does not render the same whether Wide or Byte (StringHolder new contents: 'abc_') openLabel: 'Byte'. (StringHolder new contents: 'abc_' asWideString) openLabel: 'Wide'. 3) There used to be a change of run detected at leadingChar change, but with all characters having 0 as leadingChar, this does not happen anymore. This changes the font selection. These are good candidates for bugfix before 4.1 goes final. For 1) I have a brutal workaround: do not honour Composing... (invert commented code in #scanSelector) I wish we find a better solution... Nicolas |
2010/3/25 Nicolas Cellier <[hidden email]>:
> There seem to be several issues related to Character rendering since > (Unicode leadingChar = 0) change. > > 1) #scanMultiCharactersCombiningFrom:to:in:rightX:stopConditions:kern: > looks like broken > - it seems to miss-handle some #cr stopConditions > - it does not have support for kerning pairs (unlike cousins > #scanMultiCharactersFrom:to:in:rightX:stopConditions:kern:...) > - it is strange that this message has to be redefined in every > subclass (unlike cousins again) > Â consequently, composing/displaying/selecting seems to each have their > own behavior > > A good example is to evaluate this in a workspace: > > 'abc_' , (String with: 1105 asCharacter) , 'def_' , String cr , 'ghi_' > > 2) String does not render the same whether Wide or Byte > > (StringHolder new contents: 'abc_') openLabel: 'Byte'. > (StringHolder new contents: 'abc_' asWideString) openLabel: 'Wide'. > > 3) There used to be a change of run detected at leadingChar change, > but with all characters having 0 as leadingChar, this does not happen > anymore. > This changes the font selection. > > > These are good candidates for bugfix before 4.1 goes final. > For 1) I have a brutal workaround: do not honour Composing... (invert > commented code in #scanSelector) > I wish we find a better solution... > > > Nicolas > More questions than answers yet... What is a presentation/presentationLines ? I don't really understand how these inst vars are used... Nicolas |
At Fri, 26 Mar 2010 01:11:17 +0100,
Nicolas Cellier wrote: > > More questions than answers yet... > What is a presentation/presentationLines ? I don't really understand > how these inst vars are used... I'm not looking at the code now, but these were used for the idea of logical sequence (like sequence of Unicode character that may contain the composition characters), and visual glyph sequence that may be composed from the logical sequence. But trying to implement fully elaborated glyph shaping layout in Squeak is now I think to be a really obsoleted idea and cleaning them up would be a sensible thing to do... -- Yoshiki |
Free forum by Nabble | Edit this page |