[forum] some XFree86 5.0 questions...

[Alexander Gelfenbain]

On Sun, Mar 23, 2003 at 01:09:03AM -0500, Owen Taylor wrote:
> > That is true only within assumptions of the current text rendering
> > model. When applications use an encapsulated API like STSF, they
> > do not require glyph metric data. 
> > 
> > The advantage of encapsulated APIs is that the only thing applications 
> > need to do is to create a single object that represent a fragment of 
> > displayable text.
> > 
> > Such an object:
> > 	
> > 	- manages its highlighted regions 
> > 	
> > 	- can position a caret without external intervention
> > 	
> > 	- can be rendered in an atomic operation
> > 
> > Different encapsulated APIs tend to call such an object differently:
> > 
> > 	STSF calls it a "Line Object."
> > 	ATSUI and Java2D calls it a "Text Layout Object." 
> > 
> > Once such an object is created, the application does not need to know
> > any low-level details about text that it used to create it, including
> > metric data, font technology, etc. 
> 
> There is a very big leap of faith here from the idea that it's
> good to have an encapsulated paragraph object, to the idea that
> it's good to put it on an out-of-process server.

I was saying that encapsulated APIs remove the need to transmit
individual character metrics over the wire; and I don't think 
you are disagreeing with me.

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. 

Server-side implementation is potentially easier on resources 
(everything can be shared among multiple clients and even X servers)
and on the protocol (objects are referenced by integer handles.)

> 
> Possibly objections include:
> 
>  - Layout latency matters even if you can do it on a paragraph
>    level. A text editor needs to find the layed-out size of tens of 
>    thousands of paragraphs a second. 

That's very true for every client-server architecture, but it can
be remedied by adding requests that do operations on arrays
of data in one protocol roundtrip. 

A text editor needs to find the layed-out size of a lot of paragraphs
when it loads the document. During the editing process, however,
the most typical client-server operation would be client telling server
"text changed from offset X to offset Y, the new text is Z, 
recalculate the size of the paragpraph and redisplay it and remaining
visible paragraphs"  Only one roundtrip.


>  - The paragraph object is seldom going to be simple. PangoLayout
>    (Pango's paragraph object) has 40-50 methods, the Java class
>    seems to be similar.

We have 76 methods for Style/Text/Line objects in STSF now. Not
all of them are unique protocol requests though.

> 
>    Putting this degree of complexity at a protocol layer seems
>    a little bit questionable to me.

Why?

> 
>  - 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.)

Regards,
AG


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