From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/35121 Path: main.gmane.org!not-for-mail From: Daniel Pittman Newsgroups: gmane.emacs.gnus.general Subject: Re: MML 'encoding' tag value ignored... Date: 01 Mar 2001 09:54:06 +1100 Organization: Not today, thank you, Mother. Sender: owner-ding@hpc.uh.edu Message-ID: <87n1b6a06p.fsf@inanna.rimspace.net> References: <87d7c3o54j.fsf@inanna.rimspace.net> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035170912 1275 80.91.224.250 (21 Oct 2002 03:28:32 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 03:28:32 +0000 (UTC) Keywords: daniel,win32,encoding,pdf,base64,well,type,though Return-Path: Original-Received: from lisa.math.uh.edu (lisa.math.uh.edu [129.7.128.49]) by mailhost.sclp.com (Postfix) with ESMTP id 9B505D049E for ; Wed, 28 Feb 2001 17:57:30 -0500 (EST) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by lisa.math.uh.edu (8.9.1/8.9.1) with ESMTP id QAB31961; Wed, 28 Feb 2001 16:55:24 -0600 (CST) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Wed, 28 Feb 2001 16:54:32 -0600 (CST) Original-Received: from mailhost.sclp.com (postfix@66-209.196.61.interliant.com [209.196.61.66] (may be forged)) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id QAA27172 for ; Wed, 28 Feb 2001 16:54:19 -0600 (CST) Original-Received: from melancholia.danann.net (melancholia.danann.net [203.36.211.210]) by mailhost.sclp.com (Postfix) with ESMTP id C6974D049E for ; Wed, 28 Feb 2001 17:54:46 -0500 (EST) Original-Received: from localhost (melancholia.danann.net [203.36.211.210]) by melancholia.danann.net (Postfix) with ESMTP id 01EF72A8C9 for ; Thu, 1 Mar 2001 09:54:43 +1100 (EST) Original-Received: by localhost (Postfix, from userid 1000) id 2237582167; Thu, 1 Mar 2001 09:54:07 +1100 (EST) Original-To: ding@gnus.org In-Reply-To: (Toby Speight's message of "28 Feb 2001 16:39:12 +0000") X-Homepage: http://danann.net/ X-spies: Ortega Ft. Bragg munitions Ruby Ridge ECHELON Ft. Knox NORAD Area 51 Qaddafi spy nuclear assassination Honduras genetic David John Oates User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Thalia) Precedence: list X-Majordomo: 1.94.jlt7 Original-Lines: 69 Xref: main.gmane.org gmane.emacs.gnus.general:35121 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:35121 On 28 Feb 2001, Toby Speight wrote: > 0> In article <87d7c3o54j.fsf@inanna.rimspace.net>, > 0> Daniel Pittman ("Daniel") wrote: > > Daniel> In trying to work out why a PDF file was being corrupted when > Daniel> sent from Gnus to several Win32 mailers, I found two things. > Daniel> > Daniel> Firstly, Gnus was selecting quoted-printable encoding for the > Daniel> PDF file. This was then incorrectly decoded by both Outlook > Daniel> and Eudora on the Win32 machine, resulting in a corrupt PDF > Daniel> file. > Daniel> > Daniel> Specifically, LF => CRLF conversion was happening on the Win32 > Daniel> machine. Now, I don't know the QP spec well, so I can't tell > Daniel> if this is correct behaviour for the Win32 machines. > > I think the fix for this is to quote LF and CR in non-text parts: > > -> =0A= > -> =0D= > -> =0D=0A= Well, if it were possible to ship PDF files as QP without Win32 exploding, that would be great... > Daniel> If it is, though, I think that 'application/.*' MIME entities > Daniel> should be encoded with base64 exclusively, to avoid this sort > Daniel> of problem. > > I thought you could Configure that somehow? > > [/me RTFMs] > > `mm-content-transfer-encoding-defaults' is what you're looking for, > though it's not defcustom in 5.8.3. Well, no. `mm-content-transfer-encoding-defaults' now features `("application/.*" base64)' for me, but that's not the point. The point is that the MML tag specified an encoding. Explicitly. Because I put it there. This, according to the documentation, should override whatever is in `mm-content-transfer-encoding-defaults' because I, as the user, wanted something different in this case. Heck, the code in the MIME composing is even written in an attempt to make this possible, I think.[1] It's just not _used_ in the code. Seriously, though, what would you expect this MML tag to encode the content as? <#part type="some/type" encoding="base64"> I know that /I/ expected base64, regardless of what the *default* encoding of MIME objects of "some/type" was. Because I told Gnus what I wanted. Daniel Footnotes: [1] I didn't quite follow through what was implemented but there is *definitely* support in `mm-encode-buffer' for specifying an explicit encoding. -- Estne Tibi Forte Magna Feles Fulva Et Planissima?