No, we can't throw Combining away like that.
Combining is pan-language, it's a unicode feature.

Whether we should rewrite it, and/or provide font support,
- a simple rule that combines a base character with a single diacritics
into a precomposed unicode like Yoshiki implemented is already better than
nothing. So we shall support it for WideString at least (totally useless
for ByteString).
- we should recognize more complex cases and pass the baby to the font IMHO
The font shall decide how to render (put a ? mark or display just the base,
or do the whole combination with multiple accent stacking etc...)

Did you try to reconnect Combining in Unicode scanSelector?
That would be interesting.
Currently my image is blocked after if I try to render (String with: $a
with: (16r300 to: 16r36F) atRandom asCharacter)...
MessageNotUnderstood:
CompositionScanner>>scanMultiCharactersCombiningFrom:to:in:rightX:stopConditions:kern:
but what if we add it in both CharacterScanner branches?


2013/9/25 tim Rowledge <tim at rowledge.org>

>
> On 24-09-2013, at 3:37 PM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>
> > 1) because there is a special scanning method for Japanese
>
> So that removes the main(?) need for scanMultiCharactersCombining… ?
>
> > 2) because unicode diacritics and other combining chars should be
> rendered specially
>
> And we certainly don't seem to do that right at the moment. Does FreeType
> deal with that? Would we be better off removing the
> scanMultiCharactersCombining… methods for now and replacing them later with
> a new approach (to be written by Yoshiki, of course ;-) ) ? We might be
> able to remove the CombinedChar related code too in that case.
>
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> I haven't lost my mind; it's backed up on tape somewhere.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130925/40032135/attachment.htm