lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev outgoing_mail_charset (was: megapatch)


From: Leonid Pauzner
Subject: Re: lynx-dev outgoing_mail_charset (was: megapatch)
Date: Sun, 17 Oct 1999 21:39:17 +0400 (MSD)

17-Oct-99 09:22 Klaus Weide wrote:
> On Sun, 17 Oct 1999, Leonid Pauzner wrote:

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

Yes, I was unhappy with all this special cases LY_BOLD_*, LY_SOFT_HYPHEN,
backspaces (no idea about it et all) and such.

Perhaps a better idea is using of second temp file: read the result of
print_wwwfile_to_fd() and convert it via LYUCTranslateBackFormData()
line-by-line, but you decide this as a complication...
Now when you invent a higher level conversion function we have no problem with
utf-8 charset if any.

> There's Vlad's non-NO_DUMP_WITH_BACKSPACES stuff now in
> print_wwwfile_to_fd.  But that should not come into effect

[snipped]

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

The explanation given in lynx.cfg: there are many d.c.s. possible and (remote)
mail agent may not recognize iso-8859-4 or cp866 or other uncommon charsets.
Some kind of approximation would not be too bad - lynx have already done the
conversion to d.c.s. ("internal" charset) - why not to convert it more if
necessary? Anyway, the approximation is more readable than garbage.

In my particular case - d.c.s=cp866 which is generally not recognized
by mail agents, but windows-1251 and koi8-r are.
(also, 128-159 characters got stripped from the subject line
by my mail provider; windows-1251 and koi8 keep letters out of this range).

Sure, we need a proper charset mail header.

>    Klaus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]