QP encoder is needed in order to send Latin1 mail (M4). Message send needs encoders from libmime through xpcom.

Kat, can I put you as qa contact for this bug?

Sure, I just put myself in there and replace me with yours in the CC line.

If anyone can note the specific function calls, that would speed the development :-)

There are empty functions defined in compose/src/msgCompGlue.cpp and used in compose/src/nsMsgSend.cpp and nsMsgSendPart.cpp. There are 7 functions, in libmime they're in mimeenc.cpp. Looks like init functions return function pointers. I am not sure if this is ok in xpcom. MimeEncoderData * MimeB64EncoderInit(int (*output_fn) (const char *buf, int32 size, void *closure), void *closure) {return NULL;} MimeEncoderData * MimeQPEncoderInit (int (*output_fn) (const char *buf, int32 size, void *closure), void *closure) {return NULL;} MimeEncoderData * MimeUUEncoderInit (char *filename, int (*output_fn) (const char *buf, int32 size, void *closure), void *closure) {return NULL;} int MimeEncoderDestroy(MimeEncoderData *data, XP_Bool abort_p) {return 0;} int MimeEncoderWrite (MimeEncoderData *data, const char *buffer, int32 size) {return 0;} char * MimeGuessURLContentName(MWContext *context, const char *url) {return NULL;} void MIME_GetMessageCryptoState(MWContext *,PRBool *,PRBool *,PRBool *,PRBool *) {return;}

Thanks! I will get on this very soon. I may change the name of the other interface I defined called nsIMimeHeaderConverter.h to nsIMimeConverters.h and that way, we can add these routines as we need to. How does that sound? - rhp

I think it's good to combine encoders into one interface.

These interfaces have been exported via a new XP-COM interface in libmime. What I've done is change the old nsIMimeHeaderConverter.h to nsIMimeConverter.h. A detailed view of the interface can be found at: http://lxr.mozilla.org/mozilla/source/mailnews/mime/public/nsIMimeConverter.h Let me know if there are any problems. - rhp

** Checked with 4/8/99 Win32 evening build ** I think that these encoders are being made available now for sending mail -- see Bug 3994. But I noted a problem in Bug 3994 in that while encoding is talking place, there is also a truncation problem leading to incomplete headers. I don't know if this is the problem in engaging the encoder or the encoder itself. Looking at nsIMimeConverter.h, it seems that the line length is defined there, so the truncation problem might reside in nsIMimeConverter.h. We cannot look at Base64 encoding part since Latin 1 mail does not use B (or Base64), but Japanese message display does. The B-ecoded Japanese headers are dhowing correctly. Since nsIMimeConverter.h seems to do both encoding and decoding, this would tend to confirm that Base64 part is also being used successfully. I'm going to hold off on verifying this bug until more is found about the problem in 3994.

Bug 3994 is for header encoding only. This bug is about body encoding (QP, Base64, UU). In M4, because of the Ender problem (4388), this can be only verified by writing JavaScript to access the message compose appcore.

We tried a suggested workaround on the latest build, i.e. modifying msgcompose.xul directly to send out 8-bit body, but ran into a problem which prevents us from checking on this. I'll have to wait until some workaround is found.

Bug 5525 is now blocking the verification of this fix. MIME-encoding should be working now but whatever we send disappears due to Bug 5525.

QP can be verified now because we can send Latin1. Base64 cannot be tested because we have no attachment send capability. 5525 is Japanese body send bug, as we don't base64 Japanese main body, it is not related to this bug.

** Checked with 4/27/99 Win32 build ** Thanks, Naoki, for clarification. I'm going to mark this bug fix verified based on the test results on "Latin 1 body send" which is properly encoded in QP. If we want to test Base 64 encoder, then we will do so when we have a feature working which uses this encoder.