Re: [I18n]Re: [Fonts]Another approach to text in X
David Turner wrote: ... I didn't find that Brian Stell was harsh in any way.. Announcements are great things, but Sun has a history of disappointing the Open Source community. I'm pretty certain that the ST team is good-hearted and talented, I simply fear Sun's management and the SCSL :o) Just to be clear: I have not made any statement on the goodness or not-goodness of this work or any previous work by Sun. I would like to see what they have done as the international features in the X environment primarily came out of an older era. -- Brian Stell ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n]Re: [Fonts]Another approach to text in X
Around 11 o'clock on Dec 23, David Turner wrote: - a unified font type service for Unix, named UniType which has been more or less already described in Render mailing list. I've split Xft into two pieces; one of which (fontconfig) sounds a lot like UniType: o Independent of output technology or rasterization; it's just a configuration, customization and matching library o Persistant database of existing fonts o API is independent of FreeType2, although the implmentation uses FreeType2 to examine new fonts o Precomputed meta-data, the most important piece being the set of encoded Unicode chars. But, it looks like UniType has some additional features: - identify each installed/available face with a _unique_ and _persistent_ 128-bit signature. This seems like it will be useful in transmitting precise face names from one application to another, but I'm afraid that font versioning will make it less useful in transmitting face names from one machine to another. Is there some reason not to trust the font identification built into the files as usefully unique? My plan for 'fontconfig' was to use the names in the files and allow the application to discover how close the requested pattern was to the actual matched face. That way the application can discover whether the face names and styles matched, or whether some substitution was made. * languages _really_ supported by the face (answering this question is hard !!) I agree it's pretty hard, but I don't know if it's really needed. Applications need to find a face which covers a reasonable portion of the document, and then they need to find faces which can fill-in the missing pieces, and which match the other faces reasonably well. Owen Taylor and I talked about this at ALS and I think we've figured out a mechanism that will work with upper level libraries in a reasonably efficient way. The idea is to list all of the available faces in 'match' order -- the distance from the face to the requested pattern. Now this list can be searched to find a face containing any desired set of glyphs. Using a persistant list built when the font was requested ensures that the order is stable -- independent of the order in which glyphs are requested. The reason a single synthetic face can't be exposed from the underlying font library is that a document containing passages from different locales may well want to use different faces for the same char, depending on the context that char is found (think Latin glyphs near Kanji embedded in a document that also has pure Latin passages). Obviously, a trivial synthetic face can be built from this list; simply search for the first face holding each glyph. I think we should push language support out of this library, at least for now, and focus on describing the Unicode coverage of the faces instead. * list of X11 encodings supported by each face (for backwards compatibility) Yuck. If applications really need this, let's make them support it themselves. * embedded versions of some fonts, to avoid re-generating them each time.. Hmm. I think this conflicts with your goal of being independent of the rasterizer. Also, target platforms which really need to avoid the CPU cost are also likely to have limited storage, making it unwise to keep large numbers of glyph images around. Perhaps we could consider caching rasterization efforts to share among multiple applications; that could be dynamically sized depending on the environment. The Render extension encourages this, I've just not bothered to use it as rasterization performance has not been a significant bottleneck. - management of system + user + application font list (through pattern matching similar to libXft, or even _directly_ through libXft) Any library we build will be used by Xft. Obviously, I'd prefer to use the Xft pattern code that I've moved to 'fontconfig', but I don't think it's too late to bail on that if we think it advisable. Opinions on whether the Xft pattern stuff could be improved are very welcome. (that's a big difference with libXft that insists that you use FT2 for now). With Xft split into two pieces, the underlying font configuration mechanism does not expose it's own use of FT for this same reason. Xft itself will always expose it's use of FT so that applications can get at the native FT API to access more sophisticated parts of that interface. then: - A text layout engine, based on UniType, supporting all kinds of sophisticated features (including OpenType, we haven't really touched GX for the lack of fonts to test and interest we ourselves have in the technology). Yes, keep this separate so that we can get on with solving the font configuration and customization issues. I don't think we can
[I18n]Re: [Fonts]Another approach to text in X
Alexander Gelfenbain wrote: On Wed, Dec 19, 2001 at 07:20:45PM -0500, Sergey Babkin wrote: Alan Coopersmith wrote: applications. We have designed a display and platform-independent text architecture, the Standard Type Services (ST) framework, which handles not just font rendering, but text layout and font management as well. ST incorporates typographically sophisticated features and ideas from the best regarded existing APIs, including Apple Type Services for Unicode Imaging (ATSUI) and Java2D TextLayouts. On top of ST, we have layered a new extension to the X protocol, called XST, which incorporates the ST functionality. The ST API will also be exposed to applications independant of the X environment so that it can be used It would be good if it also could provide the output in PostScript. It would be capable of generating outlines. Converting them to PostScript is trivial. I think, not quite trivial. I guess I should first explain that I don't want to sound ungrateful, and the way it is now this architecture looks very interesting and useful. Just it seems to me that it's a great opportunity to fix the historical X's weakness with printing. And seeing it missed once again would be a pity. Basically, rendering the general graphics in PostScript is easy and does not require much effort. Rendering of the text is much harder. The major thing making it complicated is the fonts. Of course, transferring the outlines of a rendered page back is a possible thing but it means large size of the resulting file and slow rendering to bitmaps at the printer. Providing a way to convert the used fonts to PostScript fonts, transferring them to the client and then rendering the pages in terms of these fonts looks like a much better thing. And probably provide a protocol to get the kerning information on to the client (unless all the rendering including kerning is done at the server side). Such a conversion is trivial too in the sense that it's clear how it can be done, the only difficulty is to actually do it and to provide an X protocol extension for such a transfer: - the Type1 fonts can be transferred directly, only with the encoding table changed according to X the server's idea about it and with the large fonts split into multiple 8-bit fonts (and/or possibly then combined into a Type0 composite font) - the TrueType fonts can be either converted to Type42 with the algorithm taken from ttf2type42 or converted to Type1 with the algorithm taken from ttf2pt1 - the other fonts can be rasterized to bitmaps and then converted to the Type1 fonts with the algorithm taken from ttf2pt1 Actually, one more possibility is to take the outlines produced from any kind of font and feed them into the algorithm from ttf2pt1. Basically, what I'm trying to say is that since yet another extension is being added to the X protocol, it would be nice to include this font transfer ability into it. -SB ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n]Re: [Fonts]Another approach to text in X
A agree with you and we will try to get this functionality in ST, however I don't promise it will be in the initial release. In addition to translating entire fonts we are also planning to do font subsetting. AG Basically, rendering the general graphics in PostScript is easy and does not require much effort. Rendering of the text is much harder. The major thing making it complicated is the fonts. Of course, transferring the outlines of a rendered page back is a possible thing but it means large size of the resulting file and slow rendering to bitmaps at the printer. Providing a way to convert the used fonts to PostScript fonts, transferring them to the client and then rendering the pages in terms of these fonts looks like a much better thing. And probably provide a protocol to get the kerning information on to the client (unless all the rendering including kerning is done at the server side). Such a conversion is trivial too in the sense that it's clear how it can be done, the only difficulty is to actually do it and to provide an X protocol extension for such a transfer: - the Type1 fonts can be transferred directly, only with the encoding table changed according to X the server's idea about it and with the large fonts split into multiple 8-bit fonts (and/or possibly then combined into a Type0 composite font) - the TrueType fonts can be either converted to Type42 with the algorithm taken from ttf2type42 or converted to Type1 with the algorithm taken from ttf2pt1 - the other fonts can be rasterized to bitmaps and then converted to the Type1 fonts with the algorithm taken from ttf2pt1 Actually, one more possibility is to take the outlines produced from any kind of font and feed them into the algorithm from ttf2pt1. Basically, what I'm trying to say is that since yet another extension is being added to the X protocol, it would be nice to include this font transfer ability into it. -SB -- Alexander Gelfenbain, Sun Microsystems, Inc. +1 (408) 635-0612 ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n]Re: [Fonts]Another approach to text in X
Alan Coopersmith wrote: applications. We have designed a display and platform-independent text architecture, the Standard Type Services (ST) framework, which handles not just font rendering, but text layout and font management as well. ST incorporates typographically sophisticated features and ideas from the best regarded existing APIs, including Apple Type Services for Unicode Imaging (ATSUI) and Java2D TextLayouts. On top of ST, we have layered a new extension to the X protocol, called XST, which incorporates the ST functionality. The ST API will also be exposed to applications independant of the X environment so that it can be used It would be good if it also could provide the output in PostScript. -SB ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
