20417 - MailNews should support the X-Face header

Status: REOPENED

(MailNews Core :: MIME, enhancement, P3)

Description

[Mark Wilkinson]

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.

Comment 1

[Phil Peterson]

Reassign to mhw since he's working on it. Mark, assuming you're changing the
MIME code to support this, please get a code review from Rich Pizzarro
<[e-mail]> before checking it in.

Comment 2

[John Moreno]

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.

Comment 3

[Mark Wilkinson]

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.

Comment 4

[John Moreno]

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 :-(

Comment 5

[Adam D. Moss]

Hmm, yes, I think it'd be easier to add PBM and/or
dynamically-generated image support nowadays with
the new imglib.

Comment 6

[Alex Chaffee]

I'm pretty sure that PBM is not the same format as X-Face, although both are
simple bitmap formats. Or is that not what you meant?

Some X-Face web sites:
 http://www.dairiki.org/xface/
 http://www.xs4all.nl/~ace/X-Faces/

Comment 7

[Mark Wilkinson]

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?

Comment 8

[(not reading, please use [e-mail] instead)]

X-Face support will happen.  I've been talking to sfraser about it.

notes to self:

X-Face: Z'Xu,,4$}c;RcA%m-fmI<\mt}_t4No^r@41[r{zCA!v51e{iewL-W"CHNF?@"#6@]2vvy*~
 'Q2-.q^_1aWrt7#Z8S0#Q$ON#_-]&Oae5?>Rx|Kd6X7Yh_f7Iws=krR0!M?4`"=XK8F|=.Eb/x'CE|
 sIMT@]TvbY%di6D[q

limited to 48 x 48, black white, right?

http://www.dairiki.org/xface/xface.php

data urls, hmm, data urls, like:

data:image/jpeg;base64,/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAYEBAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwODxAPDgwTExQUExMcGxsbHCAgICAgICAgICD/2wBDAQcHBw0MDRgQEBgaFREVGiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICD/wAARCAAgAB8DAREAAhEBAxEB/8QAGQABAAMBAQAAAAAAAAAAAAAABgQFBwED/8QALBAAAQMCBQMCBgMAAAAAAAAAAQIDBAURAAYSEyEiMUEHFSMyUVJhgXHh8P/EABoBAAIDAQEAAAAAAAAAAAAAAAYHAwQFAQL/xAAoEQABAwIFBAEFAAAAAAAAAAABAAIDBBEFEiExQQYTIlFhI3HR4fD/2gAMAwEAAhEDEQA/AKmjbS6wxuoK2WiVrR92kXAPi2rBr1TWdilNjZ79Pys/A4A+oaLeISJ2TWqg+8UkJjlso1Dv1cduOn998KV0qZBk1tbRQoGXa/THG1NvfU6VXSp3yrSu5AV+POOOqQ77quzxKSQzVJMpG8+WmtvWHQR1DsNPgc98TUz+4deFqNczJtqg+Vajsz5rpSF/B0tg9rqV8x/QwR9V53yNcedvj4QZ09G1oIHrX++EqpFPnV5x1xolxpkIbdjNWC9CBfpHFzZd9J74GRFay3pJwwqDWoz1GrMakPlTr011lqKwhwKff3gSHmI6gDoBRZWpQ6uMXm0Ic3MqbsRsV4yHpbWqEvrMV91tKT4I4UP6xQb4uvyt2lmG/tEobi4rzhSb6xo/P+vhtY3hcUsBJ0ya/pKzDsTdHKLcravTDL6WGE5mYeOzUobbQpyeW0LbUdbiDfgrV3SexvhaTSeIA4RU5pzkplLplHdmM1aXEaXOho+BKWLuNi+qyT/OIO84Ny30XDCHG/KxDPdQjQq5NdSkIQ8tLobT09Sx1Hz3vzjzTxF51W6z6bbLkr0urDNNXJU4kS0vKSI6eq6ACdV8NHEK1s7DGL2PKV9GO3JnPCu8sUbMGVYk1qjzA7KakJQ/GfUTHJ3L6ijgjXHWlWpPNxgSfhgkBtoiA4nsTslkObnCs1hcKSiLAp+wlzbc3ESFLNrgJNytKT9O/GM6pwbLbyBBV2mxJu+U3CmQ8gZS9w98rqQ9JW3sMocFgUA/Nt82Pi+LcFK1oyx3PslQz1zpN9Av/9k=

X-Face2:  data:image/...? (only allow data:/image)

for a related bug, see bug 168236

Even if we fix 168236, I'd want to add X-Face support.

Comment 9

[(not reading, please use [e-mail] instead)]

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.)

Comment 10

[(not reading, please use [e-mail] instead)]

> 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

Comment 11

[Feneric]

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/

Comment 12

[Simon Fraser [no longer active]]

Mail.app on Mac OS X shows some kind of header images, and I'm trying to find
out how they do it (there don't seem to be any corresponding headers for picons,
or xface).

Comment 13

[Axel Belinfante]

