Adding RAINBOW FLAG to Unicode

Ken Whistler kenwhistler at
Fri Jul 3 13:23:42 CDT 2015

On 7/2/2015 5:56 PM, Peter Constable wrote:
> Erkki, in this case, I think Philippe is making valid points.
> -For the proposal to be workable requires some means of ensuring 
> stability of encoded representations. The way this would be done would 
> be for CLDR to provide data with all valid sequences --- effectively 
> becoming a registry.

I think that is wrong on a couple of grounds.

First, detailed stability of reference to actual defined geopolitical 
or particular detailed flag designs is
not *required* for proposal to represent *pictographs* of flags by some
sequence of Unicode characters to be "workable". Sure, more stability
of reference is desirable. But the current RIS pair mechanism for 
flag pictographs for countries is already "workable" -- it works and is 
widely deployed
and widely used -- without having guarantees that some particular 
country may
not decide tomorrow to change its official flag and hence result in some
particular pictographic display being obsolete in some sense, for example.

Second, the horse is already out of the barn regarding the particular
data that CLDR would be referring to. This works by reference to
the ISO 3166-2 scheme of subdivisions:

and *that* becomes the registry required for stability of representations,
plus whatever grandfathering stability-of-code mechanism BCP 47
adds on top of that. We don't require a further detailed level of
registration, I think, to make this workable. If the New Zealand
Hawke's Bay Regional Council (NZ-HKB) decided it needed a district
flag (or decided to change one it may already have), I'm not going to be
overly concerned about the details there. As long as
<base, tag-N, tag-Z, tag-H, tag-K, tag-B> has a stable definition as
a Unicode extended flag tag sequence, it is up to somebody else to
decide if they want to actually map a Hawke's Bay flag /pictograph /in a 
font to
that sequence -- or update the flag pictograph they may have been

Yeah, this could be a giant headache for any vendor that felt they
had to support *every possible* region/subdivision sequence
and keep the exact representations of flag pictographs stable. But
I predict this will very, very quickly result in people making a
"let's cover the 99% case" set of decisions, and then issues like
"Should we display a flag pictograph for the Hawke's Bay Regional
Council?" will be dealt with by the normal methods of triage for
feature requests.

> -The concepts being denoted are inherently political, often unstable, 
> and sometimes highly sensitive.

> Sensitive issues aside, a better approach would be to have a URN 
> tagging scheme --- which IMO begs the question why this is a Unicode 
> topic as it clearly crosses outside the limits of plain text.

A URN tagging scheme might make sense if what we were trying to
do was delegating all identity concerns to external authority,
and if we didn't care about efficiency of representation, either.

I don't think that is what this is about, as I tried to make clear 
I don't think we are encoding *flags* -- we are creating a mechanism
for the reliable representation of a set of *pictographs (emoji) for flags*.
And those pictographs for flags need an efficient representation that
can coexist comfortably with the rest of plain text -- the way the RIS
pairs already do.

> Sensitive issues considered, though, it begs the question as to 
> whether Unicode should be considering any of this at all, no matter 
> what the scheme for encoded representation may be. Someone helpfully 
> reminded us of this:
> >> [...] the UTC does not wish to entertain further proposals for
> >> encoding of symbol characters for flags, whether national, state,
> >> regional, international, or otherwise. References to UTC Minutes:
> >> [134-C2], January 28, 2013.

I believe that that statement (and the referenced decision) refer
specifically to the unwillingness of the UTC to entertain proposals
for encoding an indefinite number of pictographs for flags (of
whatever variety) *as symbol characters* -- that is,
one-by-one encodings as a single, gc=So code point in the standard.
Heading that direction is clearly not an efficient way to deal with
the concern, and would waste everybody's time in one-by-one
proposals and ad hoc decisions for each individual flag pictograph
to be added.

The UTC has a long history of putting a stake in the ground when it
encounters a character encoding problem which requires a *general*
solution, rather than a dribbling in of one-off decisions an item
at a time. And I think the tag proposal for dealing with
the representation of flag pictographs for regional subdivisions
shows precisely the kind of generality that we are looking for --
dealing with hundreds of potentially representable entities
with a general mechanism, rather than trying to encode them
all one-by-one.

Incidentally, back to the ostensible topic of this thread -- I don't
think the extended flag tag proposal currently addresses the
issue of how to represent a pictograph for a rainbow flag.
In that case I think a new registry mechanism might in fact make
sense -- and I have spelled out details of how one could reasonably
work in conjunction with the extended flag tag proposal in
feedback submitted on PRI #299.


> Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Unicode mailing list