text and compositing

[Keith Packard]

Around 15 o'clock on Apr 23, Jon Smirl wrote:

> What is the plan for text generation, is it client or server side? Server side
> can pick up the transformation matrix and share the caching of gyph bitmaps
> between multiple clients.

In the Render extension model, all glyphs are rasterized by the client and 
transmitted as bitmaps.  The X server shares these bitmaps among multiple 
applications (yes, by brute-force comparison of the images).

That's been a very successful model for eliminating unnecessary complexity 
from the X server, and I'd like to make sure we don't accidentally 
roll-back the clock to server-side fonts here...

We could transmit glyph outlines to the server, but that begs the question 
of how to deal with hinting.  

TrueType hinting involves the interpretation of a low-level language
embedded within the TrueType font file which adjusts the position of the
glyph outline control points.  Type1 hinting involves the interpretation of
a set of suggestions included with the font; the code for that changes
wildly with each FreeType release.

If there were a notion of 'nominal' pixel size for the window, then we
could hint the glyphs to that size, transmit them as outlines and fill them
in the server.  This would optimize them for presentation at the nominal
size, and preserve their shape as the window was transformed.  To a great
extent, that's a desirable attribute; the alternative is to have the glyphs
(and spacing) jump about as the window is transformed.  This would also
provide a clear definition for how projective transformations would affect 
the appearance of the glyphs.

Now, all of this raises many questions about where tesselation occurs and 
where the 'flatness' value is applied to spline decomposition.  The 
PostScript specification requires that a flattened path rasterize the same 
as the unflattened path.  That's a nice invarient to include, but that 
would mean that the client-side decomposition visible through the path 
walking mechanism would have to produce the same answers as the 
server-side path decomposition algorithm.

There are also questions about the cairo stroke algorithm which currently 
assumes a constant pen shape and an affine transformation which preserves 
flatness computations across translation.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xserver/attachments/20040423/2d4bc014/attachment.pgp