Rich Felker wrote:
On Fri, Aug 04, 2006 at 03:46:29AM +1000, Russell Shaw wrote:
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
Eh? The goal is to move things to the server, not back to the client.
The only advantage of server-side fonts is that the user has control over
them on their own machine. Apart from that, everything that you can do with
client-side fonts should be doable with server-side fonts.
Server-side font mode is simply what internet web browsers do. You look
at web pages from a machine you have no account on. The only way to change
the fonts displayed is to change the font settings of your web browser.
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.
So the client downloads the font from the server, renders it, then
uploads the bitmaps (or other rendering primitives) back? This sounds
really inefficient. Or do you have the words client and server
reversed here?
This is how Xrender glyph rendering currently works, except that the
font is initially loaded on the client side.
The server-side setup could be done two ways:
1)In normal use, the client can just send glyph positioning coordinates
to the server, and the server does the bitmap creation and draws glyphs.
If the client needs to do extra stuff with glyphs, it can load information
about specific glyphs if needed.
2)The client downloads the font from the server, renders it, then uploads
the bitmaps back, where they're cached in the server. Each glyph would
get rendered and cached as needed, to avoid large delays of processing
a whole font file at once.
By server-side fonts, i simply mean that fonts can be loaded from the X server,
but the bitmap creation isn't neccessarily done by the server. It can still be
done on the client side, so you get all the advantages of client-side fonts.
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.
Basically there are two things programs use fonts for: interface and
documents/data. Interface fonts belong in the server and should be
rendered entirely by the server. Document fonts (fonts used in your
word processor, ps/pdf renderer, graphic design program, paint
program, ...) need to be under the control of the client at least to
some extent. When the client's output files depend on the particular
font rendering (e.g. gimp) then all the font handling and rendering
really needs to be client-side, like all other raster operations. When
the fonts are just needed for a wysiwyg preview (e.g. a word
processor) it's acceptable to have the server render the fonts as long
as the client can establish that the server has the right fonts.
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.
But why use xrender for this? The core X protocol can do the same and
it will work on any X server, not just new ones with an extension,
using plain X bitmaps.
The core thing loads whole font files if you query it iirc. Also, you can't
get more specific things such as the raw bitmap or bezier curve data.
There's some back-and-forth networking required when you want to calculate
the extents of words frequently, which i didn't like. A server-loadable
font setup should be as fast as a client-side font setup, which means
having access to all the font data from the server.
I really hate the grey blurry anti-aliased fonts. I've tried configuring
fontconfig and freetype and installing the latest freetype etc. With Xrender,
i can optimize the bitmap rendering myself with freetype.
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.
Subpixel only works on LCDs, which produce ugly output.
I think sub-pixel rendering also works for a crt, but a sudden change
in pixel value (such as the edge of a black square on a white background)
is smeared (convolved with the step response of analog electronics bandwidth)
into a few pixels on the crt. It shouldn't make sharpness any worse.
> Also it does
not give more vertical resolution which is actually what's needed in
certain scripts for small fonts to look good.
It does give the effect of extra vertical resolution. The effect is that
of a small amount of sub-pixel antialiasing, making sloping lines look
less jaggered. With a black edge on a white background, sub-pixel rendering
makes the individual r/g/b sub-pixels go from 100%(white)->67%->33%->0%(black).
Full-pixel anti-aliasing is what really wrecks the sharpness and darkness
of a glyph.
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
I'm so sick of intentional crippling. It HURTS us in the fight against
patents rather than helping us...
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
