On Thu, Aug 03, 2006 at 03:07:09PM +1000, Russell Shaw wrote: > Rich Felker wrote: > > ... snip long stuff > > I agree on the total crappiness of current "mainstream" GUI implementations.
Thanks. It's refreshing to have some support from the non-bloat crowd in m17n issues. Usually there's the standard dichotomy where bloat==m17n and lean==latin1... > A decent X GUI application should run blazingly fast on a 66MHz 486, and only > be a few tens of kB in size. I'd love to have X apps run well on old laptops > with 4MB video ram. For anyone laughing at your 486, remember: if your text rendering system takes 300 mhz for responsive realtime rendering, that's 300 mhz lost that could be spent on real processing. For instance (since I come from MPlayer I'll use a video example) decoding the movie rather than rendering the subtitles. > When "they" say core X fonts are deprecated, "they" do not represent anyone > but > their own agendas. Here's a great example of the propaganda machine: http://www.unifont.org/iuc27/html/img21.html Still, I think it is correct to say that the X core font system is deprecated, or at least the traditional use of it where fonts are encoded in character sets is deprecated. The only way I see for using it efficiently is to split a font into many glyphsets using fontspecific encoding, then access the glyphsets you need and translate test to glyphs before passing it to X. The problem is that this translation is fontspecific and the font is serverside while the information is needed clientside.. One possible approach I've considered is having the client application provide an X font server to serve its own fonts, the sole purpose being to allow them to be cached on the server side. The same thing can be done with serverside bitmaps/pixmaps however and it's probably less disgusting that way. > You might like to know that STSF (http://stsf.sourceforge.net/about.html) has > been unmaintained for a couple of years, but is being resurrected with a > recent > patch or two. It does server-side rendering and unicode. I am interested although I think it's both outside the scope of and unusable for what I'm doing right now. A character-cell font system needs to work in cells, not entire lines/words/strings. This is needed both for efficient update and for making sure the positions are correct. Also I need support for non-X devices. HOWEVER: since uuterm's display handling is modular and can easily be swapped for another implementation, I would be interested in having an STSF-based display module for it in the future. > I don't know how stsf handles exotic scripts (still learning stuff like > that myself). My threshold of what's "exotic" seems to be much higher than most people's by the way. > The other way is to use freetype2 and Xrender. This will also be quite > compact in size, > but you'll have to add all the glyph formatting scripts for different > languages if required. Xrender is unfortunately very slow, and for my present needs (a terminal emulator) truetype/opentype is really not feasible. You simply can't get good 8x16 glyphs out of an outline font... and if you're just going to have bitmap why bother with the whole big truetype framework? > STSF is designed for pluggable rendering engines without needing to > recompile X iirc. It would be better if it didn't even need pluggable engines, just some simple tables or interpreted bytecode. Honestly I wouldn't feel very comfortable loading new script modules written by m17n coders into the X server to run as root, given the quality of code I've seen from this scene in the past. Rich -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
