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. > 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? > 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. > 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. Also it does not give more vertical resolution which is actually what's needed in certain scripts for small fonts to look good. > 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... Rich -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
