freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Devel] Kerning problem with capitals


From: Werner LEMBERG
Subject: Re: [Devel] Kerning problem with capitals
Date: Wed, 08 Dec 2004 17:59:49 +0100 (CET)

> > > The image of the string is NOT a simple sequence of the glyph
> > > images.
> >
> > Actually, it is.  Except kerning, there is *no* interaction
> > between glyph images.
>
> It is like saying "there is no interaction except when there is".
> Hinting also introduces interaction.  Two glyphs need to be pushed
> together or pushed apart depending on (rsb_delta + lsb_delta).

This only exists for FreeType's autohinter.  What we've discussed
before is a problem with the native TrueType hinter which normally
doesn't handle sub-pixel rendering...

> If this is not interaction that needs to be introduced than I don't
> know what is.  So you right that there is no interaction currently,
> but there NEED be one.

You mean something different, namely that the distance between glyphs
needs some fine-tuning if sub-pixel rendering is active.  This has
nothing to do with the glyph images themselves (which are just
2D-arrays of pixels).

> > > Freetype is stuck with bad kerning until the forementioned is
> > > taken care of even at the price of binary compatibility.
> >
> > I don't understand what you are talking about!  Where is the
> > connection between binary compatibility and bad kerning?
>
> Until you break binary compatibility by introducing string
> rendering, with rsb_delta + lsb_delta used as a visable default,
> there will be spacing issues with kerning and/or with hinting.

What you want is a function which takes a string of glyph indices, and
which returns a bitmap, containing an image of the string, right?  It
wouldn't break binary compatibility to add such a function, but it is
a waste of time IMHO to do that, since only the simplest cases can be
handled correctly:

  . A `kern' table must be in the font.  Modern fonts don't have one.
    They use the `GPOS' table instead which will never be handled by
    FreeType 2.

  . No contextual analysis is done.  This means, among other things,
    that you have to specify ligatures manually.  Automatically doing
    `f' + `i' = `fi' and similar things is wrong for some languages
    (e.g. Turkish).

For the vast majority of languages it will produce bad results.

If people really want to go the `easy' route, they should use the code
from ftstring.c, for example.  Why shall we promote a bad solution?


    Werner



reply via email to

[Prev in Thread] Current Thread [Next in Thread]