dwig@ingr.com (David Wiggins) (12/06/89)
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.
grunwald@foobar.colorado.edu (Dirk Grunwald) (12/07/89)
I myself would LOVE to see this change implemented, even if only as an extension. At the same time, it would be nice to implement a general RLE font format, e.g. something like the PK packing used for TeX fonts. This would reduce the transmission I/O time for the server and save oddles of disk space. From my understanding, a machine-independent font format has been proposed for X11R4, but it only stores information about byte order, etc - it doesn't compact anything. A compact, machine independent storage format is really needed.
jim@EXPO.LCS.MIT.EDU (Jim Fulton) (12/07/89)
[description of an X extension to allow downloading of fonts] ... Is the X Consortium working on anything like this? Sort of. Instead of having an explicit extension to download fonts, we hope to develop a font server next year. When you need application-specific fonts that your site administrator hasn't installed, you'll just start up a font server and add it to your FontPath: % ls font1.bdf font2.rle font3.pk ... % fontserver appfonts & % xset fp+ `hostname`:appfonts % application In addition to greatly relieving some of the administration burden, the font server can be made arbitrarily smart about rasterizing various types of fonts, allowing different input (e.g. scaled) and output (hardware-specific) formats. Jim
dwig@b11.ingr.com (David Wiggins) (12/12/89)
In response to my posting about the sendfont extension, Jim Fulton says: > ... Instead of having an explicit extension to download fonts, we hope to >develop a font server next year. Does this mean that the Consortium realizes there is no good, existing workaround to the problems I've mentioned? Is the Consortium committed to developing the font server? When will it be available? We had an urgent need for a solution to font installation problems, and we can't wait another year. Are we the only ones who feel this way? My email shows people from at least 5 other organizations that see the sendfont extension as a possible solution to their font installation troubles. The sendfont extension provides a low-level font transport mechanism upon which fancier services, like the font server, could be built. Since the lower layer is ready now, we'd like to promote it to avoid duplication of effort and so that work can progress on higher layers. [description of how the font server might work...] > % xset fp+ `hostname`:appfonts This method of telling the X server about the font server will be vulnerable to server resets. It's a minor point, but we do get support calls asking why xhost doesn't work, or why does the picture on my root window spontaneously disappear? Server reset strikes again... >In addition to greatly relieving some of the administration burden, the font >server can be made arbitrarily smart about rasterizing various types of fonts, >allowing different input (e.g. scaled) and output (hardware-specific) formats. These are very sexy capabilities; unfortunately, it won't solve the problems we faced. Quoting myself: >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. Now replace the word "server" with "font server" and the problem reappears. The user must know ahead of time which machines will act as font servers, so that the fonts can be installed on those machines, or be willing to manually install fonts on the font server when a client asks for a font it doesn't have. The sendfont extension allows clients to propogate fonts on demand with no intervention by the user. Also, applications may want to create fonts on the fly. Can you do this using the font server? We would like to have some kind of support from the Consortium for the sendfont idea. What avenues of cooperation are open? > Jim David P. Wiggins uunet!ingr!dwig or dwig@ingr.com Software Analyst, Intergraph X-Team
gjc@mga.COM (George J. Carrette) (12/12/89)
I've been experimenting with NOT USING FONTS AT ALL for some character graphics applications. The reason is that I want to be able "download" my own custom mathematical fonts. The obvious implementation using an off-screen pixel array for your font and copy-pixel operations for draw-character and draw-string works well enough on my vaxstation-3100 (VMS). -gjc
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (12/12/89)
Does this mean that the Consortium realizes there is no good, existing
workaround to the problems I've mentioned?
"The Consortium" as a body has not discussed your message.
Is the Consortium committed to developing the font server?
The Consortium typically makes progress through the participation of
engineers in its member organizations. There is considerable interest
in developing a font server.
When will it be available?
No commitments.
The sendfont extension allows clients to
propogate fonts on demand with no intervention by the user.
Well, only sort of. You must be assuming the entire contents of all those
fonts are embedded in the application, rather than being in files (blech).
Otherwise, finding those files is equivalent to finding a font server.
Also, applications may want to create fonts on the fly. Can you do this
using the font server?
A font server could provide this capability, yes. The application could
itself become a font server, if it really wanted to.
We would like to have some kind of support from the Consortium for the
sendfont idea. What avenues of cooperation are open?
Progress is made in the X Consortium by having proposals backed and pushed
by member organizations. You can either join the X Consortium and push the
idea yourself, or find some member who's willing to push it for you.jim@EXPO.LCS.MIT.EDU (Jim Fulton) (12/12/89)
Does this mean that the Consortium realizes there is no good, existing
workaround to the problems I've mentioned?
To quibble a bit, "good" depends on your point of view. Aesthetically, I think
the current situation sucks. Practically, though, it is at least manageable.
The problems are most acute on X terminals and PC's and most of those vendors
are already supplying a variety of ways of coping with the problem. Yes, it
isn't pretty, it isn't easy, and it needs a better answer.
When will it be available?
Who knows. Realistically, I would assume that various vendors would start
shipping it as soon as it became a Consortium standard. But like all
Consortium standards, that process does take a little while. If you are
in dire straights, definitely talk to you vendor. There is nothing that
prevents them from adding such an extension.
This method of telling the X server about the font server will be
vulnerable to server resets.
As usual, your base fonts would be configured initially by the server and
then by your session manager. I certainly wouldn't want to type a bunch of
xset fp's every time I login either.
>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.
Then fix your servers to do a private font service, use NFS to provide a
common font area, or code your extension. No one was trying to inhibit your
ideas, just to let you know the direction in which we'd like to go.
The user must know ahead of time which machines will act as
font servers
Unclear. There are a variety of techniques for locating services in a
network. Preconfiguring is one; broadcasting for service is another. The
XDMCP specification provides a good illustration of how this can be dealt with.
The sendfont extension allows clients to
propogate fonts on demand with no intervention by the user.
Granted, and you might well decide to put it into your server. Given how
close we are to the end of "this yearish", you can guess how tightly the R4
server is locked down.
Also, applications may want to create fonts on the fly. Can you do this
using the font server?
Sure. Off the top of my head, I can see several different approaches:
1. Perhaps SendFont could work in the font server context. But, then
that has some of the same problems as having the extension in the
server (e.g. do you allow partial downloading of fonts [something
that is imperative for large fonts], what sort of authorization
policies would you want, etc.).
2. I think that a better solution would be for the application to spin
off its own font server and tell it when it has a new font
(through a signal, font server control protocol, etc.).
Again, this is all just brainstorming.
We would like to have some kind of support from the Consortium for the
sendfont idea. What avenues of cooperation are open?
The best thing would be for you to join the Consortium (any organization is
both welcome and encouraged to join). Then you could propose the extension
directly. Given the enthusiasm that you clearly have for this, I really hope
that you do join.
Jimjim@EXPO.LCS.MIT.EDU (Jim Fulton) (12/13/89)
If you are in dire straights, definitely talk to your vendor. To clarify a bit, this was directed at application users. Since David *is* a vendor, he clearly doesn't need to go talk to himself about his own servers! However, talking to other vendors to convince them to do the same extension is always an option. Jim
mlandau@bbn.com (Matt Landau) (12/13/89)
dwig@b11.ingr.com (David Wiggins) writes: - In addition to greatly relieving some of the administration burden, the font - server can be made arbitrarily smart about rasterizing various types of fonts, - allowing different input (e.g. scaled) and output (hardware-specific) formats. "Can be made arbitrarily smart..." Are you talking about different font server implementations being able to take some known set of input formats (which may differ from font server to font server) and generate X-server compatible font information, in which case you can only use input formats that are supported by your font server vendor? Or is the plan, to the extent there is one at this point, to make all font servers agree on at least one basic format (like BDF), so that you can adapt to new input formats by writing a format-to-BDF translator? Is there a wmtalk-like mailing list that's currently discussing font server issues? >Also, applications may want to create fonts on the fly. Can you do this >using the font server? This is a good point -- suppose I'm an application writer who has gone and licensed font-scaling software and outlines from Sun, Bitstream, or J. Random Font Foundry. My application now has the ability to generate its own fonts on the fly in response to what the user asks for -- only I can't currently get the server to know about them! At least one vendor I know of has dealt with the problem in current generation X11 by generating all the glyphs on the client side then building bitmaps for each line of text and shipping them to the server for display. It works, but it's slow and kludgey. Will the proposed font server allow an application to tell the server about new fonts while it's running? If so, then it's particularly crucial that every font server accept some agreed-upon format, so that as a bare minimum I KNOW my application can take my nonstandard outlines, generate bitmaps at some desired size, turn them into BDF files, and hand them to a font server, which will tell the X server about them. (Actually, allowing applications to define new fonts at runtime seems like it's going to require a server extension no matter what...) -- Matt Landau Waiting for a flash of enlightenment mlandau@bbn.com in all this blood and thunder
jim@EXPO.LCS.MIT.EDU (Jim Fulton) (12/13/89)
"Can be made arbitrarily smart..."
Are you talking about different font server implementations being able
to take some known set of input formats (which may differ from font server
to font server) and generate X-server compatible font information, in
which case you can only use input formats that are supported by your
font server vendor?
Different font servers will probably be able to take any format that they
choose, with BDF as a required minimum. Font vendors will undoubtedly supply
font servers that understand their scalable formats. Your system supplier may
choose to OEM technology from the font vendor, or you as an end user might
license the font server directly.
One might then hope for a publicly available version that would understand
something like MetaFont or one of the many other scalable formats that the
trade press claims will be published soon. Instead of pregenerating millions
of BDF files, the font server would simply rasterize on the fly (probably with
some sort of lru caching).
Will the proposed font server allow an application to tell the server
about new fonts while it's running?
I certainly would want my font server to be able to do this....
(Actually, allowing applications to define new fonts at runtime seems like
it's going to require a server extension no matter what...)
Depends on whether or not "at runtime" means redefining glyphs and metrics out
from underneath existing applications. If you allow the font server to look
at font state only on initial open like the X server does (meaning that it
logically caches the font data so that changes in the data aren't reflected in
any subsequent queries), then there shouldn't be any problem. Whenever a new
font is created, the X server could receive the equivalent of a
CatalogueChanged event instructing it to throw away any local notions of the
contents of the indicated current catalogue.
Anyway, enough back-of-the-envelop sketching,
Jimdwig@b11.ingr.com (David Wiggins) (12/15/89)
In article <114@eileen.mga.com>, gjc@mga.COM (George J. Carrette) writes: > I've been experimenting with NOT USING FONTS AT ALL for some character > graphics applications. The reason is that I want to be able "download" > my own custom mathematical fonts. The obvious implementation using > an off-screen pixel array for your font and copy-pixel operations for > draw-character and draw-string works well enough on my vaxstation-3100 (VMS). > > -gjc Are you really satisfied with this? Isn't it tantalizing to think that your text drawing could be occuring several times faster if you could only feed your font to the server? To us, it was irresistable; thus the sendfont extension. David P. Wiggins uunet!ingr!dwig or dwig@ingr.com Software Analyst, Intergraph X-Team
dwig@b11.ingr.com (David Wiggins) (12/15/89)
In article <8912121349.AA23926@expire.lcs.mit.edu>, rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: > The sendfont extension allows clients to > propogate fonts on demand with no intervention by the user. > > Well, only sort of. You must be assuming the entire contents of all those > fonts are embedded in the application, rather than being in files (blech). The font data can come from anywhere: it can be embedded in the code, generated on the fly, or stored in a file. > Otherwise, finding those files is equivalent to finding a font server. Lots of existing applications and utilities find files that they need at run time with no help from the user, usually by looking in fixed locations. Maybe that's inelegant, but it seems to be widely accepted practice. Would it be as acceptable for a client to expect a certain machine name to be the fontserver? Maybe so; I can't say. David P. Wiggins uunet!ingr!dwig or dwig@ingr.com Software Analyst, Intergraph X-Team
gjc@mga.COM (George J. Carrette) (12/16/89)
In article <6846@b11.ingr.com> dwig@b11.ingr.com (David Wiggins) writes:
[gjc comments about not using fonts]
Are you really satisfied with this? Isn't it tantalizing to think that your
text drawing could be occuring several times faster if you could only feed
your font to the server? To us, it was irresistable; thus the sendfont
extension.
Yes and no. Yes in that for mathematical applications my font characters
are large enough and self-contained enough that each "Symbol" (which may
actually be a sequence of characters, e.g. "Xi" "Z.3") has a lot
of information in it, from the users point of view, so the all important
"information-paint-rate" (IPR), appears to be acceptable.
No in that I see no reason, (from having looked at the instruction sets
of some of the latest graphics chips) that general BITBLIT type operations
from pixel arrays to windows should not be approximately competitive
with so-called "character set" special case handling. Of course you get
a different idea if you are talking about the implementation, in C,
of the R3 X11 server.
For painting english text one might think about a cache mechanism for
the most common words being painted to the screen. Why limit yourself to
"fonts." Certainly *people* don't READ a character at a time, they read
a word at a time, or words at a time, so why not *display* a word at a time?
-gjcgrunwald@foobar.colorado.edu (Dirk Grunwald) (12/16/89)
the advantage of using fonts is that they have a normal ``stride'' or escapement associated with them; also X has primities to lay down multiple glyphs at once. Thus, when you lay down a strng "foo", the first "o" will follow "f" and so on - this makes for much faster display because you don't have to specify the X,Y locations for each glyph.