Rich Felker wrote:
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.
If the X font system had some extra features added, server-side fonts
would probably be ok.
All that's needed is extra protocols for loading extra font info from the
server to the client on an as-needed per-glyph basis. All the details
required of a font need to be included, such as bezier curve coefficients
or bitmaps, kerning tables, bounding boxes, horizontal/vertical bearing and
advance etc. Unlike the current setup, it wouldn't load a whole font file
in one go.
I still haven't made up my mind if server-side fonts are really needed.
They'd be needed for users running X clients on a remote machine they
don't have an account on, but want to be able to set their own fonts.
It is somewhat appealing to have the X server be more of a dumb rastering
device that doesn't even have draw_line() or draw_text() functions, but
just draws primitive objects such as polygons, with all the intelligent
drawing done in the client libraries. Something more efficient than polygons
is needed, to avoid large amounts of network traffic.
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?
Xrender can be very slow when it used for things it is unsuited for.
This includes anything with curves such as circles or arcs. Tons of
polygons are needed to get a smooth edge. You need higher order primitives
without flat edges if you don't want to flood your network with small flat-edged
polygons.
Xrender can hold lists of bitmap glyphs in the server, which means you just send
a glyph index and x/y coordinate to render one. I think that's quite fast. You'd
easily get the impression that Xrender is very slow from the typical bloated and
slow apps that use/abuse it for eye candy.
Freetype2 can be compiled in pieces, so you could leave out the truetype
part i think.
However, when you render a glyph with freetype into a bitmap for Xrender, you
can do sub-pixel rgb rendering that gives the effect of anti-aliasing that is
three times sharper than pixel-level antialising. That gives quite smooth curves
that could look ok, making mono-space truetype fonts useable for terminal stuff.
I noticed that to do kerning, you have to place each glyph individually in
Xrender, even though Xrender can take strings of glyphs. It would be easy
to modify it so that you could get per-glyph kerning on whole strings. I think
it was intentionally crippled because of political BS as evidenced in the last
paragraph: http://lists.freedesktop.org/archives/cairo/2003-July/000253.html
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.
By rendering engines, i meant things like freetype that do the actual
bitmap generation.
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
