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
