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

Thomas Muldowney temas at box5.net
Thu May 8 18:12:17 UTC 2003


Personally I'm at an impasse here.  I need more voices one way or the
other.  I'm not going to battle this for ages, and I'd happily say that
all data is either PNG or MNG.  That's what I wanted for JEP-0008, but
people wanted it other ways.  The specs for those formats are open and
available and plenty of decent libraries implement them.  About the
compression method too.  I just looked at what appears to be the recent
spec and it only mentions compression method 0, so I'm fine saying
that's the limitation.  Since, it's the only "official" method.  MNG
supoort could be flagged optional and it would be the client
responsiblity to say, "Hey, careful there, not everyone will see this." 
Where are the people that wanted other formats?

--temas


On Thu, 2003-05-08 at 11:55, Tijl Houtbeckers wrote:
> 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:
> 
> http://www.smartisans.com/burn_all_gifs.htm
> 
> 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.. 




More information about the Standards mailing list