Re: [ft-devel] Getting the kerning pairs in under O(n*n)
On 12-10-05 06:49, Werner LEMBERG wrote: WL OK. So FreeType should obey the `gasp' table by default? Or should WL this be a new FT_LOAD flag? Or a rendering flag? Please not by default. I *NEVER* want monochrome rendering when I use aa. But some fonts are *designed* to obey the gasp table! In particular there are fonts which are rendered incorrectly in case you don't follow the gasp. As a default, I can imagine to use auto-hinting for those ranges where the gasp table says `bi-level' and the user asks for `anti-aliasing'. I would say that gasp should be active and obeyed if TT bytecode hinting is being executed. If the FreeType autohinter is used, then it doesn't make sense. The whole point of the gasp table is that it's *part of the TrueType hinting infrastructure. Ignoring it makes as much sense as ignoring cvt but executing prep, or something like that. If FreeType autohinting is used, then it's obvious that the developer-designed hinting is ignored. In such a case, it's safe to assume that gasp should not be part of the process either. These days, I feel that an even more important aspect is the y-smoothing in ClearType. The gasp flags were clearly designed to work in conjunction with ClearType, and using the y-smoothing flag in ClearType DW wisely certainly produces better results than just ignoring it. Best, Adam -- 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
Re: [ft-devel] Getting the kerning pairs in under O(n*n)
WL == Werner LEMBERG w...@gnu.org writes: WL Is it really `spotty'? I've never tested it, ... Try (a modern version of) gnu emacs to give libotf a whirl. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Getting the kerning pairs in under O(n*n)
WL Is it really `spotty'? I've never tested it, ... Try (a modern version of) gnu emacs to give libotf a whirl. I use it all the time, but I have no knowledge about complex scripts like Arabic or Khmer. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Getting the kerning pairs in under O(n*n)
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.
Re: [ft-devel] Getting the kerning pairs in under O(n*n)
Ps. The Minimal layout system exposed by FreeType is analogous of using ASCII only. *If* you use ASCII to encode your text, then you should use FreeType only, with its Minimal layout system. However, these days, most people use Unicode to encode their text, and rightly so. *If* you use Unicode to encode your text, then you should use OpenType Layout through a library such as HarfBuzz. But using the TrueType 1.0 Layout model (kern table) is analogous of using 8-bit character encoding (ANSI or ISO Latin-1) for your text. Which is the worst possible solution. If you use ASCII these days, then you know you're in a decidedly primitive environment. But if you want anything beyond ASCII, you should switch to Unicode, and forget about the 1990s mess of codepages, ANSIs and 8-character encodings. The same is true for text layout: either use FreeType only (Minimal), or do it properly with OpenType Layout. Anything in-between, especially the TrueType 1.0 Layout (kern) is ancient, half-baked, and totally unfit for today's world. If you really want that, you can write your own kern table parser and deploy it privately -- but I would be decidedly against accepting such code in the mainstream distribution, so I applaud the FreeType developers that they have made this decision a long time ago and have stuck with it. (Again, with gasp it's a totally different thing!) Best, Adam -- 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
Re: [ft-devel] Getting the kerning pairs in under O(n*n)
On Wed, Oct 03, 2012 at 02:38:40PM -0700, Vinnie Falco wrote: Please don't forget that FreeType's job is to render glyphs, nothing else. My opinion is that since FreeType opens the font file, it might as well process everything that is in it. That is easy to say :) Regards, Khaled ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Getting the kerning pairs in under O(n*n)
Hi, On Wed, Oct 03, 2012 at 02:38:40PM -0700, Vinnie Falco wrote: Please don't forget that FreeType's job is to render glyphs, nothing else. My opinion is that since FreeType opens the font file, it might as well process everything that is in it. Might the suggestion that FreeType could perhaps /parse and expose/ all tables without necessarily /handling/ all of them, help in this discussion? Analogous to Adam's audio/video example, could it make sense for FreeType to implement the audio/video demuxers (table parsers) and the video codecs (glyph rendering), but not the audio codecs (text layout)? (Something else: in this and similar discussions I don't hear anyone mentioning m17nlib for text layout, even though it aims to handle all aspects of all current unicode scripts. I've also found its API for that quite nice and elegant a few years ago. When it's mentioned, it's mostly in the context of multilingual input alone. Does it have pronounced disadvantages compared to Harfbuzz or Pango that I'm missing?) Kind regards, Emile. -- E-Advies - Emile van Bergen em...@e-advies.nl tel. +31 (0)78 6144845 http://www.e-advies.nl ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Getting the kerning pairs in under O(n*n)
The makers of m17n developed libotf which at a time provide some, although rather spotty, support for complex-script rendering. The OpenType Layout model is such that -- especially for Indic scripts -- an OpenType Layout engine (a library) must know a lot and interact well with OpenType fonts. The knowledge about the correct orthographic and typographic text layout in a number of Asian scripts is split between the OpenType Layout engine and OpenType fonts. The correct text layout is only possible in combination of these two. The FreeType project once started a sub-project called FreeType Layout, which was aiming to develop an OpenType Layout engine that would match the reference implementation, which is the Microsoft Uniscribe library on Windows. However, the FreeType developers found that they were not the right people to do that, so the project stalled. Then, the m17n developers created libotf. However, the FreeType Layout library was then forked into two separate OpenType Layout engines, one as part of Qt, the other as Pango, or something like that. Then, the projects were merged again, which resulted in HarfBuzz. And then, HarfBuzz was rewritten from scratch, which resulted in HarfBuzz-ng, which is now the current HarfBuzz. Independently of all that, IBM has developed the ICU Layout library as part of the ICU project, with a similar goal. More recently, the ICU Layout library was essentially abandoned but valuable portions of it were ported to HarfBuzz. Before 2011, ICU Layout was considered stable, and possibly the best solution for an opensource OpenType Layout library, while HarfBuzz was undergoing very dynamic rewrites. But in 2012, I believe that HarfBuzz has matched and surpassed ICU Layout. So it all did start with FreeType after all. HarfBuzz stemmed from it, went a complicated path, and arrived at where it is now -- which is *good shape* already. ICU Layout is probably second choice, while other solutions such as libotf are no longer developed and I wouldn't invest into them. Regards, Adam On 12-10-04 02:41, emile...@e-advies.nl wrote: Hi, On Wed, Oct 03, 2012 at 02:38:40PM -0700, Vinnie Falco wrote: Please don't forget that FreeType's job is to render glyphs, nothing else. My opinion is that since FreeType opens the font file, it might as well process everything that is in it. Might the suggestion that FreeType could perhaps /parse and expose/ all tables without necessarily /handling/ all of them, help in this discussion? Analogous to Adam's audio/video example, could it make sense for FreeType to implement the audio/video demuxers (table parsers) and the video codecs (glyph rendering), but not the audio codecs (text layout)? (Something else: in this and similar discussions I don't hear anyone mentioning m17nlib for text layout, even though it aims to handle all aspects of all current unicode scripts. I've also found its API for that quite nice and elegant a few years ago. When it's mentioned, it's mostly in the context of multilingual input alone. Does it have pronounced disadvantages compared to Harfbuzz or Pango that I'm missing?) Kind regards, Emile. -- 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
Re: [ft-devel] Getting the kerning pairs in under O(n*n)
Please don't forget that FreeType's job is to render glyphs, nothing else. My opinion is that since FreeType opens the font file, it might as well process everything that is in it. I'm with the majority. Layout and rendering are different kreatures. Auto-kerning is, however, a totally different story. Freetype should be able to provide some shape descriptors to help fitting the neighboring glyphs. For example, some sort of top, middle, and bottom protrusion to the right and to the left of center. Undeniably, Freetype is supposed to know the shape best. Why did Tetris just come to my mind? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Getting the kerning pairs in under O(n*n)
Hi, On Wed, Oct 03, 2012 at 02:38:40PM -0700, Vinnie Falco wrote: Please don't forget that FreeType's job is to render glyphs, nothing else. My opinion is that since FreeType opens the font file, it might as well process everything that is in it. Might the suggestion that FreeType could perhaps /parse and expose/ all tables without necessarily /handling/ all of them, help in this discussion? Analogous to Adam's audio/video example, could it make sense for FreeType to implement the audio/video container demuxers (table parsers) and the video codecs (glyph rendering), but not the audio codecs (text layout)? (Aside, I don't hear anyone mentioning m17nlib for text layout these days, even though it aims to handle all aspects of all current unicode scripts. I've also found its API for that quite nice and elegant. Weird is that I see it most often in the context of multilingual input alone. Does it have pronounced disadvantages compared to Harfbuzz or Pango that I'm missing?) Kind regards, Emile. -- E-Advies - Emile van Bergen em...@e-advies.nl tel. +31 (0)78 6144845 http://www.e-advies.nl ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Getting the kerning pairs in under O(n*n)
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. [...] Adam, this is an excellent analogy! Thanks for that. 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*. OK. So FreeType should obey the `gasp' table by default? Or should this be a new FT_LOAD flag? Or a rendering flag? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Getting the kerning pairs in under O(n*n)
Might the suggestion that FreeType could perhaps /parse and expose/ all tables without necessarily /handling/ all of them, help in this discussion? There is already an API which exposes all SFNT tables. Parsing doesn't make sense at all: The SFNT tables are written for *live access* (as done by HarfBuzz). Everything else makes it far too clumsy, slow, and memory hungry. BTW, I got the impression that Vinnie's JUCE stuff puts all kerning pairs into a table or so. In case this is true, it is dead wrong for reasons outlined by Adam. (Something else: in this and similar discussions I don't hear anyone mentioning m17nlib for text layout, [...] I think that m17nlib has one single target: Emacs. Consequently, it uses Lisp code to control it. However, as has been stated, the developers don't have time, energy, or whatever to further develop it, and IIRC it has been suggested by its authors that Emacs eventually switches to Harfbuzz also. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Getting the kerning pairs in under O(n*n)
The makers of m17n developed libotf which at a time provide some, although rather spotty, support for complex-script rendering. Is it really `spotty'? I've never tested it, but it seems that its Lisp framework should easily handle all aspects, and in case errors are found, m17n gets patched accordingly. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
