[Python-Dev] PEP 393 Summer of Code Project (original) (raw)

Guido van Rossum guido at python.org
Thu Sep 1 04:51:35 CEST 2011

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)

More information about the Python-Dev mailing list