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 [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
