[Date Prev][Date Next]
[Thread Prev][Thread Next]
[Date Index]
[Thread Index]
[New search]
To: "FrameSGML List" <FrameSGML@xxxxxxxxxxx>, Free Framers <framers@xxxxxxxxx>
Subject: FM 6.0 and Unicode
From: Dan Emory <danemory@xxxxxxxxxxxx>
Date: Fri, 17 Mar 2000 14:49:12 -0700 (MST)
Sender: owner-framers@xxxxxxxxx
Adobe's failure to implement Unicode in 6.0 is a giant hiccup, but maybe there's a (somewhat awkward) way around the problem when using FM+SGML 6.0 to export XML from EDD-defined structured documents. The basic problem is that, without Unicode, entity references (defined in the ISO PUBLIC character sets for SGML) will have to be produced in the XML for upper-ASCII characters, plus any others which require the Symbol font. It should not be a big deal to build a post-processor that scans exported XML document instances for those entity references, and replaces them with the corresponding Unicode value. It also shouldn't be a big deal to build a pre-processor that would scan an XML document instance (conforming to some prescribed DTD) and convert Unicode characters corresponding to those in the ISO PUBLIC character sets to entity references (the pre-processor would also have to massage a few other things in the XML document instance to turn it into SGML that conforms to the same DTD as the one declared in the XML). With the proposed pre- and post-processors, it would then be possible to round-trip any XML document instance that was originally produced in FM+SGML. It should also be possible for the pre-processor to convert XML document instances not created with FM+SGML to conformant SGML if the DTD for the XML is known, provided that all Unicode characters corresponding to characters in the ISO PUBLIC character sets can be converted to the equivalent entity references. Admittedly, this proposed solution is by no means able to fully implement Unicode, since it would restrict XML characters above ASCII 127 decimal to those defined in the ISO PUBLIC character sets, but at least it's a start. It might even be possible to implement these pre-and post-processors as FM+SGML plug-ins. Does this sound feasible, and if so, do you think we could interest a third-party software developer (e.g., BlueBerry or Omni Systems) in implementing it? Your comments please. ==================== | Nullius in Verba | ==================== Dan Emory, Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing Voice/Fax: 949-722-8971 E-Mail: danemory@primenet.com 10044 Adams Ave. #208, Huntington Beach, CA 92646 ---Subscribe to the "Free Framers" list by sending a message to majordomo@omsys.com with "subscribe framers" (no quotes) in the body. ** To unsubscribe, send a message to majordomo@omsys.com ** ** with "unsubscribe framers" (no quotes) in the body. **