Re: Arrow dingbats

Michel Suignard (editor of ISO/IEC 10646) responded to these questions,
but let me augment his response with some more detailed history here.
(Pardon the length of the reply, but these things tend never to be as
simple as people assume and hope they are.)

On 5/28/2015 2:08 PM, Chris wrote:
>
> So it sounds like 27a1 came first. Then 2b05 etc was added to complete
> the set with 27a1, except that it didn’t complete the set because
> nobody aligned the glyphs. Then they added U+2B95 in a 2nd attempt to
> complete the set? (Why not just fix the old arrow?)

O.k. That is *roughly* correct, but only very roughly.

U+27A1 BLACK RIGHTWARDS ARROW

That *did* come first. It has a Unicode Age=V1_1, dating back to 1993 in
the standard.
(Actually, its Unicode history goes back even further, but 1993 is
enough for this
discussion.)

U+27A1 was part of the set of dingbats encoded for compatibility with
the ITC Zapf Dingbats series 100, which saw widespread early commercial
implementation
on PostScript printers and was widely used as a font encoding back in
the 80's
and early 90's.

An important thing to note about the Zapf Dingbat arrows (go look at the
Unicode code chart for the 27XX block) is that almost all of those arrows
are exclusively right-facing:

http://www.unicode.org/charts/PDF/U2700.pdf

It was assumed at the time that in actual implementations that used these
arrows in documents, they would be used by PostScript drivers that had
arbitrary scale and rotate functions that would allow, among other things,
the rotation of an arrow to display in any orientation. The Unicode
*character*
encoding of these was, rather, intended as a code point compatibility
mapping that would enable Unicode mapping of documents that had used
font encoded Zapf dingbats simply as symbolic "blorts" in text.

This compatibility issue explains why, back in 1993, the whole set of
Dingbat
arrows was not elaborated into character-encoded rotational sets
of symbols (i.e. rightwards, leftwards, upwards, downwards, ...)

U+2B05 LEFTWARDS BLACK ARROW

That one (and the near-complete rotational set of similar black arrows
at U+2B05..U+2B0D) have a Unicode Age=V4_0 (2003). Andrew West
was correct in identifying the source of these. They were brought to
SC2/WG2 and proposed for encoding by the DPRK, back in 2001, for
compatibility with a North Korean standard. See page 5 of the pdf in:

http://www.unicode.org/L2/L2001/01349-N2374-DPRK-AddSymbols.pdf

That is the proximate source of these "black arrows" in the Unicode Standard
(along with the white versions at U+2B00..U+2B04). The glyphs that were
used for these arrows in Unicode 4.0 are also derived from that source.
However, the fact that WG2 N2374 (i.e., the DPRK) did not ask for also
encoding a separate "RIGHTWARDS BLACK ARROW" indicates that they
considered the existing U+27A1 BLACK RIGHTWARDS ARROW to
suffice for mapping to their standard.

The fact that "nobody aligned the glyphs" in 2003, when these were published
was partly because: a) the glyphs were inherited from the proposal document
and then ISO ballot documents, and nobody commented on or required them
to be changed in ballot comments, and b) nobody much cared, because these
were compatibility additions for a DPRK standard, and weren't mapped to
any commercial sets at the time, anyway.

The glyphs for U+2B05..U+2B0D remained unchanged in the standard from
Unicode 4.0 through Unicode 6.3. (Again, because nobody had any strong
reason to do otherwise.) And that explains why, as implementations of
the Unicode 4.0 (and later) repertoire came to be more widely supported
in fonts, the glyphs for U+2B05 tended to have a relatively narrow arrow
shaft that matched the Unicode charts. The unification of the rotational
set U+2B05..U+2B0D with the existing ITC Zap Dingbat U+27A1 was
*implicit* in the encoding, but was not explicitly called out by anything
other than a note in the names list for the 2BXX block that pointed to
the 27XX block for "Other white and black arrows to complete this set".
In practice, most people just put glyphs in fonts that matched the code
charts.

U+2B95 RIGHTWARDS BLACK ARROW

This one has a Unicode Age=V7_0 (2014). It was added as a result of a
complete re-rationalization of all of the arrow symbols in the standard,
required, as Michel Suignard noted, to deal with the addition of
compatibility
characters to cover the multitude of arrow symbols in the Wingding sets.

If you want to see the explicit rationale and the point at which this
happened,
see page 21 in the pdf of:

http://www.unicode.org/L2/L2012/12130-n4239.pdf

That was the disposition of comments for PDAM 1.2 to ISO/IEC 10646
3rd edition. And the relevant note from the editor is:

"To complete the set of BLACK ARROW in 2B05..2B0D a new character
is added:
2B95 RIGHTWARDS BLACK ARROW
(The character 27A1 BLACK RIGHTWARDS ARROW in the dingbat block
is not an appropriate match for the other 9 characters)."

This happened in the context of mapping against multiple Wingding arrow
shapes, which were at the time being added to the standard in explicit
rotational sets. Doing this consistently required a rationalization of the
shapes and aspects of the white and black arrows in the 2BXX block.
And the explicit changes that ended up in the Unicode code charts can
be traced back to the following repertoire chart:

http://www.unicode.org/L2/L2012/12128-n4244.pdf

See pages 36 and 49 of the pdf.

Page 49, in particular, shows explicitly what Michel pointed out: the
addition
of the new character 2B95 was deliberately aligned with the glyph changes
for 2B05, etc.

So now finally, to your question: "Why not fix the old arrow?"

Well, Michel explained that in WG2 N4239. If you are going to map
an entire set to Wingdings (as opposed to a then decade-old proposal
document from the DPRK) it makes sense to use appropriate glyphs
for that, in the context of all the other additions. But it is *not*
appropriate to retroactively pick out the old ITC Zapf Dingbats series
100 glyph (from amongst a set of others with very explicit shapes)
and change *that* glyph just to make the rotational set complete.
Hence the addition of U+2B95 as the best solution for Unicode 7.0.

>
> Except that nobody seems to have U+2B95 aligned either.

It takes a while for font implementations to catch up with the
standard. The glyphs for U+2B05..U+2B0D have been in fonts
for some time now, and the multitude of arrow additions for
Unicode 7.0 are relatively new and not yet fully supported in
many fonts. *When* a font adjusts for the addition of the new
sets of arrows, however, it *should* take into account the explicit
glyph updates for U+2B00..U+2B0D, which were clearly intentional,
as part of all this work on the arrows to cover Wingdings.

> On unicode-table.com <http://unicode-table.com> it looks totally
> different,

You cannot depend on unicode-table.com for definitive information
about glyphs. That site is not coordinated with or sanctioned by
the Unicode Consortium. If you want definitive information about
encoding and current representative glyphs for each character, please
go instead to:

http://www.unicode.org/charts/

> and Mac doesn’t even have it.

Implementations may well lag in addition of new sets of symbols
from Unicode 7.0.

> Is there any hope this will actually fix it?

Yes.

> Has the unicode consortium made it clear to one and all that U+2B95 is
> supposed to align?

Yes. (See above.)

--Ken

>
>
>
Received on Thu May 28 2015 - 22:15:36 CDT