[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unicode and math symbols
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
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
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