On Mon, Oct 09, 2006 at 12:37:24PM -0600, Wesley J. Landaker wrote: > On Thursday 05 October 2006 16:03, Rich Felker wrote: > > A few comments on "Why not just use OpenType??": > > > > - The GSUB model does not adapt well to a character cell device where > > characters are organized into cells and where arbitrary string > > replacements don't make sense. > > > > - The glyph metric data is as large as the actual glyphs, doubling > > font size. Charcell fonts don't need any glyph metrics. > > > > - I don't think you can implement OpenType in less than 100 lines of > > C. The UCF char-to-glyph mapping algorithm is easy to implement and > > tiny. > > > > - Personally I like solutions that are adapted to the nature of the > > particular problem (character cell device) rather than trying to > > apply an overly general solution that will be awkward at best. > > > > - Something like UCF has a chance of getting into *NIX console drivers > > someday. I doubt anything OpenType-based would ever pass the > > necessary bloat tests to get integrated at such a low level. > > The main point here, which I don't argue against, is that OpenType is complex > and bloated when applied to minimally simple charcell devices. So, say I want > to go implement this right away... I code it up and... ah, no fonts!
Actually we have all of "GNU Unifont" plus plenty of other bitmap fonts, all of which are easy to convert. Unfortunately the European/Western glyphs in GNU Unifont are extremely ugly; if it weren't for that I would just have converted them already. I'll be working on the scripts that are interesting to me, but my viewpoint here is as follows: there are VERY MANY scripts with absolutely no terminal emulator that can display them, or with only one locale-specific terminal emulator with very poor features. If a terminal emulator implements UCF support, it _automatically_ supports these scripts as soon as someone makes a font. No coding is required by users wanting to get their script supported; just font drawing. While this doesn't help so much with the goal of getting a complete font for all scripts, it does make it very easy to achieve the local goal of supporting just one or two scripts you need, as the need arises. > To help create UCF fonts, it seems like having an OpenType to UCF converter > would be a *really* big help. Well, I mostly disagree. TrueType/OpenType fonts simply do not make legible character cell fonts, between not being designed for fixed width and the classic problem of poor rendering at small sizes. In any case, if you can make bitmaps from your OpenType fonts, it's trivial to use the glyphs in a UCF font, and programs to make bitmaps (e.g. BDF) out of OpenType fonts already exist. However, the OpenType tables for substitutions and positioning are built on an entirely different framework of layout that's about character sequences, baselines, and anchor points as opposed to character cells, so IMO there's very little hope of converting such tables in a meaningful way. If you have an idea for how this could be done, I'd be very interested in hearing it! Keep in mind that most glyphs don't even need any such tables. The vast majority of glyphs are CJK. Also, the fact that UCF doesn't need precomposed glyphs for accented characters cuts down vastly on the number of glyphs needed. As an example, my current Tibetan UCF font has only 113 glyphs because it makes powerful use of combining. Fonts with precomposed glyphs can have well over 1000. The situation for Latin is similar. > Even if you still had to tweak it manually > afterward for >75% of the glyphs, it would still be a big win, reduce a lot > of manual labor, and would help tide the "gee, UCF sounds like a good idea; > too bad there will never be any fonts" arguments. Well, we'll see. :) > Not to distract from your work here, No problem, comments are welcome. > but you implied that you are going to > work on converting fonts manually. Even just for your own use, wouldn't it > save you time in the long run to get a minimal OpenType to UCF converter > working? Well, my plan right now for fonts is split into several parts: For Latin, Cyrillic, Greek, etc. I plan to compile fonts in several styles: one that's classic VGA-style glyphs, one with a more standard modern non-bold terminal look, and one based on the font I personally use, which I designed for Latin-only a long time ago (extending it to non-Latin alphabets). The first two are matters of importing; the latter is a matter of drawing. For other scripts, I'm converting glyphs if there are nice existing ones (for instance the Thai font in GNU Unifont seems decent) and drawing new glyphs for scripts that don't yet have any good bitmap fonts. For scripts with heavy use of combining marks, shaping, or ligatures, a good bit of drawing would be necessary even if I found existing bitmaps, in order to make the shaping work right. This is especially true for Indic languages I think, which aren't well-suited to character cells but which can be forced to align to charcell boundaries without being much more offensive than fixed-width Latin is.. :) Rich P.S. It's my intent that a good UCF-using program would allow multiple simultaneous font files in use and search them all for glyphs. A more advanced one might even use separate fonts for Chinese/Japanese style ideographs, etc. and have terminal escapes or whatever to switch styles. -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
