2012/6/1 Doug Ewell <[email protected]>: > 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.
