[Date Prev][Date Next]
[Thread Prev][Thread Next]
[Date Index]
[Thread Index]
[New search]
Subject: Unicode support
From: "Lee Richardson" <lhr@xxxxxxxxx>
Date: Fri, 29 Jun 2001 13:58:44 -0700
In-Reply-To: <3B3C4D0D.FF489D3D@textmatters.com>
References: <5.1.0.14.2.20010628045803.03c70d90@mailsj.corp.adobe.com> <054601c0ffe3$877c1910$b77671d4@ydhomew2kws><p05100301b76173cb2ec2@[216.15.97.176]><3B3C4D0D.FF489D3D@textmatters.com>
Sender: owner-framers@xxxxxxxxx
'Full' Unicode support, say, compliance with Unicode 3.x and the ability to display, edit, print, spell-check, and hyphenate every character therein in a language-appropriate way, is going to be rare in the real world. There are the combining forms and composite characters, bi-di languages, and gaiji characters for Japanese et al. There are limitations in font variety; vertical CJK rendering would probably need to be included. Most editing and layout apps are therefore going to implement a Unicode subset, and will need a scheme for handling character points that aren't otherwise 'supported' or don't have glyphs available. In turn, much useful content can be stored in Unicode in XML without straying beyond current encodings, especially if you include the common CJK encodings like Shift-JIS. Using Unicode to store a doc in French doesn't suddenly add 100s of new character code points. FrameMaker handles French (and CJK) just fine. It will handle French Unicode characters just fine. Dmitry is making a different point. He wants support for Eastern European languages and encodings. Generalized Unicode support is one way to provide that, but isn't the only way and is not even necessarily the right way if that's all you want. I'm not arguing that FrameMaker should do a better, more-generalized job of handling different languages. I'm pretty darn clear on it, having had multiple conversations about the subject over the years, and core Unicode support is most likely the right way to implement it. Given the size of the task and priorities on other features, it isn't happening in the next major release. It is a high-priority item for the following one. You know, as a side note, Unicode is far from being a panacea. It's a somewhat better solution than what was previously available, enough to make it worthwhile, but requires almost as much work as the other solutions. And it will require work by users to either convert or fit into existing workflows, especially for shops using multiple versions of FrameMaker. ...Lee At 10:40 AM +0100 6/29/01, Mark Barratt wrote: >Lee Richardson wrote: >> That's silly. Full Unicode support has nothing to do with XML support > >I'm with Dmitry on this. The XML spec says: > >Legal characters are tab, carriage return, line feed, and the legal >characters of Unicode and ISO/IEC 10646. The versions of these standards >cited in A.1 Normative References were current at the time this document >was prepared. New characters may be added to these standards by >amendments or new editions. Consequently, XML processors must accept any >character in the range specified for Char. The use of "compatibility >characters", as defined in section 6.8 of [Unicode] (see also D21 in >section 3.6 of [Unicode3]), is discouraged.] ** To unsubscribe, send a message to majordomo@omsys.com ** ** with "unsubscribe framers" (no quotes) in the body. **