[standards-jig] NEW: User Avatars (JEP-0084)

Tijl Houtbeckers thoutbeckers at splendo.com
Thu May 8 16:55:00 UTC 2003

Thomas Muldowney <temas at box5.net> wrote on 8-5-2003 18:08:50:
>On Thu, 2003-05-08 at 01:49, Justin Karneges wrote:
>> I believe the C-library libmng is crossplatform (this is how Qt gets 
>> its MNG support, which works on win32/x11/mac/zaurus).  libmng 
>> should cover most C/C++ applications, but I'm not sure about other 
>> languages like Java ... 
>> On Wednesday 07 May 2003 06:46 pm, Tijl Houtbeckers wrote:
>> > - drop GIF (considering it has patent issues for opensource
>> > applications anyway)
>> I agree.  If adventurous clients wish to use GIF anyway (like I 
>> probably will do with Psi), they can bite the patent bullet and do a 
>> GIF->PNG/MNG conversion before publishing.  What do others think?
>Thinking that a client should convert the format is madness.

If the client wants me to be able to use PCX files as an avatar why 
shouldn't it be able to convert them? Maybe a jabber webservice 
component that can convert images would be cool too.. Just to be sure, 
I think everyone is talking about having a client convert the images 
*before* it published them. 

>The client
>should only allow usage of formats that are allowed within the spec.  
>As to why we wanted to include GIF, it's simple.  Compatability with 
>other systems, primarily AIM.  Plus, the patent issues are for 
>encoding of GIFs, not use.

Read an example of their delightfull licence practises here:


Basically this means: if someone on AIM uses a GIF that is made with an 
unlicenced gif generator you are not allowed to display it in your 
jabber client without paying 5k$ to Unisys first. 

>> > - restrict PNG's to compression method 0 (deflate)
>> > - restrict JPG to standard encoding (as opposed to progressive 
>> > encoding) 
>> I'm not sure if we should go there.  Clients should not be required 
>> to do image checking or reformatting (well, unless they wish to use 
>> an unsupported image format).
>Tijl, what are the downsides to allowing general PNG and JPG usage?  
>Funky display?  Why would we want to limit to those?  Especially the 
>PNG compression, this is a great method to fit in the 8k cap.

Method 0 is practically the only compression method used for PNGs, it's 
easy to support because it's based on normal "ZIP" compression. 
Ofcourse all filters should be supported. Decoding progressive encoded 
JPGs is a lot harder as normally encoded. So the reason is: any native 
support for these formats will support at least method 0 for PNG and 
normal encoding for JPG. (and often: not more then that). If 1 of those 
2 or both of them are not supported it's not that hard to write your 
own extenstions. Eg most J2ME devices support only PNG method 0 and 
nothing more, but there are lots of opensource/BSD-style pure Java JPEG 
decoders. However I don't know of one that supports progressive 
encoding, and I'm sure that would make the codesize bloat some more too.

>Tijl, I don't feel a special
>section is needed for animation.  The animated formats encode the only
>option I can think of, play once or loop forever.  What else would
>dictate a special section?

So what should clients do who do not want animation or do not support 
it? If you truly want as many clients as possible to be able to show an 
avatar ("crossplatform") you're gonna have to limit your options to 
less then "use any PNG/JPEG/MNG/GIF/Animated-GIF and it's ok". I'd 
choose to split it in two, one pubsub channel for a very basic PNG/JPG 
avatar, and one (or more) channel(s) for a more advanced avatar, for 
wich the more advanced clients who support it can Fneg or Disco the 
hell out of each other.. 

Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands

More information about the Standards mailing list