From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Wed Jun 04 2003 - 12:29:14 EDT
From: <Peter_Constable@sil.org>
> Jim Allen wrote on 05/30/2003 09:38:12 AM:
>
> > See also
> >
> http://www.usefulcontent.org/docs/manuals/REC-MathML2-20010221/isoamso.html
>
> > for some mathml characters and their unicode encodings.
> >
> > The character "empty" is encoded as U+2205 plus the variation selector
> > U+FE00 and has the description "/emptyset - zero, slash" and the alias
> > "emptyset".
>
> > At
> >
> http://www.usefulcontent.org/docs/manuals/REC-MathML2-20010221/byalpha.html
>
> > the entities empty and emptyset are both assigned to U+2205 followed by
> > U+FE00 while emptyv is again just U+2205.
> >
> > That the differing forms are indicated by a variation selector indicates
> > that the forms are seen to be "primarily glyphic variations" (see
> > http://www.unicode.org/reports/tr25/#13_7_variation_selectors).
>
> According to
> http://www.unicode.org/Public/UNIDATA/StandardizedVariants.html, there is
> no variation sequence < 2205, FE00 > defined. Somebody needs to tell the
> author(s) of this page that they can't make up their own variation-selector
> sequences.
Yes they can: this is a private agreement which is valid only in their context: MathML (note that this is still not a recommandation, but a proposal). It will become a Unicode approved sequence if there are requests for use of such sequence in a finalized MathML specification, and in other general contexts (such as language morphology).
In my opinion, if Unicode approves such new variants, it will keep the original U+2205 free of any glyph assumption (meaning that it can safely be represented as a slashed circle or oval or zero, upright or slanted.), and the more precise glyphs needed (if justified by the necessity of using two distinct symbols in the same document) will be encoded separately as variants.
In that case, the MathML proposal will become normative after correction, and usable outside of any MathML context (but in a FUTURE version of Unicode, and not if the encoded text is labelled Unicode-4.0)... Else, I don't see why it was needed to add more variant selectors, given that no other sequence is available that use them. These additions mean that they were fixed to allow easier interchanges for discussing new variants to approve later.
They can be used both in proposals and experimentally, with a private agreements between authors of a proposal... This way, it will allow to start the lengthy manual input of documents, that will be reencoded later with an automatic tool for a more general publication as plain/text (before that the documents can be shared internally and a PDF file or an HTML page with embedded graphics can be prepared for general interchange if a normative publication needs to use these characters)
This archive was generated by hypermail 2.1.5 : Wed Jun 04 2003 - 13:25:05 EDT