Status

Problems with parsing the MIME structure and displaying messages. When this problem happens, it's often useful to attach a copy of the mail message generating the problem. If you have Communicator 4.x, you can select the message and save it as an .eml file (just save with the .eml extension). A few examples: 1. The contents of a message do not display properly. Certain items do not show up.

The X-Face header has been used by a minority of Internet users for some years
to pass a well compressed 48x48 bitmap of their face (or some other picture). It
can be argued that the usage remains in the minority because few standard email
packages actually support the header - Zmail was the last one I remember. It
would be nice to see support for the header in Mozilla. I'd suggest:
* displaying X-Face faces when looking at mail messages
* allowing addition of an X-Face header to outgoing messages
* UI to allow the header to be created in the first place
I've started work on coding the first of these.

Any reason this never went anywhere? The code for turning the string into
a bitmap is easily available (support for this was just added to Xnews), I'd
have thought the biggest problem was simply a layout question of where
to put the picture.

The main problem when I looked seriously at this was displaying a dynamically
generated bitmap. All the UI stuff assumed that an image would be a gif or jpeg
in a file somewhere, not a ready decompressed bitmap sitting in memory. I
started looking at writing PBM support for the image library, but didn't get to
completion. The idea was to add a box to the header with an image as a
generated data: url containing the PBM data.
I know there's a new image library now, and much has probably changed
internally, so a simpler design might be feasible now.

