WAP Pictogram Specification as Emoji Source

[Marcel Schneider]

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