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 <d...@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 🇺🇸 > > >