[forum] some XFree86 5.0 questions...

[Owen Taylor]

On Fri, 2003-03-21 at 23:19, Alexander Gelfenbain wrote:
> On Fri, Mar 21, 2003 at 11:04:03PM +0800, Wu Jian Feng wrote:
> > Martijn Sipkema writes:
> > 
> > > - fonts don't need to be local.
> > > - better caching of fonts
> > > - access to fonts only by server. this also removes searching for
> > > available fonts from applications.
> > > 
> > > --ms
> > 
> > Thanks for your explaination, but some applications need glyph metrics
> > information to do their own text layout. 
> 
> 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.

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. 

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

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

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

Regards,
                                           Owen