[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xfree-fonts
Subject:    Re: [Fonts] Complex text layout and mapping screen coordinates
From:       Keith Packard <keithp () keithp ! com>
Date:       2002-02-25 9:03:01
[Download RAW message or body]


Around 0 o'clock on Feb 25, Arun Sharma wrote:

> Can you be more specific ? Are you saying that it's a bad idea or that
> it's illegal ? Do you think interpreting the argument to XDrawString()
> as a sequence of character codes instead of a glyph string would be a
> violation of the X protocol ?

Yes.  The protocol specification says that the glyphs are directly indexed
by the character codes delivered over the wire.  The client can directly 
compute the precise area covered by the text using the per-glyph metrics 
available via QueryFont.

> 1. In a networked environment, people have control over their desktop
>    machines, but not necessarily a large number of clients machines they're
>    logging in to.

If they can login, they can configure the machines.  Client side fonts 
means that font configuration is *always* under the control of the 
application, and through them the user.  Server side fonts means that the 
application might be able to configure the fonts, or it might not.  In a 
networked environment, this means that applications must suffer with the 
available fonts instead of being able to provide appropriate fonts from 
their local filesystem.

Remote machines are often X terminals or low-cost PCs with fixed 
configurations; requiring these to constantly be reconfigured to support 
new fonts is unreasonable.  Instead, as applications are installed, the 
relevant fonts can be installed along with them.

I've been doing networked computing for a rather long time using both 
server-side and client-side fonts.  It's a rare thing when the user and 
the server know which fonts to use but the application does not.  It's 
even rarer that the user has the ability to configure the server and not 
the client.

> 2. Client side fonts require the fonts to be installed on each one of
>    the client machines - basically requiring that all the clients be
>    localized. A server side solution only requires that the clients be
>    internationalized - not necessarily localized.

Whereas server-side fonts require every X server to be localized for any
possible locale that the applications may want to use.  This idea that
users access data in a single locale is total fiction -- I run applications
using dozens of languages that cover a large fraction of the Unicode space.

Asking me to get my fonts installed on every device I may run those
applications is a daunting chore; instead, I can take advantage of NFS (or
other network filesystem) and install the fonts in one central place,
applications can access those fonts over the wire using a nice existing
protocol that is well supported and is independent of the font file format.

> 3. If we ever were to make open type fonts network transparent,
>    communicating font information to the client over the network may
>    be expensive. It's the classic question of - do you move
>    code to where data is or do you move data to where code is ?

We already have network transparent font file access -- it's just called 
remote file access.  Suitable caching strategies can resolve any bandwidth 
issues.  FreeType MMAP's the font files so that unused portions need never 
transit the wire.  Attempting to develop a font file format-specific 
network protocol is a horrible mistake; again, setting the wire format in 
stone to match a particular set of font capabilities makes it difficult or 
impossible to migrate to new formats that offer functionality unknown in 
the current formats.

> True. What's wrong with the client doing the layout, but using the
> "services" of the X server for handling the information in the open type
> font file ? If the client handles line breaks, it could possibly
> send a line of data to the server at a time to query its extents.

Now you've restricted our fontfile format to OpenType.  The protocol now 
encodes precisely the information available in that format, and not any 
future formats.  Because the wire protocol changes so slowly, this means 
that future font formats will take a long time before they are available 
to applications.

In addition, moving the services to the X server requires a lot more 
traffic between the X server and the application -- most line 
justification and typesetting algorithms require incrementally querying 
the metrics of the entire line after adding each character.  That's dozens 
of round trips for each typeset line unless the client can precisely 
compute the metrics of the text locally.

Keith Packard        XFree86 Core Team        Compaq Cambridge Research Lab


_______________________________________________
Fonts mailing list
Fonts@XFree86.Org
http://XFree86.Org/mailman/listinfo/fonts
[prev in list] [next in list] [prev in thread] [next in thread]