Re: Tag characters and in-line graphics (from Tag characters)

Note: Everything below is my personal opinion and does not represent any
official Unicode Consortium or UTC position.

William_J_G Overington <wjgo underscore 10009 at btinternet dot com>
wrote:

>> Historically, Unicode was not meant to be the means by which brand
>> new ideas are run up the proverbial flagpole to see if they will gain
>> traction.
>
> History is interesting and can be a good guide, yet many things that
> are an accepted part of Unicode today started as new ideas that gained
> traction and became implemented. So history should not be allowed to
> be a reason to restrict progress.

I used "historically" to distinguish between the pre- and post-Emoji
Revolution eras. There have clearly been changes recently, but there is
still at least a minimal expectation that proposed characters will
fulfill a demonstrated need.

I'm not seeing any truly novel, untested ideas in the list below that
Unicode implemented purely on speculation.

> For example, there was the extension from 1 plane to 17 planes.

That was an architectural extension, brought about by the realization
that 64K code points wasn't enough for even the original scope. There's
no comparison.

> There was the introduction of emoji support.

Emoji proponents would argue that "emoji support" began in 1.0 with the
inclusion of various dingbats. But even emoji are arguably "characters"
in some sense. They aren't a mini-language used to define images pixel
by pixel.

> There was the introduction of the policy of colour sometimes being a
> recorded property rather than having just the original monochrome
> recording policy.

There isn't any such policy. There is a variation selector to suggest
that the rendering engine show certain characters in "emoji style"
instead of "text style," and there are characters with colors in their
names, but there is no policy that specific colors are "recorded" as
part of the encoding. YELLOW HEART could conformantly appear in any
color.

> There has been the change of encoding policy that facilitated the
> introduction of the Indian Rupee character into Unicode and ISO/IEC
> 10646 far more quickly than had been thought possible, so that the
> encoding was ready for use when needed.

That's not a change to what types of things get encoded. It's a
procedural change, one which I would agree has been applied with
increasing creativity.

> There has been the recent encoding policy change regarding encoding of
> pure electronic use items taking place without (extensive prior use
> using a Private Use Area encoding), such as the encoding of the
> UNICORN FACE.

This is probably your best analogy. People like Asmus have addressed it,
saying it's not reasonable to expect users to adopt PUA solutions and
wait for them to catch on.

> There is the recent change to the deprecation status of most of the
> tag characters and the acceptance of the base character followed by
> tag characters technique so as to allow the specifying of a larger
> collection of particular flags.

There must have been a great wailing and gnashing of teeth over that
decision. So many statements were made over the years about the basic
evilness of tag characters.

But the concept of representing flags was already agreed upon as a
"compatibility" measure, and the Regional Indicator Symbols solution was
a compromise that allowed expansion beyond the 10 flags that Japanese
telcos chose to include. RIS were an architectural decision. The tag
solution (to be fully outlined in a future PRI) was another
architectural decision. Neither (I believe) is analogous to a scope
decision to start encoding different types of non-character things as if
they were characters, and as I have said before, assigning a glyph to a
thing that isn't a character doesn't make it one.

--
Doug Ewell | http://ewellic.org | Thornton, CO 🇺🇸