On Mon, Sep 09, 2002 at 09:42:21AM -0700, Michael Elkins wrote:
> Brian Grayson wrote:
> > I downloaded 1.4 on Friday just to see, and the same problem
> > occurs. The fundamental problem is once the CTE code sees a
> > nonzero value of lobin, it goes into quoted, regardless of
> > whether hibi
On 2002-09-09 09:42:21 -0700, Michael Elkins wrote:
>Thanks for the extra info. I looked into this more closely, and I
>see that there are a couple of factors that come into play into
>this situation. First, I noticed that your PDF attachment was
>labeled improperly as "text/plain". This
Brian Grayson wrote:
> I downloaded 1.4 on Friday just to see, and the same problem
> occurs. The fundamental problem is once the CTE code sees a
> nonzero value of lobin, it goes into quoted, regardless of
> whether hibin is nonzero. The following patch does the right
> thing for my testcase
On Fri, Sep 06, 2002 at 11:21:09PM -0700, Michael Elkins wrote:
> Brian Grayson wrote:
> > Hm. I have 1.2.5 source locally, and it looks like in
> > mutt_set_encoding() in sendlib.c, the following logic may be
> > faulty:
>
> I just noticed that you are using an extremely ancient version of Mu
Brian Grayson wrote:
> Hm. I have 1.2.5 source locally, and it looks like in
> mutt_set_encoding() in sendlib.c, the following logic may be
> faulty:
I just noticed that you are using an extremely ancient version of Mutt
(0.95). Please try using Mutt 1.4, which is the current stable version.
Hm. I have 1.2.5 source locally, and it looks like in
mutt_set_encoding() in sendlib.c, the following logic may be
faulty:
static void mutt_set_encoding (BODY *b, CONTENT *info)
{
if (b->type == TYPETEXT)
{
if (info->lobin || info->linemax > 990 || (info->from &&
opt
I'm attaching three files:
rep1k (quoted -- this is what came up). This is the first 1K
of the PDF that misbehaved, and it decided wrong.
rep.5k (8bit -- this is what came up, so it guessed right).
This is only the first 512 bytes of the PDF.
rep1k, forced to use base64 encoding, so th
