Re: Tags and future new technologies (from RE: Flag tags (was: Re: Unicode 6.2 to Support the Turkish Lira Sign))

From: Philippe Verdy <verdy_p_at_wanadoo.fr>
Date: Fri, 1 Jun 2012 19:27:23 +0200

2012/6/1 Doug Ewell <doug_at_ewellic.org>:
> Philippe Verdy <verdy underscore p at wanadoo dot fr> wrote:
>
>> Note that I absolutely do not advocate the reuse of language tags for
>> something else. They are deprecated and should remain deprecated. They
>> were not intended to be visible symbols.
>
> Just as a matter of terminology, the deprecated Plane 14 block is for
> "tags" and not just for "language tags." The idea for such a block did
> come from the proposal to support inline language tagging, and the only
> defined type of tag is U+E0001 LANGUAGE TAG, but other tags could have
> been introduced later for other purposes. By deprecating the entire
> block and not just U+E0001, UTC essentially deprecated the whole tag
> concept.

Fine. But the Plane 14 was not deprecated at the same time as a whole.

Anyway, given that I propose symbols, they are NOT tags. I haev no
opinion however about which plane should be used to allocated them.
The plane 14 is fine for me, like any other plane (except the BMP and
the SIP), even if they are not tags.

You seem to think that the whole plane is for tags. I don't think so.
Only the **existing** blocks assigned in Plane 14 are deprecated.

>> I much prefer a solution that generates **true** symbols that can be
>> combined, and **optionally** (but safely) rendered as ligatures (by
>> design of the encoding itself) to render the true flags instead of
>> showing their code in the list of glyphs (the default rendering in
>> absence of recongnized ligatures).
>
> I wish we would use some other term for these than "ligatures." They are
> definitely not ligatures in the sense that any typographer, sign
> painter, or reader would think of them. A picture of a French flag has
> no imaginable visual relationship to the letter F or the letter R.

You're right, in terms of typography. But all the technologies used
for producing the ligatures are perfectly usable here to give the
desired effect, with the same usage policies : they will remain
optional, even if they are desirable (and should be enabled by
default, just like the LAM-ALEF ligature in the Arabic script).

If you wanted to develop an OpenType font displying the actual flags
for some countries, you would map those using an OpenType feature that
is normally enabled by default.

Those users that won't have that font will still see the default
glyphs chosing the flag codes enclosed in a blank flag, using a basic
font that just contains simple character-to-glyph mappings (so they
will see something very similar to the representative glyphs, and it
will be fine).

If those users don't even have a font with these basic mappings, they
will just see square boxes, and it will be fine too: they know that
something is encoded there and that they need a supporting font. But
in such a case, renderers that lack a supporting font may use the NFKC
mappings to show the ASCII codes enclosed in punctuation marks like
square brackets, or they may synthetize the glyphs themselves, using a
Latin font and some additional drawings for the basic shape of a white
flag.
Received on Fri Jun 01 2012 - 12:29:33 CDT

This archive was generated by hypermail 2.2.0 : Fri Jun 01 2012 - 12:29:34 CDT