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: Adam Twardoch (List)
Subject: Re: [ft-devel] Getting the kerning pairs in under O(n*n)
Date: Thu, 04 Oct 2012 00:00:24 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1

I'll try it like this:

Multimedia container files like AVI or MOV have audio and video streams,
plus optional streams like subtitles etc. Each such stream can typically
use various codecs for various flavors of audio or video.

SFNT-based fonts also are such containers, and there different kinds of
"streams" inside them. Just like with video and audio, there are two
kinds of streams in SFNT:

1. The equivalent of video is the "glyph rendering stream". Glyphs are
typically monochrome and use different "codecs": cubic outlines in the
"CFF" table, quadratic outlines in the "glyf" table. Some platforms
support some additional "codecs" like MultipleMaster or TrueType
Variations. There is an effort to put multicolor glyphs in the "SVG "
table under way. And there is a number of bitmap formats that can be
included ("bloc/bdat/EBLC/EBDT" for monochrome and grayscale, the new
Apple "sbix" color table).

2. The equivalent of audio is the "text layout stream". Again, several
different "codecs" are used:
* Minimal: "hhea", "OS/2", "cmap"
* TrueType 1.0 Layout: "hhea", "kern" table only
* OpenType Layout: "OS/2", "GSUB", "GPOS", "GDEF", "JSTF" tables
* TrueType AAT Layout: Apple-extended "kern" table, reportedly the new
Apple "kerx" table, and many others
* SIL Graphite: (different tables)
* Microsoft Math: the "MATH" table and bits of "GSUB"

There are also some "private" or auxiliary streams which don't
necessarily have to do with either glyph rendering or text layout -- for
example the "name" table which primarily provides a "user interface"
access, just like some metadata in AVI or MOV, or like ID tags in MP3.

Just like there are some "sync points" between video and audio streams
in a multimedia container, there are some ways to "sync" between the
text layout stream and the glyph rendering stream. The most important
sync point is the Glyph ID (GID).

I fully agree with Werner that FreeType has no business in the "text
layout stream" just like a video codec doesn't necessarily need to
decode audio. It might, but there may be very good reasons why it
shouldn't. Other libraries like HarfBuzz, ICU Layout, Uniscribe,
CoreText or Monotype WorldType, Graphite, XeTeX/LuaTeX (for Math) should
deal with the "text layout stream", and FreeType should deal with the
"glyph rendering stream", providing only access to the "Minimal" layout
stream ("hhea", "OS/2", "cmap"), and to some tables needed for external
access, like "name". 

Basically, if you "play" your fonts with FreeType only, you get access
to a lot of the different video streams and codecs, and you have some
nice video filters (autohinting etc.), but you only get the English mono
sound. No multilanguage tracks, no stereo or dolby surround. If you want
that (i.e. more advanced text layout), use a dedicated text layout library.

I agree that even "kern" should not be added, especially since it's
ancient and primitive. No serious text layout these days should be done
using the TrueType 1.0 Layout model (i.e."kern" table only). It's over
20 years old, and dramatically outdated.

People should either use OpenType Layout or just the Minimal layout.

HOWEVER: I must agree with Behdad though that "gasp" *definitely* should
be supported by FreeType. Basically, in the "default grayscale
rendering", it should actually be grayscale+monochrome as defined by
gasp. In the "default subpixel rendering", it should be
subpixel+Y-smoothing as defined by gasp. The user should be able to
override these ("force grayscale" or "force monochrome") but "gasp" is
definitely NOT external to glyph rendering, it's very *essential*.

Regards,
Adam


On 12-10-03 23:14, Werner LEMBERG wrote:
>> [...] 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
>
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/freetype-devel


-- 

May success attend your efforts,
-- Adam Twardoch
(Remove "list." from e-mail address to contact me directly.)




reply via email to

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