[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: "Martin J. Duerst" <mduerst@ifi.unizh.ch>*Subject*: Re: Unicode and math symbols*From*: bbeeton <BNB@MATH.AMS.ORG>*Date*: Mon, 24 Feb 1997 09:03:21 -0500 (EST)*Cc*: Chris Rowley <C.A.Rowley@open.ac.uk>, bkph@ai.mit.edu, tex-font@math.utah.edu*Flags*: 000000000000*In-reply-to*: <Pine.SUN.3.95q.970224125523.245C-100000@enoshima>*Mail-system-version*: <MultiNet-MM(369)+TOPSLIB(158)+PMDF(5.1)@MATH.AMS.ORG>

unicode (and other codes) deal with *meaning*, not form. there is a separate font/glyph standard, and a glyph registry for dealing with form; essentially all the math symbols associated with tex from computer modern, the ams extra symbol fonts, and the latex fonts are registered (i was involved, and i checked carefully). by "essentially", i mean that all "singular" symbols are included -- the pieces that make up a pieced brace, or the various sizes of radical signs -- and that includes separate and distinct text-class and display-class sums and integrals because of their differing treatment in those two environments. also, when the same shape can appear both as an ordinary symbol and as a relation, there are two different glyphs registered; the justification i used was that the side bearings are different, since a difference in meaning wasn't permitted. unicode does not at present incorporate all the distinct symbols that have been registered as glyphs. whether it should or not, i have still (after many years) not made up my mind; unicode is not, and never will be, suited to carry along anything but the basic identification -- any knowledge about positioning, relation to embellishments or adjacent symbols, etc., etc., is simply outside its scope, and therefore inclusion of something like an extensible radical sign must be by definition overly simplistic. on the other hand, all the symbols that have been registered as glyphs have also been included in the sgml public entity sets, where there is at least a chance of carrying along this extra baggage. i'm firmly against "one shape, one code"; without a lot of extra information provided in a non-code manner, it will never yield publishable math, and it's unclear to me that it will be intelligible either, in the sense required for systems that must be rendered in other than visual form. -- barbara beeton

**Follow-Ups**:**Re: Unicode and math symbols***From:*"Martin J. Duerst" <mduerst@ifi.unizh.ch>

**References**:**Re: Unicode and math symbols***From:*"Martin J. Duerst" <mduerst@ifi.unizh.ch>

- Prev by Date:
**Re: Unicode and math symbols** - Next by Date:
**Checksums (was re: 8r fonts)** - Prev by thread:
**Re: Unicode and math symbols** - Next by thread:
**Re: Unicode and math symbols** - Index(es):