lynx-dev outgoing_mail_charset (was: megapatch)

[Klaus Weide]

On Sun, 17 Oct 1999, Leonid Pauzner wrote:

> 13-Oct-99 12:31 Klaus Weide wrote:
> > It's in <http://enteract.com/~kweide/lynx/>.
> 
> > * LYPrint.c: In subject_translate8bit (see OUTGOING_MAIL_CHARSET
> >   option), use higher level function to charset-translate mail Subject
> >   line, rather than low-level UCTransCharStr.
> 
> > [ It actually works better now, including for UTF-8.
> > OUTGOING_MAIL_CHARSET is awfully misnamed for what it does. ]
> 
> The idea was to change GridText.c::print_wwwfile_to_fd()
> so it will convert a mailed page to OUTGOING_MAIL_CHARSET also.
> Not implemented, sorry.
> Could you come up with a patch one day?

Could you come with a patch? :)

You probably have thought about it more, like where the translation
should occur.

I think calling the same function I used in subject_translate8bit,
LYUCTranslateBackHeaderText aka LYUCTranslateBackFormData, should
give the best results.  The simplest would be to just call it once
for every complete line.  But the lines has to be copied (LYUCTrans*
might reallocate it) and stripped of LY_BOLD_* and LY_UNDERLINE_*
chars (I don't know what happens if they are left in).

There's Vlad's non-NO_DUMP_WITH_BACKSPACES stuff now in
print_wwwfile_to_fd.  But that should not come into effect
anyway for mail.  (If it does now, that's bad.)  The other
"else if"s also shouldn't matter, the unusual stuff depends
on dump_output_immediately.

I already forgot why exactly I chose the _Back_ version. :-(
But mostly because that tries hard not to generate lynx special
characters; if anything it should translate them back to something
more suitable for the outside world.

But I'm not sure I like all this...  It will give some (approximation
of) a character set 'translation', but the outgoing ";charset=" in
the mail headers would also have to be set right.

We are talking about a way of sending mail where the user has no chance
to review the translation before it gets sent.  It may have become
complete garbage, and the user wouldn't be able to notice that
garbage is going out (under his/her name).

Well I guess you could say the user shouldn't use the option then...

The Rightest Way would be to just send the data in the current
charset, appropriately labelled and MIME-encoded.

   Klaus