Unicode issues in 4.1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Unicode issues in 4.1

Nicolas Cellier
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

Reply | Threaded
Open this post in threaded view
|

Re: Unicode issues in 4.1

Nicolas Cellier
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

Reply | Threaded
Open this post in threaded view
|

Re: Unicode issues in 4.1

Yoshiki Ohshima-2
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