MailNews should support the X-Face header

RESOLVED WONTFIX

Status

P3
enhancement
RESOLVED WONTFIX
20 years ago
3 years ago

People

(Reporter: mhw, Assigned: ataylor)

Tracking

(Blocks: 1 bug)

Trunk
Future
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments, 4 obsolete attachments)

(Reporter)

Description

20 years ago
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.

Updated

20 years ago
Assignee: phil → mhw
Component: Front End → MIME

Comment 1

20 years ago
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
<rhp@netscape.com> before checking it in.
(Reporter)

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 2

18 years ago
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.
(Reporter)

Comment 3

18 years ago
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

18 years ago
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

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

Comment 6

18 years ago
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/

(Reporter)

Comment 7

18 years ago
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?
(Reporter)

Updated

17 years ago
Depends on: 117983
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.
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.)
Target Milestone: --- → Future
> 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

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
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>.
"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

16 years ago
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

16 years ago
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

16 years ago
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.
Depends on: 61520

Comment 19

16 years ago
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

16 years ago
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

16 years ago
what about bug 60881 ?

Comment 22

16 years ago
oops. Sorry for the spam. 
(Assignee)

Comment 23

16 years ago
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.
(Assignee)

Comment 24

16 years ago
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/

Comment 26

16 years ago
> 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).
(Reporter)

Comment 27

16 years ago
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.
(Reporter)

Comment 28

16 years ago
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?
BMP has a not too difficult binary format; though I don't know how it compares
to PBM.
(Assignee)

Comment 30

16 years ago
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

16 years ago
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.
(Reporter)

Comment 32

16 years ago
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

16 years ago
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.
(Assignee)

Comment 34

16 years ago
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.
(Assignee)

Comment 35

16 years ago
This is a small patch to allow compface to compile within the mozilla
environment.
(Assignee)

Comment 36

16 years ago
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.
(Assignee)

Comment 37

16 years ago
This patch cleans up the conversion code a bit.
(Assignee)

Updated

16 years ago
Attachment #130038 - Attachment is obsolete: true
(Assignee)

Updated

16 years ago
Attachment #130067 - Flags: review?(sspitzer)
(Assignee)

Comment 38

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

Feedback and/or code reviews would be appreciated!
Attachment #130067 - Attachment is obsolete: true
(Assignee)

Updated

16 years ago
Attachment #130138 - Flags: review?(scott)

Comment 39

16 years ago
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

16 years ago
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)

Updated

16 years ago
QA Contact: lchiang → nobody
*** Bug 220670 has been marked as a duplicate of this bug. ***

Comment 42

16 years ago
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

16 years ago
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) ??? 
Attachment #130067 - Flags: review?(sspitzer)
(Assignee)

Comment 44

15 years ago
(Assignee)

Updated

15 years ago
Assignee: mhw → ataylor
(Assignee)

Comment 45

15 years ago
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

15 years ago
Hmm, that's a great idea!

Comment 47

15 years ago
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.
(Assignee)

Comment 48

15 years ago
Posted file Javascript uncompface v2 (obsolete) —
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.
Attachment #148223 - Attachment is obsolete: true
(Assignee)

Updated

15 years ago
Blocks: 169117

Comment 49

15 years ago
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.
bugzilla-daemon@mozilla.org 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.
Product: MailNews → Core
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!
(Assignee)

Comment 52

14 years ago
Here is the latest version of the javascript implementation, with improvements
from Karsten.
Attachment #148701 - Attachment is obsolete: true
(Assignee)

Comment 53

14 years ago
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/

Updated

14 years ago
Blocks: 163993

Updated

14 years ago
No longer blocks: 163993

Comment 54

14 years ago
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 56

14 years ago
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!
Attachment #130138 - Flags: review?(mscott)
(Assignee)

Comment 57

14 years ago
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.
Blocks: 423488
close?   ^^
QA Contact: nobody → mime
Product: Core → MailNews Core
ok, time to close this.  We should really make sure that extension works with the new thunderbird headers.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WONTFIX

Comment 60

3 years ago
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.