On Thu, Aug 03, 2006 at 12:21:56AM +0200, Werner LEMBERG wrote: > > > A revised, simplified file format proposal based on my original > > sketch, some of Markus's ideas for "NCF", and an evaluation of which > > optimizations were likely to benefit actual font data. > > What about using bitmap-only TrueType fonts, as planned by the X > Windows people?
Could you direct me to good information? I have serious doubts but I'd at least like to read what they have to say. > This has the huge advantage that both FreeType and > FontForge (and X Windows too in the not too distant future) already > support them. Quite frankly it doesn't matter it FontForge supports a bitmap font format because "xbitmap" is the ideal tool for making bitmap fonts. However as long as you can import and export glyphs I see no reason FontForge couldn't be used for this too. I also get the impression from some Apple papers i was browsing recently that TTF/OpenType put the burden of knowing how to stack combining characters and produce ligatures onto the software rather than the font. Under such a system, applications will never support all scripts unless they use one of the unweildy libraries with all of this taken care of... > I can't see an immediate advantage of a new bitmap format. ...on the other hand, at least for bitmap fonts, simple rule-based substitutions set up by the font designer can easily provide the needed functionality with less than 5kb of code doing all the glyph processing. Right now we're at an unfortunate point where the core X font system has been deprecated, but there is nothing suitable in its place. Moreover non-X unix consoles are essentially deprecated as well since they lack all but some patronizing Euro-centric 512-glyph "Unicode" support. Do you think someone is going to integrate FreeType into Linux anytime soon? :) All problem solving is about choosing the right tool for the job. Storing bitmap fonts in the TTF/OpenType framework is like using a nuclear missile to toast fruit flies, or like driving an SUV to commute to the office... When it comes to character cell fonts (which is an even narrower problem field than bitmap fonts), the goal is something that can provide the baseline support for readable and correct display of any script and that can work in any environment needing character cell display, from embedded systems to unix console drivers to 'poweruser' X sessions with 50 terminals open across 8 virtual desktops and half of them scrolling text constantly... What is NOT needed is more substanceless eyecandy that takes 500 megs of ram and 3ghz to run smoothly. Doesn't anyone find it a bit ironic that you can get translations of the featureless GNOME and KDE applets (which are about as bare and useless as the MS Windows "accessories") into almost any language and that the widgets display all the scripts correctly, but then when you go try to USE your language for any serious work on unix you find that everything displays bogus when you type "ls" in your shell, that most of the powerful text editors have no idea about something as basic as nonspacing characters, that ELinks still insists on dumbing-down the perfect UTF-8 it received from the web into a legacy codepage before converting it back to UTF-8 to display on your terminal, etc.? There's a severe gap in where the focus on m17n and i18n is being placed and where it's needed, and IMO a huge part of that comes from the fact that most competent unix users _scorn_ m17n and i18n because of the perception that it's inherently bloated. I've met plenty of people whose knee-jerk reaction after typing ./configure --help is to --disable any i18n-related option they see out of fear that it will fill up their disk with unwanted crap, introduce security vulns, or just make the program use 3-10x the memory it should.. Fears like this are compounded by the fact that, at present, the user is forced to make a choice between "lightweight configuration with incorrect or no m17n support" and "bloated configuration that pulls in Pango, glib, fontconfig, Xft, Xrender, ..." just to be able to get "odd scripts I don't really care about" to display properly. This sort of dichotomy of course perpetuates the lack of good support. GNOME coders who have no features in their apps except for the beautiful behavior of the gui widgets are happy to spend effort (and tens of megabytes) linking to the behemoth libs and patting themselves on the back for being "internationally friendly", while developers working on long-standing projects where most of the substance lies somewhere other than the gui presentation are baffled by these libs for which they understand neither the necessity nor the implementation. And unlike rad gui monkeys who are happy to copy-and-paste-and-glue whatever libs someone throws at them, people working on mature projects with actual features are weary of including support for anything they don't understand. The perpetuation of the myth that "correct rendering of all the world's scripts is difficult and requires advanced software" of course makes them even more weary. I could go on and on for years and years about this for sure. I'm extremely bitter about the sad state of m17n on unix and the fact that there is not even one working Unicode terminal with simultaneous support for all scripts. So with that said, I'll continue on with my draft bitmap font format (which already has a lot more simplifications -- remember, a work of art is only complete when you can't find anything left to _remove_ from it), write my 5kb of code, integrate it into uuterm, and somewhere in the next few months aim to have the first working Unicode terminal emulator... in a 50kb static binary. So much for "m17n is bloated crap"... Rich P.S. At the same time I'd be very happy to discuss bitmap and character cell fonts, others users' and developers' requirements for them (particularly for scripts I'm not familiar with). Also I have a tendancy to flame especially when I'm bitter about something. Please don't take anything I said too seriously except for that overall thesis that things are in a bad state and lightweight m17n support is critically needed in order to enable use and development of m17n in serious apps. -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
