Re: Tin MIME charset handling inconsistency in normal and full header display modes

Urs Janßen <[email protected]>
Newsgroups gmane.network.tin.user
Message-ID <[email protected]>
On Sun, Sep 28, 2003 at 03:13:36PM +0300, Ville Mattila wrote:
> >the problem lies in the broken article you look at, 8bit chars in the
> >body without mime-headers are not allowed. you might want to have a
> >look at tin(5) attributes:undeclared_charset to assign a charset !=
> >us_ascii to such articles.
> 
> 	Thank you! Setting undeclared_charset=ISO-8859-1 works fine
> 	for me with tin-1.6.2. Should've read the manual right away,
> 	this attribute seems not to be covered in options menu.
> 
> 	As tin users at my site probably never will need to able to
> 	read Usenet articles written in languages requiring other 8
> 	bit charsets than ISO-8859-1, I think I'll just recompile with

ISO-8859-1 does not include the euro-sign, ISO-8859-15 does, but that
is _not_ the only difference between those two charsets.

> 	  '--with-mime-default-charset=ISO-8859-1' and
> 	  '--disable-mime-strict-charset'.
> 	- That would do the same trick I guess.

I don't think so, as IIRC --disable-mime-strict-charset has no effect
when the system has iconv(3), --disable-mime-strict-charset was a
hack to make tin think that the charset used in the article does
match the local charset (which usualy was the case several years ago,
but today it's not as besides ISO-8859-x there are a lot of ther
charsets in use (i.e. Windows-125x, UTF-8, ...).
--with-mime-default-charset=ISO-8859-1 will set the default network
(outgoing) charset on systems which do have iconv(3).

if you are the systems administrator and like to 'force' 8-bit
postings without mime-headers to get ISO-8859-1 as charset attached
use the system wide attributes file (/etc/tin/attributes) - users may
override any settings made there within thier attributes file.

urs
-- 
"Only whimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it ;)" - Linus
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.