Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!ingr!dwig From: dwig@ingr.com (David Wiggins) Newsgroups: comp.windows.x Subject: Banish 'font not found' errors forever! Keywords: extensions, font Message-ID: <7872@ingr.com> Date: 5 Dec 89 22:10:17 GMT Organization: Intergraph Corp. Huntsville, Al Lines: 113 X Community, How many of you have been tripped up when you tried to run a client on a server that didn't have the needed fonts? Judging from the volume of postings in this newsgroup regarding this topic, it appears to be a common headache. We used to have this problem. We have many X applications which require special fonts. No alternative fonts are acceptable, because the special fonts contain symbols and icons that are not present in normal fonts. It is extremely frustrating to our users when, after successfully installing and running an application on one machine, it fails when they run it remotely. We agree with them - it is cumbersome to have to install the application's fonts on every server machine. Some of you may object, suggesting that clients should never require the server to have special fonts. Instead, you say, clients should stroke font glyphs into bitmaps and use XCopyPlane to draw them. Let's compare the performace of this approach to XDrawImageText. Take, for example, the network traffic involved in drawing 9 charaters: number of bytes/ bytes/ Method requests request total char XCopyPlane 9 x 32 = 298 32 XDrawImageText 1 x 28* = 28 3.1 * 16 bytes for the base request + 9 characters + 3 pad bytes = 28 bytes. Note that these numbers are actually skewed in favor of the XCopyPlane method because 1) we've ignored all of the requests needed to initially stroke the glyphs into the bitmaps, 2) the choice of 9 characters causes XDrawImageText to transmit 3 useless bytes, and 3) by drawing more characters, we could have made the XDrawImageString bytes/char much lower. Still, XDrawImageText wins by a factor of 10. Actual timing tests of the two methods bear these numbers out. On some servers, XCopyPlane was as much as 60X slower! Simulating fonts with bitmaps and XCopyPlane clearly involves an unacceptable performance penalty. Now that we have led you down the garden path (drum roll...) We have developed an X extension that enables a client to send a font to a server. (thundering applause) From the client side, it looks like this: void XSendFont(dpy, fontType, fontData, fontDataSize) Display *dpy; int fontType; /* font type (bdf, snf...) */ char *fontData; /* array of font data as it appears in font file */ int fontDataSize; /* size in bytes of fontData array */ There is also a higher-level function, XInstallFont, which takes a font pathname and sends the contents of the file to the server if the server does not already have the font. In the simplest case, clients would call XInstallFont before XLoadFont. Existing clients will not be affected. xsendfont, a trivial client built on XInstallFont, makes the extension useful even if no other clients explicitly use it. It looks like this: xsendfont [-display displayspec] [fontfilename ...] This extension solves several problems and eliminates the need for some rather expensive techniques that are currently in use. The sendfont extension provides a solution for applications that need special fonts: users install the application once, and the application negotiates with the server to insure that the server has the needed fonts. No more headaches for the user! A client may want to generate a font on the fly, and make the result immediately available for use by other clients. A font editor would be a good candidate. The core X protocol cannot satisfy this need. With a sendfont extension, it's easy. We have noticed that, in an effort to select an appropriate font, some clients cause the server to generate a reply on the order of several thousand bytes in response to an XListFonts(WithInfo). This bandwidth could be put to better use with our sendfont extension. XInstallFont queries the server for an exact font name match, and if the server doesn't have it, the font is sent. The amount of data transferred is comparable to the XListFonts solution, and the client always gets exactly the font it desires. One possible protocol-preserving solution is to concede that some clients need special fonts, and to rely on a general file transfer method to send them. This adds a measure of complexity that is visible to the user, who must arrange the communication between the X server and the font server. It also complicates the server, which must now support yet another protocol. (Our sendfont extension added less than 10K to our server.) Which seems better: two separate, largely redundant channels, one to send fonts and one for everything else, or one channel for both purposes? The designers of the X protocol apparently considered including the capability to send fonts, but ruled it out as a Bad Idea. Our main questions, then, are: What alternative methods were seen that justified omitting this functionality from the core protocol? Is the X Consortium working on anything like this? Is any member of the Consortium willing to take up this cause? Who else would like to see this capability? If you've been bitten by server font woes, speak up! If interest is shown, we will make source code (client half and server half) available to implement this extension. David P. Wiggins Software Analyst for the Intergraph X-Team dwig@ingr.com or uunet!ingr!dwig Disclaimer: all emotions and opinions are mine, not Intergraph's.