> SMB exporte (or imported ?) outbound.
>
> The problems is that the *.?lo files are written by a DOS program, using
> some strange capitalization; then the files on the fs don't follow
> that capitalization.
EC> Aha, so when ifgate generates .flo's for dos transport that works but
EC> when dos tosser generates .flo's for ifcico then ifcico may not see the
EC> files referred in the .flo... I see. I wonder how this may be worked
EC> around cleanly...
IMHO, the only correct way is to handle that at the file-system level.
Configure samba so that all files are seen by Linux as lowercase.
Then ifcico will see them (as it lowercases the path written in the *.?lo
file)
EC> I was always reluctant to include charset support without (at least basic)
EC> MIME support.
What do you call 'basic MIME support' ?
I use MIME for the charset support; of course I only handle text/plain
(and text/html); as handling other types would be useless anyway; the FTN
programs are either unable to handle concepts of multipart, embedded images,
etc.
EC> OTOH full support for b64/qp encodings and multipart/
EC> embedded messages seems an unreasonable complication.
Quoted-printable and B64 support is needed however; as FTN only understands
8bits, it is necessary to convert to 8bits when gating; otherwise the messages
are unreadable.
EC> I now feel that
EC> the proper way would be to combine ifmail/ifnews with a separate filter
EC> that could deal with MIME encodings and pass to ifmail a clean text/plain
EC> message with encoding=8bit. Most probably the same program could even
EC> trnaslate the character set and put new charset= attribute. The only
EC> thing ifmail would do is convert charset= mime attribute into ^aCHRS
EC> kludge. What do you think?
It could be done like that too.
But as the code to do that in ifgate is already done I don't really see what
a separate process could add.
The current weakness are:
- when converting FTN->rfc the subject line isn't always correctly converted
(as it is read before knowing the real charset used by the FTN message;
and besides that I also saw messages using different charsets for the subj.)
- when converting rfc->FTN and the rfc message uses unicode, the conversion
isn't very good (I only implemented simple conversions
(to iso-8859-{1,5,6,7,8} as they need only to remove a given offset; no
complex tables involved)
I also added, as some people needed it, the possibility to force to ignore
the charset indications for messages coming from a given *.pkt (per link
configuration); and the possibility to force messages to a given node to be in
a given charset (to allow people with lame programs not handling CHRS to
see properly the messages).
It is really not so much different of your code; the difference is that
the conversion function doesn't use a compiled in table, but receives the
name of the table to use as a parameter; and the table to use is decided
after scanning the headers/kludges lines, and the config file, to know the
original charset used, and the one wanted after gating.
And to be consistent, the CHRS/Content-Type lines are rewritten to reflect
the charset used in the message that is written (the original CHRS is
kept on a X-FTN-ORIGCHRS: line, so it can be reverted back (almost, but the
lost chars are on the range of the illegal ones anyway (semigraphics)) when
gating back to FTN.
EC> Eugene
-- À bientôt, Pablo Saratxaga PGP Key available, key ID: 0x8F0E4975