[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:       Arun Sharma <arun () sharma-home ! net>
Date:       2002-02-25 18:18:35
[Download RAW message or body]

Keith Packard wrote:
> 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.

Yes to bad idea or Yes to illegal (i.e. violation of the protocol) ?

> The protocol specification says that the glyphs are directly indexed
> by the character codes delivered over the wire.

Did you mean to say "character codes" or "glyph codes" ? In the context
of Indian language support, there is a strong distinction between the
two.

Is it fair to say that the X protocol doesn't interpret those values (as
either character codes or glyph codes) and just uses them as "numbers"
used to index a font file ?

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

From my perspective, the client is "remote", because the X server is
always right in front of me. Also, in my environment - which has a large
number of headless boxes and just one or two desktops - I have always 
dealt with more X clients than servers. So numerically, it's easier for
me to reconfigure servers.

> Instead, as applications are installed, the relevant fonts can be
> installed along with them.

Yes, there are many benefits of using client side fonts like you've
pointed out.

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

It's not very uncommon in a heterogeneous environment where sysadmins
exercise strong control over headless servers (i.e. X clients), while
giving root access to people's desktop PCs (i.e. X servers). Often,
these servers don't even have a X server or fonts installed for security
reasons.

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

Agree on both points. It just so happens that - there are cases where
it's easy to modify the server. At the same time, there are environments
(Xvnc and Exceed for windows) where it's not easy to modify the server,
but it may be easy to modify the client, where the client side fonts are
more suitable.

My belief is that both client and server side solutions will be
prevalent in the short term and users will pick and choose what's right
for them.

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

If the X server and the X client have a firewall in between them, it's
unlikely that NFS will be usable. However, X can still tunnel over ssh.

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

That's true. Which is why we're not trying to add anything open type
specific to the protocol. Our proposal is:

1. Pass UTF-8 character codes to XDrawString() and friends. 
2. Keep the open type font specific information confined to the X
   server and use the existing APIs like XQueryTextExtents to communicate the
   information to the client. We may add some non-open type specific
   extensions for added performance.

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

Yes, reading the sources to some text widgets revealed this issue. We
have some proposals to batch those requests and query the metrics on a
"per run" basis, instead of one character at a time. But that'd be an
optimization not needed for correctness.

I just glanced at the XST client API spec and it seems to me that it is
a server side implementation. Comments ?

http://stsf.sourceforge.net/xst.pdf

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