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 > Freetype-devel@nongnu.org > 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.) _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel