WAP Pictogram Specification as Emoji Source
Marcel Schneider
charupdate at orange.fr
Sun Jan 8 09:38:33 CST 2017
On Sat, 7 Jan 2017 00:21:37 +0100, Christoph Päper wrote:
>
> I just discovered the WAP Pictogram specification (WAP-213-WAPInterPic),
> last published in April 2001 and updated in November 2001.
> […]
> […] it’s obvious that WAP pictograms have been unified with Japanese (i-mode) emojis
> upon their encoding in Unicode 6+. However, the mapping is not obvious in all cases
> and I think there are some pictograms that have been omitted / forgotten […]
On Sat, 7 Jan 2017 13:12:10 +0900, Martin J. Dürst replied:
>
> Isn't WAP overall pretty much defunct these days?
>
> (Well, many including me predicted as much pretty much when it first
> showed up.)
On Sat, 7 Jan 2017 12:43:03 +0100, Philippe Verdy replied:
>
> Technically it is is operational within operators. Old mobile phones still
> have an advantage that has completely been forgotten with smartphone, it is
> their very long battery lifetime, and there are still mobile phones sold
> today that are NOT smartphones, have NO Internet connectivity (only
> GSM/EDGE and SMS
and MMS and WAP – this seems to be what I have.
> ) and that will remain in charge for about 2 weeks, when my
> smartphone gets out of charge in less than 24 hours (or several times a day).
> So no complex layered networking protocol stacks, no advanced typography
> and a minimalist display. WAP is still supported on the EDGE/GPRS interface
> (used also with the Internet protocol under 2G networks which works almost
> everywhere when 3G/4G/5G signals cannot be received).
> However don't expect using this for feature rich interaction including for
> sending cute "WAP pictograms" that these devices will anyway not be able to
> decipher and render.
My terminal is able to display colorful pictograms, but I remember that some
time ago, the screens were mainly monochrome (and even smaller).
> I bet that WAP pictograms was an early specification
> for test that was in fact never needed, because the target audience goal
> was better achieved with Internet protocols and encoding standards, but
> also no one really wanted to administer a registry for the names (see the
> death of pict.com : no one paying for it, specification redundant with
> classic URIs on the web for referencing images), or standardizing the glyphs.
>
> The existing standard with normalized glyphs and semantics however exist,
> notably for traffic signs (on streets/roads, railways, rivers/canals,
> seas...), or in various industry standards (including for food, chemical
> products, or cleaning instructions for textiles, or additional glyphs for
> recycling, hazards or pollution).
There must be several standards in various domains.
> We are far from being complete in Unicode
> there, even if the supporting standards are effective, sometimes even
> mandatory, and very used. The problem for them is that these standards are
> not necessarily international, and incompatible with each other but still
> regulated and required and you cannot unify the glyphs specified by one of
> these standards with those from a competing standard (or with those glyphs
> already implemented in the UCS).
Yes. This has been discussed in 2003:
http://unicode.org/mail-arch/unicode-ml/y2003-m06/0274.html
and in 2015:
http://www.unicode.org/mail-arch/unicode-ml/y2015-m08/0004.html
http://www.unicode.org/mail-arch/unicode-ml/y2015-m08/0013.html
> And for now Unicode has resisted the idea
> of standardizing sets of symbols for specific standards, and notably if the
> glyphs are too strictly defined (not allowing variations/derivations
> without breaking the intended regulated semantics).
That is the point. Such constraints are opposed to the Unicode principles of
encoding symbols, Asmus Freytag explained in another context 12 days ago:
http://www.unicode.org/mail-arch/unicode-ml/y2016-m12/0115.html
Marcel
More information about the Unicode
mailing list