Flaw on Side View vs Front View Emoji Pairs?

From: Marcel Schneider <charupdate_at_orange.fr>
Date: Thu, 23 Mar 2017 01:20:14 +0100 (CET)

Here is an issue that admittedly is unsignificant
when compared to on-going world events, but I need
to work on some documents to be finished these days.

Some transport emoji pairs appear to have been encoded
at the same time (6.0), but have their glyphs swapped
in some current font(s).

These include:

U+1F68C BUS
U+1F68D ONCOMING BUS

U+1F692 FIRE ENGINE
U+1F6F1 ONCOMING FIRE ENGINE

U+1F693 POLICE CAR
U+1F694 ONCOMING POLICE CAR

U+1F695 TAXI
U+1F696 ONCOMING TAXI

U+1F697 AUTOMOBILE
U+1F698 ONCOMING AUTOMOBILE

While on cellphones, the first are side views
(source: iemoji.com), the
latter ones are conformant front views. By contrast,
web browsers on Windows use a font or fonts that show
the first in front view, while the others are missing.

I note that both are “fully conformant” to the
Standard, so far as the name is a mere identifier, not
a descriptor, and the glyphs in the charts have little
of a prescription. At least, whenever the name is
generic as of perspective, any designer of somewhat
related glyphs can claim conformance, and Unicode has
to endorse the resulting flaw.

I note, too, that “oncoming” is often misunderstood as
carrying a connotation of dynamics, whereas in reality,
many vehicles are more iconic in front view, while
others stand more out in side view.

Was it imaginable to be precise and call them simply:

U+1F68C BUS SIDE VIEW
U+1F68D BUS FRONT VIEW

U+1F692 FIRE ENGINE SIDE VIEW
U+1F6F1 FIRE ENGINE FRONT VIEW

U+1F693 POLICE CAR SIDE VIEW
U+1F694 POLICE CAR FRONT VIEW

U+1F695 TAXI SIDE VIEW
U+1F696 TAXI FRONT VIEW

U+1F697 AUTOMOBILE SIDE VIEW
U+1F698 AUTOMOBILE FRONT VIEW

Or did the first ones already exist in both views,
so that it was desirable to add one more character
for each one of them to make sure to get front views?
That would imply that fonts with the first in front view
don’t need to support the second characters, treated as
mere glyph variants. In any case we seem to have
some drawbacks to choose from data interchange flaws
and document rendering flaws.

Does the original proposer or anybody else have any
clues on how the set was intended, and how to fix
the discrepancy?

Regards,
Marcel
Received on Wed Mar 22 2017 - 19:20:44 CDT

This archive was generated by hypermail 2.2.0 : Wed Mar 22 2017 - 19:20:44 CDT