Server side text layout (was Re: [forum] some XFree86 5.0 questions...)

[Alexander Gelfenbain]

On Tue, Mar 25, 2003 at 10:28:55AM -0500, Owen Taylor wrote:
> > Encapsulated paragraph objects are good in general, and they
> > can be implemented either client-side or server-side. For example
> > STSF has two modes of operation - server side with STSF-enabled
> > X11 server and client-side with X11 STSF client library. 
> 
> This is perhaps where we part company ... you seem to think
> it is a good thing that STSF allows either client side or 
> server side layout. I think it is a disaster to have that
> sort of "flexible architecture". 

I believe in abstraction and encapsulation. STSF implements 
a text layout object. It abstracts out its implementation 
that can be either server-side or client-side.


> What I'd predict would happen is that most people will use 
> and develop with the client side libs, and then when someone 
> tries to use them with the server side layout, performance 
> will be abysmal, because you can get away with a lot of
> stuff with the client side libs you can't with remote layout.

I don't think this will happen. 

1) There is no reason to assume that most application developers 
will use STSF in "local library" mode. If STSF is widely available 
with the most popular X11 servers, there is no reason for application 
developers not to use the client-server mode. 

2) There are no benefits for *application developers* (like ease 
of debugging) in using STSF in the local-library mode. All STSF
objects are opaque. I doubt there will be too many STSF hackers
who will be debugging STSF itself. I can see that for them
it might be easier to use STSF in the local-library mode.

I am skipping over most of our discussion regarding client-side
vs server-side and going to the end of your email.

Client- vs server-side is a subject of a separate paper that
I will forward to you (and post on our web site) shortly.

> > >  - There may be needs to customize the layout process; to wrap
> > >    paragraphs to custom shapes, to implement custom line break
> > >    algorithms (say, to do global paragraph optimization) and
> > >    so forth. The Java2D way of doing this customization seems
> > >    to involve creating TextLayout objects for smaller pieces of 
> > >    text and positioning them youself:
> > > 
> > > http://java.sun.com/j2se/1.4.1/docs/api/java/awt/font/LineBreakMeasurer.html
> > > 
> > >    Which certainly won't work well if there is significant latency
> > >    for creating text-layout objects and finding out their
> > >    size.
> > 
> > 
> > STSF has special objects - STGlyphVector objects - that encapsulate
> > arrays of positioned and styled glyphs. If an application chose to 
> > use STGlyphVector objects, it indeed needs to query all metric data
> > for characters and position them. But after that the entire 
> > STGlyphVector object (which can be multi-line or multi-paragraph)
> > is displayable in one protocol request (that does not even require
> > a roundrtip.)
> 
> So, the choice is between:
> 
>  - Get good performance and i18n, but be restricted to exactly the
>    layout that STSF provides.
> 
>  - Get fully flexible layout, but get poor performance (the metric  
>    set is typically larger than the glyph images that need to be 
>    rendered), have to reimplement all of layout yourself, including  
>    complexities like bidi, and lose most of the i18n capabilities (I
>    assume there is no representation of, say, OpenType layout tables
>    in the the STSF get-the-metrics API call.)


You are missing one point. Glyph vectors and client-side layout is
not the only way to extend STSF layout processing. STSF layout is 
implemented as a layout engine drop-in object (shared library.)
The interface between STSF and layout engine objects is documented
and custom layout engines can be written and dynamically installed,
potentially without restarting the application or the ST Font Server.


Regards,
AG

-- 
Alexander Gelfenbain, Sun Microsystems, Inc.
+1 (408) 635-0612