[JDEV] Buddy Icon (Avatar) Proposal
julian at jabber.org
Thu Aug 30 19:57:16 CDT 2001
Ok, talked with temas and a few others.
I like 48x48, and temas said it wouldn't be a big deal if it were that way.
We're removing the type attribute, and the new list of supported formats is
As for public XML storage, temas confirmed... there are still certain very
important servers which don't support public XML... these being the same
servers which don't support jabber:iq:browse. (Not that this annoys me or
anything ;) )
----- Original Message -----
From: "Jens Alfke" <jens at mac.com>
To: <jdev at jabber.org>
Sent: Thursday, 30 August, 2001 20:23
Subject: Re: [JDEV] Buddy Icon (Avatar) Proposal
> On Thursday, August 30, 2001, at 04:53 PM, Julian Missig wrote:
> > 50x50 is what AIM uses. The point of this was to easily support AIM's
> > Buddy
> > Icons as well.
> OK, that makes sense. I'll just squish 'em to 32x32 and thank the gods
> for bicubic scaling.
> > It didn't seem worth it to support JPEG. When images are that small,
> > most
> > people don't want them lossy to begin with.
> It makes a big difference in data size. In my tests, JPEG images of
> faces with "medium" compression were about 1/4 the size of their PNG24
> equivalents and visually indistinguishable. The GIFs were tiny but
> looked like shit due to the 8-bit color table. I don't have the test
> images handy anymore, but it's easy to verify. (I used PhotoShop to
> generate all the image files.)
> > This way icons can easily be changed when presence changes. I could very
> > easily have one icon for available, one for away, one for dnd, etc.
> You can still do that if it's stored on the server: just upload a new
> image right before sending the <presence> element. I don't see any
> drawback to this compared with having to send the image every time
> someone asks for it. As soon as more than one buddy requests the image
> you've saved on bandwidth.
> jdev mailing list
> jdev at jabber.org
More information about the JDev