Hey Casays, thank you for this. Very interesting. Pretty much as everything you write. Would it make sense to have some of this supported in WURFL in yourMessage 1 of 4 , Nov 18, 2012View SourceHey Casays, thank you for this. Very interesting. Pretty much as everything you write.Would it make sense to have some of this supported in WURFL in your opinion?Luca
On Sat, Nov 17, 2012 at 3:07 PM, casays <casays@...> wrote:
I wrote an overview on pictograms in mobile browsers.
If you are wondering whether or how to use this feature, you can read about it at mobiForge:
You can also find the article in the following site, together with a PDF version formatted for A4 print-outs:
A shameless plug, certainly, but it concerns a terminal capability that is not often considered by mobile developers.
... It really depends on the demand for such information, and the effort to enhance the current database with the required attributes. In essence, I see theMessage 1 of 4 , Nov 18, 2012View Source--- In firstname.lastname@example.org, Luca Passani <luca.passani@...> wrote:
>It really depends on the demand for such information, and the effort to enhance the current database with the required attributes.
> Would it make sense to have some of this supported in WURFL in your opinion?
In essence, I see the following points:
1) OpenWave and WAP
Support for pictograms can be a derived attribute.
If the following information is known:
a) browser name;
b) browser version;
then one can easily determine whether the browser supports pictograms, and, implicitly, which classes of pictograms. It is really a matter of checking the mobile_browser against a list of browser names, and the mobile_browser_version against a range of versions.
Things get more laborious, but one can still handle support for ISO pictograms as a derived attribute.
If the following information is known:
a) OS name;
b) OS version;
c) browser name;
d) browser version;
then one can determine whether pictograms are supported, and, implicitly, which classes of pictograms. Data about the OS is required because ISO pictograms are associated to system fonts, and data about the browser is required because some browsers may or may not handle all pictograms in the UNICODE space properly. Once again, it is a matter of checking device_os and device_os_version in addition to the mobile_browser and mobile_browser_version.
3) WAP, Openwave, ISO details
For these three standards, there are two ways to handle the matter:
a) Just provide the basic attributes about OS and browser through the database/API, and let the server application developer code the logic to derive from it which pictograms are supported (based on my article and referred standard documents).
b) Enhance the default descriptors associated with the browser or the OS with an additional attribute giving the type of pictograms supported (WAP, ISO, Openwave) and another one listing the classes of pictograms supported (i.e. Openwave icon ranges, WAP dictionaries, ISO UNICODE blocks).
Regarding ISO in the latter case: one would have to investigate for relevant OS/browsers which UNICODE blocks are fully implemented (and that could therefore appear in the list), and leave unimplemented or partially implemented blocks aside (it is not terribly useful to know that some symbols are not implemented without knowing exactly which ones). This is a tedious job -- there are several UNICODE blocks coming into play, and hundreds upon hundreds of symbols to check (I quickly counted and there were over 1300). At some point, somebody will probably have to do this anyway as ISO pictograms are becoming relevant in the mobile web -- chiefly because of Apple.
Anyway, I do not think that it would be the role of WURFL to provide some sort of cross-translation facility between pictogram formats; this is something to be left to the application server.
There things are really complicated. We cannot rely upon browser or OS -- this information is frequently unknown, and even then, not really conclusive anyway.
Japanese operators classify devices in generations, which are associated with browser capabilities and emoji classes; if this information would be present, then one could derive from it the pictogram classes supported. This requires delving in the relevant documentation -- which is frequently only in Japanese (the documentation is usually well organized and Babelfish is your friend, but still).
In any case, one would have to associate the information (either device class or emoji type -- DoCoMo, Softbank, etc -- with emoji class) explicitly for each device model. Quite some work -- but it could be justified if you intend to push WURFL in Japan, where emojis are truly important.
Hope this helps.
The second part of my investigations regarding pictograms is on-line at http://areppim.com/b2evolution/usrblogs/technotes/?p=38 It comprises compatibilityMessage 1 of 4 , Feb 10View SourceThe second part of my investigations regarding pictograms is on-line at
It comprises compatibility tables for UNICODE pictographs in WP, iOS and Android, and caters for feature phones by establishing the correspondence with WAP and Openwave icons. There are some tips about detecting support for pictograms with WURFL.
I am now polishing a third and last part detailing how to implement custom pictograms on mobile phones.
I hope mobile Web developers will find this useful.