PBM? Well, I hope you can take another whack at it, I think it'd be quite
popular, when it was added to Xnews there was a whole slew of people
that immediately picked it up. And then posting test articles to the wrong
group :-(

No, I wasn't thinking that X-Face images were related to PBM format. The problem
at the time I first filed the bug was that the mozilla user interface components
could only display images referrenced by URLs, which meant the data had to be in
a format understood by libimg. At the time that was GIF, JPEG and PNG (I think),
all of which are compressed. I didn't like the idea of decompressing the X-Face
image into a bitmap, then recompressing it again to create some bits that libimg
could decompress again. Hence the thought of adding PBM support. At that point I
got as far as finding the header and displaying an image in the email message
display window, but the image was a reference to a static GIF file in the chrome.
Much has changed since then; there's a new image library and I've noticed that
it now has support for PPM (raw P6 format only), ICO, BMP and Icon files, all of
which appear to be uncompressed. I might well be able to get something working
with the PPM support unless any of the other formats would be more suitable.
Basic approach I'm intending to use is to decompress the X-Face header into a
bitmap, encode as PPM, base 64 encode that and then use it in a data: URL string
generated into the email message header using a suitable user interface
component. Any comments, anyone?

I don't know of any plans to work on this any time soon, so futuring.
(the current bug owner can re-target if I'm wrong.)
to clarify, there is no X-Face2. That was me thinking out loud. X-Face is
limited to 48x48 black/white PPM. but we could use data urls to send images of
other sizes, color depths and encodings (gif, png, etc)
note, while mozilla doesn't currently handle X-Face headers, it is possible to
send them.
in your prefs.js, add:
user_pref("mail.compose.other.header","X-Face");
then, in the compose window, when sending, you use the addressee picker
(To,Cc,Bcc) and choose "X-Face" and then paste in your X-Face text.
on sending, it will become:
X-Face: Z'Xu,,4$}c;RcA%m-fmI<\mt}_t4No^r...
I've updated http://www.mozilla.org/mailnews/arch/hiddenprefs.html to cover this
pref. (it will take a few minutes before my change shows up.)

> X-Face support will happen. I've been talking to sfraser about it.
I did talk to sfraser about it, and he did send me some sample code, but other
things have come up.
there is code already checked into mozilla that X-Face can piggy back on to.
see setFromBuddyIcon() in msgHdrViewOverlay.js

Just a comment on the musings on X-Face2 -- I suppose you could say that picons
are the functional equivalent of X-Face2 as they were created to provide more
features than the basic X-Face. They are sort of in between embedding general
data URLs within mail/news messages (as was discussed) and embedding the data
itself within mail/news messages (as is done with the traditional X-Face).
Instead they rely on a global database of icons that can be freely cached. The
positives and negatives of this approach should be pretty obvious -- a much
smaller virus threat for MS-Windows users, better color management/consistency
for people with 8-bit color, etc. (for the positive); and something of a tie to
one central location for updates, potential differences between different cached
copies around the world, etc. (for the negative).
More information can be found on the PIcons FAQ at:
http://www.cs.indiana.edu/picons/ftp/faq.html
More information on both X-Faces and PIcons can be found at:
http://www.cs.indiana.edu/ftp/faces/

Might as well add that Gnus supports X-Face. Additionally, the above references
to X-Face2 may have been referring to the "Face header" (also supported by
Gnus). See http://quimby.gnus.org/circus/face/

I just noticed that Bug 60881 already covers PIcons, and has had a patch
available since Mozilla 0.6 or thereabouts. It's still not in the main build,
though. As has already been observed, PIcons are functionally equivalent to
X-Face2 and the proposed patch to handle PIcons may be adaptable to handle
X-Faces as well.

XEmacs supports X-Face. Outlook Execrable supports X-Face (though that's not
exactly an endorcement of the feature!)
Bug 61520 will handle:
* allowing addition of an X-Face header to outgoing messages; adding dependency.
Any layout issues have been resolved: do what's done by (and reuse) the new
buddy icon display code that fixes Bug 168236. But do it in an established,
open protocol way.

So we're apparently already supporting non-standard AIM "buddy" images in
messages and the address book? It seems crazy that we're doing this and not
handling X-Faces, PIcons (Bug 60881), and perhaps even the Mail.app images that
Simon observed, too; they could all share the same basic display code and screen
real estate. The biggest part will be figuring out the hierarchy -- i.e. do AIM
buddies override Mail.app buddies and do X-Faces override domain PIcons, etc.

The order is unlikely to be important - (I imagine few faces will be not the
same and on more than one system. My take: since X-Face headers are in the
email itself, they should take priority over 'net-based icons - because only
they're local, and becasue if they're there, surely it's because that's what the
sender wants displayed. Second should be NIM/AIM icons which are local.)
Remember, Mozilla parent is Netscape, whose parent is AOL. So, it's not
surprising that AIM buddy support came first. Besides, I'd guess there's more
penetration of AIM buddy icon usage.

Here is a quick and dirty program that converts an x-face header into a
displayable data: url. It uses the libcompface library (part of the faces
package) which appears to be licensed under the GNU GPL.

Though PBM is discussed above, my test program generates an XBM image, mainly
because it is already supported by mozilla, and it is extremely easy to compose
one on the fly.
By encoding it as a data: url, we can leverage mozilla's existing ability to
display such an image with a bare minimum of code changes. The next step would
appear to be cleaning up the convertor and exposing it through XPCOM.

Is there already a feature request about the Face: header?
Newest Gnusae support it, it's a small PNG (< 800 Bytes or so), which may
include color etc.
Would be cool if Mozilla were among the first MUAs/NUAs to support it.
http://quimby.gnus.org/circus/face/

> The next step would appear to be cleaning up the convertor and exposing it
> through XPCOM.
Unfortunately not. You mention that your converter includes GPL'd code. Such
code cannot be checked into the Mozilla codebase (code has to be MPL/GPL/LGPL
tri-license).

I emailed James Ashton (the original author of the compface package) in March
this year about the license, and he replied:
"I'm happy for the code to be used in mozilla. Let me know if you need
anything more from me than just this email to confirm a change to the GPL
licence for the code.
On the technical side, please be aware that there's potential for a buffer
overrun. It's necessary to check the length of the input data before
passing it to the compface input routines as they're currently written."
I just haven't had time to integrate the code into the source tree yet.

Hrrm; I now see what you mean about PBM support - bug 197530 removed support for
PPM files from the tree completely.
It might be premature optimization, but converting the binary image data into
text for another part of the code to parse seems a bit clumsy to me. Anyone know
whether any of the other supported image decoders has a simple binary format, or
is XBM the best remaining option?

It's worth noting that the compface libraries output format is already a
text-based format, and the conversion from that format (ikon?) to xbm is almost
trivial. You would just be moving the text to binary conversion up one layer.
I don't think you'd get much increased efficiency converting from text to binary
in the x-face specific code; in fact it would probably less efficient than the
already-tuned libimg2 code.
Also remeber we are dealing with 48x48 1 bit images here, so optimizing for
speed or footprint is ridiculous. Optimizing away complexity should be the
goal. An xbm data: url is simple solution that makes uses the existing
facilities as much as possible.

Bug 61520 has been fixed, so at least we can now add X-Face, Face, X-Face2,
PIcons Mail.app (and Habeas,etc.) headers to outgoing email.
helpwanted? Someone needs to take all the existing pieces and skillfully put
'em together.
Mark Wilkinson: Seems like you need to email James Ashton to get it released
specifically under MPL/GPL/LGPL tri-license.

The full text of the reply (with my request included) was:
<quote>
At 10:10 PM 17/03/2003 +0000, you wrote:
>When I find some time I'm hoping to add support for the X-Face header to
>mozilla's mail reader (see
><http://bugzilla.mozilla.org/show_bug.cgi?id=20417>). Initially this
>will just be displaying X-Face images when you look at a mail message. I
>was wondering if you'd have any objection to me using the compface
>source code as a basis - it's not immediately obvious that the mozilla
>source licenses don't conflict with the licence that you used when you
>released compface. I suspect that mozilla.org would need the code
>licensed under the MPL/GPL/LGPL triple license that they're working
>towards (see <http://www.mozilla.org/MPL/license-policy.html>).
I'm happy for the code to be used in mozilla. Let me know if you need
anything more from me than just this email to confirm a change to the GPL
licence for the code.
On the technical side, please be aware that there's potential for a buffer
overrun. It's necessary to check the length of the input data before
passing it to the compface input routines as they're currently written.
</quote>
I took that as meaning the triple license was Ok, but his specific mention of
the GPL could lead to a different interpretation.

This patch adds x-face display support to mozilla. The x-face is only
displayed if the message has an x-face header (obviously) and if a buddy icon
can't be found for the sender.
This patch relies on the above compface patch. The compface source files must
also be copied into the mozilla tree at mozilla/mailnews/mime/src.

Is it written in stone that the proposed X-Face / X-Image support will only
allow embedded pictures? Would it be possible to use an external URL in the
X-Face header?
What will the resolution be? Can we not make a pref to allow a MAX SIZE (and
Moz would resize the pic to fit)
(Im more fond of a color picture - See Example:
http://www.drosoph.com/Mozilla-xface1.jpg -- I used the Buddy Icon ability to
create the mockup)

I would think that the proposed X-Face support is written in stone as the X-Face format is pretty
well established and settled, and it should probably not be used for arbitrary URIs.
That being said, there are other standards out there that do handle more complex formats.
Mozilla already supports AIM "Buddy Icons" and Bug 60881 is for adding support of PIcons, so
that's two more ways Mozilla will be able to tag e-mails / news messages with graphics. Actually,
if the proprietary AIM Buddy Icons are already supported, I think that the proprietary .Mac icons
that Simon mentioned should be supported, too (along with any other proprietary form that comes
along with a large enough user base -- why not have Mozilla look as good as it can?) but that the
non-proprietary types like X-Face and PIcons should always perhaps be treated as a little more
important...

If this bug goes beyond the scope of X-Face and is a tracking bug for Any/All
embedded image types for mailnews then I understand that Bug 202670 is a
duplicate otherwise it should not be ,marked as a dupe as it refers to the
X-Image-URL header and not the X-Face header that is mentioned in this bug ...
Are we making this bug generalized and encompassing all picture format embeddeed
headers (X-Face, X-Face2, Face, PIcon, X-Image-URL, etc) ???

I've ported the C uncompface algorithm to javascript, which should hopefully
make it easier to package this up as an extension. The attached HTML page
provides a simple interface to test it out.
(This addresses the original 48x48 1-bit X-face bitmaps only)
As always, feedback/reviews/comments appreciated!

Any chance of getting X-Face support in Mozilla 1.7?
I've been using X-Faces for several years with the
Sylpheed-Claws email client (Linux and FreeBSD) as
well as the WebMail/2 client (IBM OS/2) which
both support x-faces rather well.
Thank you.

Here is my second attempt at a javascript x-face implementation.
Unfortunately, it is very, very slow. Javascript is horrible at the kind of
fiddly math x-faces uses, and I've optimized it as much as I can (js wizards:
any suggestions?). It still takes several *seconds* to decode a face on a
reasonable modern box. The delay is very noticable and worse yet, on some
occasions tbird/mozilla unhelpfully offers to stop the script because it
figures it got into an infinite loop.
I'll resume work on a C++ version.

Is it technical or licensing issues that have slowed this bug down? If it's the
latter, perhaps the work done so far in this bug could be put toward an XPI
extension with uncompface's license. AFAIK, users are allowed to install
GPL-only extensions, aren't they?
BTW, FWIW, I used a modified version of the test page in attachment 148224[details] to
test the javascript uncompface in attachment 148701[details]. It took about 1.4 seconds
to decode the largest face I gave it, which isn't great, but isn't as bad as
described in comment 48. I tested on my 667MHz P3 with faces from
http://www.xs4all.nl/~ace/X-Faces/ and made an effort to pick ones with the
longest strings.

JFTR:
The current Mnenhy v0.7 (http://mnenhy.mozdev.org) now displays X-Faces (as part
of its Custom Headers module).
Many thanks to Andrew Taylor, without whose spadework this wouldn't have been
possible!

I've created a patched version of MessageFaces
(http://tecwizards.de/mozilla/messagefaces/) with support for x-faces.
MessageFaces is an extension for Thunderbird that provides support for faces
(see comment 25). The next official release of MessageFaces will likely include
x-faces support.
As with mnenhy, the performance seems acceptable.
An .xpi for the patched version of MessageFaces is here: http://www.phyre.ca/xface/

Fine, to see that there was some progress over the *years*.
I try to figure out now how to include my picture in mails with Mozilla Mail. A UI function like adding custom headers would be nice. All the hints I found don't work in the first place. When I try to use the suggested solution to add another header, I cannot insert multiple lines there. If I try to add linebreaks into the X-Face code the mailer is sending this verbatim (with \n or \r\n included), when I insert the base64 code without linebreaks it is sending it without linebreaks, the result is the same everytime, the picture is not displayed with mnenhy.
What I figured now is that linebreaks are not needed, the line is wrapped automatically *iff* there are whitespaces where a linebreak was.
"prefs.js" looks like this then:
user_pref("mail.identity.id1.header.X-Face", "X-Face: ,&'['.3ah~iAt$2Q/`9cGMjo)~WURde1b+0[8@bJ)[UnH0g\\W~,o8rv[?-s8bw?s\"5MUH|C ~I,mWr\\[u\"LTbx2.\"FUIrs{pW>n!vYNtJ4P)X/x7q];%pF.dx?^YeY^)7$n_+$&0#y`qpi;F~&au:V lf^9Aop!O0VJH9c^#ifI>k'J)aZ7AX+\\wtW-?Y;2l&32d,=G:w%Xs(CeLIMP&Em'Rpc8Y3+JCIOnhP O.^@rtn!ey4N2a_pdEh@\\Xvs?;|}a;i+`1Gm&");
user_pref("mail.identity.id1.headers", "X-Face");
Note that the X-Face code cannot begin ':' this will be truncated. And '\' and '"' needs to be quoted to '\\' and '\"'. Face headers are similar, since they are base64 no quoting is needed, however, mnenhy doesn't support Face: header yet...
What bugs me now is that mnenhy displays X-Face but not Face headers. Display both or provide an option to display Face instead of X-Face would be nice ;)
So intergration of the TB extension into mnenhy should be the way to go.
Why is it so hard to add such a minor feature (like custom headers or X-Face: / Face: support) to Mozilla Mail? There is several years of discussion and finally we got some extensions which displays the Face: or X-Face: pictures, fine, but how to insert my own picture without doing hours of websearch and testing?
Will it ever be finished (add custom headers from the UI or at least X-Face: / Face: support)? When?
Regards,
Gerrit

Sorry to put additional spam but to answer the previous comment: as far as I understand this bug is not about providing an UI to set an X-Face. With Mozilla/SeaMonkey one could use the "about:config" interface to set properties so no manual escaping of " and \ characters would be needed. IIRC there's an extension which brings this interface in Tbird, too. Mnenhy doesn't include support for the 'Face' header as one could read its author's arguments:
http://bugzilla.mozdev.org/show_bug.cgi?id=10245#c1

Comment on attachment 130138[details][diff][review]
adds x-face display to mozilla v3
now that I know there's a thunderbird extension out there that does this, I'd rather see us go the extension route. Maybe folks can talk the extension author into putting it up on addons.mozilla.org for all of us to get!

For those who are still interested, I've cleaned MessageFaces up for use with modern versions of SeaMonkey and Thunderbird. I've done extensive testing on SM 2.39, but it should work just as well on the newest thunderbird. I have also added picon search support. I am currently working on a local search for picon database lookups on the filesystem. This extension now supports: Face, X-Face, Gravatar, Local images, x-image-url, x-face-url, face-url, and picon lookups for all message headers. Everything other than the Face header is optional to display and can be set in the add-on preferences (by default, only the Face header is enabled for security reasons). The program can now also display multiple different types of headers in one message, gmane-style. So, if the user has a message with a Face, Gravatar, and a valid picon, then the add-on will display all three side-by-side. I have also cleaned up the display of Gravatars, so it only shows Gravatars that are non-default (i.e., actually exist for that user). The reason I have updated MessageFaces specifically is because mnenhy only supports X-Face, while Display Contact Photo only supports Face headers (and has a bunch of features I view to be superfluous). Would love to post to AMO if I could get the original creators blessing..
https://github.com/JohnDDuncanIII/MessageFaces

You need to log in
before you can comment on or make changes to this bug.