[Python-Dev] PEP 393 Summer of Code Project

[Guido van Rossum]

On Wed, Aug 31, 2011 at 6:29 PM, Neil Hodgson <nyamatongwe at gmail.com> wrote:
> Guido van Rossum:
>
>> On Wed, Aug 31, 2011 at 5:58 PM, Neil Hodgson <nyamatongwe at gmail.com> wrote:
>>> [...] some text drawing engines draw decomposed characters ("o"
>>> followed by " ̈" -> "ö") differently compared to their composite
>>> equivalents ("ö") and this may be perceived as better or worse. I'd
>>> like to offer an option to replace some decomposed characters with
>>> their composite equivalent before drawing but since other characters
>>> may look worse, I don't want to do a full normalization.
>>
>> Isn't this an issue properly solved by various normal forms?
>
>   No, since normalization of all cases may actually lead to worse
> visuals in some situations. A potential reason for drawing decomposed
> characters differently is that more room may be allocated for the
> generic condition where a character may be combined with a wide
> variety of accents compared with combining it with a specific accent.

Ok, I thought there was also a form normalized (denormalized?) to
decomposed form. But I'll take your word.

>   Here is an example on Windows drawing composite and decomposed
> forms to show the types of difference often encountered.
> http://scintilla.org/Composite.png
>   Now, this particular example displays both forms quite reasonably
> so would not justify special processing but I have seen on other
> platforms and earlier versions of Windows where the umlaut in the
> decomposed form is displaced to the right even to the extent of
> disappearing under the next character. In the example, the decomposed
> 'o' is shorter and lighter and the umlauts are round instead of
> square.

I'm not sure it's a good idea to try and improve on the font using
such a hack. But I won't deny you have the right. :-)

-- 
--Guido van Rossum (python.org/~guido)