Around 17 o'clock on Feb 26, Alexander Gelfenbain wrote:
> We don't believe implementing ST on top of Xft/fontconfig/FreeType is a good > idea. ST is designed to be scaler-independent. We want to be able to use a > variety of open-source and commercial scalers with ST, including FreeType and > commercial scalers from Adobe, Bitstream and Agfa. FreeType is not a particular scaler, it is an API under which many scalers can operate. It currently provides several open-source scalers for various formats, but also permits easy integration of new scalers as well. Bitstream is currently working on migrating their proprietary scaler to work as a plugin within FreeType. They currently plan on offering that as a part of their btX product line. I've committed to them that the X server will use FreeType2 so that their plugin will solve font access for all applications under Linux based on that standard API -- the X server, Qt3, Gtk+ 2.0 and Mozilla will use FreeType2 as the scalable font API. There's no reason Agfa and Adobe couldn't benefit from the common FreeType API and provide their scalers as FreeType plugins as well. This would certainly broaden the market for their scalers as applications wouldn't have to be customized to use their products. We aren't ready to standardize on a text layout mechanism, so there will be more than one such for quite a while. I suggest that it would be productive to work together on the underlying infrastructure so that font configuration and customization will work across multiple layout engines. Whether ST wants to use additional scalers is a separate issue. Fontconfig provides a scaler-independent font configuration and customization mechanism that ST could use while still providing access to alternate proprietary scalers. > We are planning to add a "local" XST mode where it would send bitmaps to > the X Server just as Xft does. It gives a clear transition path for > applications since the API will not change while the implementation > transitions from the client mode to the server mode. Then this local XST mode could use the Render extension, providing a complete high-performance implemetation that would run on all XFree86 servers. This would eliminate the need for a new X extension. As I say, I'm all for the widest possible research in the area of text layout. I'd like more than one to be available to application developers on every platform so that we can all get a better understanding of the subtle issues involved in developing such systems. While diversity is important at some levels, there are other levels at which standardization can happen today. Let's work to fit our diverse ideas into a relatively standard framework so that users don't suffer from our development model. > We believe ST provides a reasonable level of abstraction for font > capabilities now and I doubt that there will be any new font formats > designed any time soon that use a significantly different paradigm that > would require any protocol changes. Typography is a very conservative > industry, and investments in existing font technology are huge. When X started, Type1 fonts were just starting to become available; the Apple Laserwriter was introduced in 1985, the same era that X was designed. Since that time, we've had two fundemental shifts in type systems (TrueType and OpenType) and *no* change in core X text support. Typography may be a conservative business, but the X protocol demonstrates even more resistance to change. I'd hate to lock ourselves into a new protocol and discover in a short time that it was as useful as the core protocol is today. Keith Packard XFree86 Core Team Compaq Cambridge Research Lab _______________________________________________ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
