Re: Open-Type Support (was: Greek Prosgegrammeni)
on 11/22/00 4:19 AM, Marco Cimarosti [EMAIL PROTECTED] wrote: - AAT/ATSUI (see in http:/www.apple.com). Most of the "intelligence" is in the font itself, which also includes a state machine to operate substitution. The behavior of the smart fonts may be influenced by external user settings. John Jenkins already related most of the relevant information, but I'll just add that: http://fonts.apple.com/ is a much better place to go if you're looking for information on AAT, and http://www.apple.com/developer/ is the place to go for information on ATSUI. Deborah Goldsmith Manager, International Toolbox Group Apple Computer, Inc. [EMAIL PROTECTED]
Re: Open-Type Support (was: Greek Prosgegrammeni)
Lukas Pietsch wrote: a lot was said in this thread about intelligent rendering mechanisms, [...] I figure that people are mostly thinking of the technology called "Open Type", is that right? Right, but quite partial. There are several major technologies for rendering "complex Unicode scripts". Here are some of the principal ones: - Open Type itself (see in http:/www.microsoft.com). The "font-specific intelligence" is in the font itself; the "generic script intelligence" is in a software component called UniScribe. - AAT/ATSUI (see in http:/www.apple.com). Most of the "intelligence" is in the font itself, which also includes a state machine to operate substitution. The behavior of the smart fonts may be influenced by external user settings. - Graphite --my favorite, so far-- (see in http:/www.sil.org). Takes a "stupid" TrueType font and merges it with the "intelligence" written in an ad-hoc description language (GDL), to produce an "intelligent" font quite similar to AAT/ATSUI. The accent is on extendability and, specially, in supporting the Private User Area (which is a precious resource for linguistic research and defining new orthographies). - Omega (http://omega-system.sourceforge.net). Built on top of the old and glorious TeX typesetting system. It may becaome (or already is?) the standard for Unicode in Linux. - More... Other projects are ongoing, with a variety of approaches, philosophies, scopes, applications. OTH _ Marco __ La mia e-mail è ora: My e-mail is now: marco.cimarostiªeurope.com (Cambiare "ª" in "@") (Change "ª" to "@") __ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup
Re: Open-Type Support (was: Greek Prosgegrammeni)
On Wed, Nov 22, 2000 at 04:19:42AM -0800, Marco Cimarosti wrote: - Omega (http://omega-system.sourceforge.net). Built on top of the old and glorious TeX typesetting system. It may becaome (or already is?) the standard for Unicode in Linux. I've never seen Omega used under Linux, nor have I found any good (English) documentation for it, although it is shipped with tetex and hence with Debian and probably other Linux distributions. FreeType seems to support OpenType fonts. Pango (http://www.pango.org) apparently is going to use FreeType at some point, but is currently hacking some complex script support into bdf (http://www.wholehog.fsnet.co.uk/robert/indic/fonts.html). -- David Starner - [EMAIL PROTECTED] http://dvdeug.dhis.org Looking for a Debian developer in the Stillwater, Oklahoma area to sign my GPG key
Re: Open-Type Support (was: Greek Prosgegrammeni)
John Hudson wrote: At present, polytonic Greek is not supported in Uniscribe, I suspect because no one has determined that it needs to be. So, would you agree that it does need to be? Keeping in mind what Kenneth Whistler wrote: Not if the fonts they use map capital letter + ypogegrammeni character combinations into capital letter + full-size iota glyph sequences. Of course, if the fonts they use are not designed for correct use with polytonic Greek, then the default rendering behavior of the ypogegrammeni will not be what they expect or want. Time to upgrade the fonts. ... This is not all that sophisticated. It should be a matter that can be wholly encapsulated within the fonts: Font IFont II A. 0397 0313 0345 == 'H iota adscript 'H iota subscript B. 1F98== 'H iota adscript 'H iota subscript ... Many of us have felt all along that polytonic Greek should always be represented decomposed, and that the ELOT polytonic "character" encoding was a dangerous conflation of glyph design and character encoding concerns. ... Implementations that use full decomposition for polytonic Greek and fonts that correctly map the accentual and diacritic combinations are the best bet for consistency *and* good presentation in the long run. Mind that the case-mapping question we were discussing is just one minor aspect of the issue; the main task is much more general, and at the same time more straightforward (If we leave aside the issue of automatic case conversion and the fancy problems of, let's say, small-caps): the decomposed character sequences simply need to be mapped to the precomposed ones. It affects not only the iota subscripts/adscripts but also all the other diacritics. Without some glyph processing most combinations will never display readably. Since the precomposed glyphs already exist as Unicode codepoints, I suppose that the implementation would probably not even be very difficult, and not much of it would even depend on the individual font, would it? By the way, I wouldn't agree with Kenneth that it wasn't a good idea to have the precomposed characters in Unicode in the first place. I'm very glad they are there, since, as we see, the beautiful smart rendering features we are talking about are simply not yet available in mainstream text processing software. Much as I like the idea of the projects such as "Graphite" that Marco mentioned, I do think there are quite a number of people out here who would love to be able to handle Greek comfortably in their everyday all-purpose text-processing and browsing software. The precomposed characters are at present the only means they have to do so on a Windows platform. Adding smart rendering support for the decomposed characters would provide them with a much better means; I'd certainly agree with Kenneth about that. And I'd also think it would be preferable if that could be done system-wide and not just by some individual application, wouldn't it? So it seems as if Uniscribe looks like the best bet at the moment, for Windows users. What do the Microsoft people think? May we hope? Lukas
Re: Open-Type Support (was: Greek Prosgegrammeni)
At 08:05 AM 11/22/2000 -0800, Lukas Pietsch wrote: Mind that the case-mapping question we were discussing is just one minor aspect of the issue; the main task is much more general, and at the same time more straightforward (If we leave aside the issue of automatic case conversion and the fancy problems of, let's say, small-caps): the decomposed character sequences simply need to be mapped to the precomposed ones. It affects not only the iota subscripts/adscripts but also all the other diacritics. Without some glyph processing most combinations will never display readably. Since the precomposed glyphs already exist as Unicode codepoints, I suppose that the implementation would probably not even be very difficult, and not much of it would even depend on the individual font, would it? Mapping decomposed character sequences to precomposed is not something that necessarily needs to be done in a font, or even in a script shaping engine like those in Uniscribe. This could be handled entirely at the IME level (e.g. as a simple extension of keyboard input). Font level glyph processing is particularly adapt at handling character-to-glyph and glyph-to-glyph manipulations, character-to-character manipulations can be handled almost anywhere in an input process. By the way, I wouldn't agree with Kenneth that it wasn't a good idea to have the precomposed characters in Unicode in the first place. I'm very glad they are there, since, as we see, the beautiful smart rendering features we are talking about are simply not yet available in mainstream text processing software. The counter argument could be made: that if Unicode had not accepted so many precomposed diacritic characters, especially in the Latin blocks, smart rendering software would have become mainstream much sooner. It is unfortunately true that, if smart rendering were necessary to process German and French, it would have been a priority many years ago. John Hudson Tiro Typeworks | Vancouver, BC | All empty souls tend to extreme opinion. www.tiro.com | W.B. Yeats [EMAIL PROTECTED]|
Re: Open-Type Support (was: Greek Prosgegrammeni)
Let me add a little to what Marco has written: - Open Type itself (see in http:/www.microsoft.com). The "font-specific intelligence" is in the font itself; the "generic script intelligence" is in a software component called UniScribe. OpenType provides partial support for complex script rendering. It is dependent upon software to interpret the font-specific information in the OT tables in an OT font, and to also take care of some rendering issues which OT itself does not address (e.g. reordering as needed for Indic). These things can be handled directly by an application. MS has also provided the Uniscribe engine for this purpose, however. (There are some aspects of OT support related to fine typography that Uniscribe does not address. Uniscribe is intended eventually to provide adequate support for complex script rendering, however.) On Win9x/Me and on WinNT4, Uniscribe support must be explicitly written into an app; i.e. an app must explicitly call the Uniscribe engine to take advantage of its benefits. Word 2000 does this, for example, to handle Arabic, but it does not do this for Thai (except in the S. Asia version of Word 2000). In contrast, on Win2000, all Win32 text drawing interfaces make use of Uniscribe. Thus, *any* app running on Win2000 benefits from Uniscribe. As has been mentioned, current versions of Uniscribe provide support for some scripts but not others. Work is being done to extend the selection of scripts that are supported. Currently, polytonic Greek is not supported, but it will be supported in the future. New updates of the Uniscribe engine will appear next year with Office 10 and with Whistler (apparently Win2000 consumer version) or with other updates to Windows, Office or Internet Explorer. I have no idea what new script support will appear when. I just know that more is coming. OT implementations are being done for Mac and Unix/Linux. On the Mac side, Apple reps have made statements that suggest that they would incorporate system-level support for the aspects of complex rendering that OT itself doesn't provide (i.e. they'd write something comparable to Uniscribe). On Unix/Linux, I'm not sure what is being done about providing the support that OT itself lacks. - AAT/ATSUI (see in http:/www.apple.com). Most of the "intelligence" is in the font itself, which also includes a state machine to operate substitution. The behavior of the smart fonts may be influenced by external user settings. Essentially, all of the intelligence is in the font. (There is an external engine that runs the state tables in the font, but that's a generic engine - all the behaviour is embodied in the state tables in the font). Thus, complex script rendering for polytonic Greek (for example) is available if a system has an AAT font that implements support for that script. In order to take advantage of that capability, however, an application must be written to use the ATSUI text drawing interfaces rather than the older QuickDraw interfaces. Developers have been slow on the uptake, but Apple has been working hard to make it easier for developers to support these interfaces. - Graphite --my favorite, so far-- (see in http:/www.sil.org). Takes a "stupid" TrueType font and merges it with the "intelligence" written in an ad-hoc description language (GDL), to produce an "intelligent" font quite similar to AAT/ATSUI. The accent is on extendability and, specially, in supporting the Private User Area (which is a precious resource for linguistic research and defining new orthographies). The font technology itself is indeed very much like AAT, though there are some differences. The existence of GDL is an important difference, though I wouldn't have called it an "ad-hoc" language. It is a carefully designed high-level language intended to deal specifically with the kinds of issues involved in complex scripts. Graphite also relies on a generic run-time engine that interprets the state tables that are added to the font, and also requires applications to be written using special interfaces that call upon that engine. There is not yet support for this outside of SIL that I know of, though many have expressed interest. In particular, there has been a lot of interest in seeing this technology implemented for the Unix/Linux environment. - Omega (http://omega-system.sourceforge.net). Built on top of the old and glorious TeX typesetting system. It may becaome (or already is?) the standard for Unicode in Linux. Whatever Omega does or doesn't do, I wouldn't categorize it as a general script rendering system like AAT, OT/Uniscribe and Graphite. It is an end-user application, not a system extension for complex script support. I suppose you could write an app that only output text by generating TeX source and processing it via Omega, but I wouldn't expect to find much of a market for such an app. The other platform of potential interest is Java. Sun has been working on providing complex script support in Java 2.
Re: Open-Type Support (was: Greek Prosgegrammeni)
On Wed, 22 Nov 2000, John Hudson wrote: At 08:05 AM 11/22/2000 -0800, Lukas Pietsch wrote: By the way, I wouldn't agree with Kenneth that it wasn't a good idea to have the precomposed characters in Unicode in the first place. I'm very glad they are there, since, as we see, the beautiful smart rendering features we are talking about are simply not yet available in mainstream text processing software. The counter argument could be made: that if Unicode had not accepted so many precomposed diacritic characters, especially in the Latin blocks, smart rendering software would have become mainstream much sooner. It is unfortunately true that, if smart rendering were necessary to process German and French, it would have been a priority many years ago. I agree with you on this point. I guess this is kind of 'kitchen and egg' issue. Let me draw another example from Korean Hangul. If Unicode/ISO-10646 had just a subset of precomposed syllables (perhaps 2350 of them from KS X 1001) and left out the rest (some 8000 of them for modern Korean) to be composed out of Jamos(alphabets) in U1100 block, we would be more(though not very much more) likely to have rendering infrastructure on major platforms that can offer 'beautiful rendering features' for Hangul (which is essential for the full support of modern, let alone medivial, Korean). (I'm well aware that Korean delegation adamantly insisted that all 11,172 of them be included, but in retrospect...) And, the same might be true of Greek and other scripts for which both precomposed characters and 'component' characters (decomposed) are available. Jungshik Shin