Exmh (http://www.exmh.org/) also supports X-Face header lines.
In addition, it supports x-image-url header line.
See: http://www.beedub.com/exmh/guide.html#FACES 

Comment 14

[Simon Fraser [no longer active]]

It has been pointed out to me that Mail.app gets images for users with mac.com
email addresses, looking for
<http://homepage.mac.com/<USER>/.cv/thumbs/me.thumbnail>.

Comment 15

[Stanimir Stamenkov]

"40tude Dialog" <http://www.40tude.com/dialog> is another mail/news application
supporting the X-Face header <http://www.40tude.com/dialog/features.htm>:

http://www.40tude.com/dialog/screenshot2.htm

Comment 16

[Jason Dufair]

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/

Comment 17

[Feneric]

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.

Comment 18

[Matthew Elvey]

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.

Comment 19

[Feneric]

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.

Comment 20

[Matthew Elvey]

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.

Comment 21

[Yves Lambert]

what about bug 60881 ?

Comment 22

[Yves Lambert]

oops. Sorry for the spam. 

Comment 23

[Andrew Taylor]

Attachment: program to convert x-face to data: url

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.

Comment 24

[Andrew Taylor]

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.

Comment 25

[Jens Müller (:tessarakt)]

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/

Comment 26

[Alex Bishop]

> 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).

Comment 27

[Mark Wilkinson]

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.

Comment 28

[Mark Wilkinson]

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?

Comment 29

[Christian :Biesinger (don't email me, ping me on IRC)]

BMP has a not too difficult binary format; though I don't know how it compares
to PBM.

Comment 30

[Andrew Taylor]

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.

Comment 31

[Matthew Elvey]

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.

Comment 32

[Mark Wilkinson]

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.

Comment 33

[Adam D. Moss]

I interpret that to mean that he's only okayed it as GPL.  Afraid it's best to
verify (again!) that it's okay under Mozilla's triple-license.

Comment 34

[Andrew Taylor]

I sent him off an email last night specifically asking about the triple license.
 I refered him to the mozilla license policy:
http://www.mozilla.org/MPL/license-policy.html.

Comment 35

[Andrew Taylor]

Attachment: compface patch to compile in mozilla enviroment

This is a small patch to allow compface to compile within the mozilla
environment.

Comment 36

[Andrew Taylor]

Attachment: adds x-face display to mozilla

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.

Comment 37

[Andrew Taylor]

Attachment: adds x-face display to mozilla v2

This patch cleans up the conversion code a bit.

Comment 38

[Andrew Taylor]

Attachment: adds x-face display to mozilla v3

Updated my patch to be against the CVS head.  Also added x-face support to
thunderbird.

Feedback and/or code reviews would be appreciated!

Comment 39

[Scott MacGregor]

I thought dmose was working on this recently. Dan, didn't we end up deciding
that we wanted x-face as an extension and andother component X-image or
something as part of the default package?

Comment 40

[Andrew Perry]

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)

Comment 41

[Matthias Versen [:Matti]]

*** Bug 220670 has been marked as a duplicate of this bug. ***

Comment 42

[Feneric]

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...

Comment 43

[Andrew Perry]

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) ??? 

Comment 44

[Andrew Taylor]

Attachment: A Javascript Implementation of uncompface

Comment 45

[Andrew Taylor]

Attachment: A test page for the javascript uncompface

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!

Comment 46

[Adam D. Moss]

Hmm, that's a great idea!

Comment 47

[[e-mail]]

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.

Comment 48

[Andrew Taylor]

Attachment: Javascript uncompface v2

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.

Comment 49

[David Perry]

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.

Comment 50

[Karsten Düsterloh]

[e-mail] aber hob zu reden an und schrieb:
> perhaps the work done so far in this bug could be put toward an XPI
> extension with uncompface's license.

I have a quite smoothly working adaption of Andrew's JS script that will be part
of the next Mnenhy release that is scheduled for mid September.

> AFAIK, users are allowed to install GPL-only extensions, aren't they?

*Users* can do whatever they like. ;-)

> 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.

Andrew's implementation is very similar to uncompface, in some places far more
similar than actually needed. In Mnenhy, I tried to strip down the decoder as
much as possible:

http://www.mozdev.org/source/browse/mnenhy/src/bin/chrome/mnenhy/content/mnenhy/headers/mnenhy-headers-xface.js?rev=1.1&content-type=text/x-cvsweb-markup

> 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.

On my Athlon 500, I do not /notice/ any more delay by the X-Face decoding than
Mnenhy already does of its own.

Comment 51

[Karsten Düsterloh]

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!

Comment 52

[Andrew Taylor]

Attachment: Javascript uncompface v3

Here is the latest version of the javascript implementation, with improvements
from Karsten.

Comment 53

[Andrew Taylor]

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/

Comment 54

[Gerrit P. Haase]

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

Comment 55

[Stanimir Stamenkov]

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 56

[Scott MacGregor]

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!

Comment 57

[Andrew Taylor]

The thunderbird extension is called MessageFaces, and it uses the x-face decoder from this bug.  It's already up on addons:
https://addons.mozilla.org/extensions/moreinfo.php?application=thunderbird&numpg=10&id=393

I agree this belongs in an extension; maybe it's time to close this bug.

Comment 58

[Wayne Mery (:wsmwk)]

close?   ^^

Comment 59

[Bryan Clark (DevTools PM) [:clarkbw]]

ok, time to close this.  We should really make sure that extension works with the new thunderbird headers.

Comment 60

[John Duncan]

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

Comment 61

[chrizilla]

(In reply to Scott MacGregor from comment #56)

now that I know there's a thunderbird extension out there that does this, I'd rather see us go the extension route.

(In reply to Andrew Taylor from comment #57)

I agree this belongs in an extension; maybe it's time to close this bug.

The consensus was:
X-face is desired and blocks Outlook parity.
But this bug was closed because an extension was available.

Today, to my knowledge no X-face extension is available.
Therefore please decide what to do about this bug and it's expired brother bug #254964 (color X-face).