freetype-devel
[Top][All Lists]
Advanced

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

Re: [ft-devel] Getting the kerning pairs in under O(n*n)


From: Werner LEMBERG
Subject: Re: [ft-devel] Getting the kerning pairs in under O(n*n)
Date: Wed, 03 Oct 2012 23:14:38 +0200 (CEST)

> [...] The problem is that I have to do an operation on the order of
> O(N^2) where N = number of glyphs, to extract the kerning pairs.  It
> would be a lot easier if FreeType offered some sort of iterator that
> lets me enumerate each kerning pair.
> 
> The developer who brought this to my attention claims that "they
> arent interested in supporting it" (they meaning the FreeType
> developers).  But my experience with FreeType development has only
> been positive.  Is there anything we can do about this?

Reading the thread, I must say that Hugh is right basically.  The
number of fonts which have full-featured `kern' tables is rapidly
diminishing.  Today, full kerning is in the `GPOS' table, and `kern'
only holds the absolute minimum of necessary kerning values for
backwards-compatibility, a `poor-man's kerning', so to say.

Please don't forget that FreeType's job is to render glyphs, nothing
else.  Accessing additional font tables (gasp, kern, etc.) should be
handled by a higher-level library.  Well, Behdad tries me to convince
that `gasp' is something for FreeType but I'm not convinced yet...
However, `kern' certainly doesn't belong to FreeType, and to fully
support `GPOS' kerning you *need* an OpenType layout engine like
Harfbuzz.

If you want better support for kerning from the `kern' table,
something like Hugh's code is OK, and adding it to your amalgamation
project looks like a good solution.

Regarding the other issue, this is, getting the character code from
the glyph index, Hugh seems to completely forget OpenType features
which makes it *impossible* to invert the mapping.  As an example,
think of using small capitals which get mapped onto the character code
positions of lowercase characters.

In case there are valid glyph names, Adobe's glyph list algorithm
(AGL) *partially* works.  However, complex scripts do glyph
reordering, insert more glyphs, etc., etc.  For such cases even the
AGL will not work.

Similar to Hugh's solution for better `kern' table handling it should
be rather easy to add a small function which provides poor-man's glyph
to character code support if the cmap is directly used.


    Werner



reply via email to

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