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

[David Starner]

I would say that a system would conform with Unicode in having yellow heart
red (in a non-monochrome font) as well as if it made it a cross. Either way
it's violating character identity. I'd say that being monochromatic is now
like being monospaced; it's suboptimal for a Unicode implementation, but
hardly something Unicode can condemn as nonconformant.

On 4:25pm, Sat, May 30, 2015 Doug Ewell <doug at ewellic.org> wrote:

> 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 ����
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20150531/22e7002b/attachment.html>