Re: Too narrowly defined: DIVISION SIGN & COLON

There's something that is underused in the OpenType specification :
the possibility to bind different glyphs according to a given
language. If we had semantic characters encoded instead of just
characters encoded for their core visual aspect, we could make the
difference between cultures, according to user's locale preferences or
according to the document's language (provided that it is tagged
properly in its metadata).

But we've all seen that language tagging fails almost always. Language
tagging is generally false, or simply not defined by authors, and
automatic language identification most often works better (but with a
significant share of failures too).

For this reason, it is still best to create documents encoded using
visually encoded characters rather than semantically encoded. Yes this
means that the semantics of the characters will remain ambiguous, but
at least users will see the glyphs matching what was meant by the
document author in his own document and in his language (even if the
application used to view it cannot completely guess that information,
even from existing language tags which are generally wrong, or lost
during the transfer when working with downloaded documents, as the
language will then become the prefered one used by the viewing/editing
user in his own system).

Do we really need new semantic characters that will render differently
according to a language indication that is not even reliable ? And
that will create a lot new confusable and will cuase new security
problems (imagine the effect if the solidus-slash is not distinctable
and used in a filename or URL because it was encoded semantically as a
division symbol, and then an encoding conversion changes it in an
ASCII pathname separator ? Same problem with the colon (probably even
more critical if it allows accessing to another URI scheme or to an
hardware device).
Received on Mon Jul 09 2012 - 16:03:36 CDT