X-face display patch

X-face display patch

[Hrvoje Niksic]

I believe I saw mention of a patch to reenable x-face display under
pgnus-0.84.  Is such a patch available?

Re: X-face display patch

[Karl Kleinpaste]

[-- Attachment #1: Type: text/plain, Size: 153 bytes --]

Hrvoje Niksic <hniksic@srce.hr> writes:
> I believe I saw mention of a patch to reenable x-face display under
> pgnus-0.84.  Is such a patch available?


[-- Attachment #2: X-Face display patch --]
[-- Type: message/rfc-822, Size: 4163 bytes --]

Unintended base64 encoding

[Karl Kleinpaste]

Karl Kleinpaste <karl@justresearch.com> writes:
> --=-=-=
> Content-Type: message/rfc-822
> Content-Disposition: inline; filename=24514
> Content-Transfer-Encoding: base64
> Content-Description: X-Face display patch
> 
> WC1Gcm9tLUxpbmU6IG93bmVyLWRpbmdAaHBjLnVoLmVkdSAgV2VkIE1heSAxMiAxMjoyNTo0
> NCAxOTk5ClJldHVybi1QYXRoOiA8b3duZXItZGluZ0BocGMudWguZWR1PgpSZWNlaXZlZDog

Why did p0.84 decide to do that to me?  I composed the message with
`C-c C-a', specified message/rfc-822, and manually tweaked the
disposition to "inline".  The forwarded message itself was text/plain
and us-ascii.

Duh?  I'm confused.

Re: Unintended base64 encoding

[Lars Magne Ingebrigtsen]

Karl Kleinpaste <karl@justresearch.com> writes:

> > Content-Type: message/rfc-822
> > Content-Transfer-Encoding: base64

[...]

> Why did p0.84 decide to do that to me?

Because mm encodes anything that it doesn't know anything about as
base64.  And it doesn't know about "message/rfc-822", but it does know 
about "message/rfc822".  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Unintended base64 encoding

[Karl Kleinpaste]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Because mm encodes anything that it doesn't know anything about as
> base64.  And it doesn't know about "message/rfc-822", but it does know 
> about "message/rfc822".  :-)

Harumph.  Well, considering that pGnus now (0.85) knows only about
message/rfc822, without the dash, this errant base64ification won't
happen any more.

Re: Unintended base64 encoding

[Toby Speight]

Lars> Lars Magne Ingebrigtsen <URL:mailto:larsi@gnus.org>

0> In <URL:news:m3909o99wo.fsf@quimbies.gnus.org>, Lars wrote:

Lars> ... mm encodes anything that it doesn't know anything about as
Lars> base64.

That's evil.  Why does it do that, rather than inspecting the content
to decide the appropriate encoding?

Re: Unintended base64 encoding

[Lars Magne Ingebrigtsen]

Toby Speight <Toby.Speight@digitivity.com> writes:

> Why does it do that, rather than inspecting the content to decide
> the appropriate encoding?

What is the appropriate encoding?  base64 is always¹ appropriate.

¹) For some values of.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Unintended base64 encoding

[Toby Speight]

Lars> Lars Magne Ingebrigtsen <URL:mailto:larsi@gnus.org>

0> In <URL:news:m3908yrt15.fsf@quimbies.gnus.org>, Lars wrote:

Lars> Toby Speight <Toby.Speight@digitivity.com> writes:

>> Why does it do that, rather than inspecting the content to decide
>> the appropriate encoding?

Lars> What is the appropriate encoding?  base64 is always appropriate.

Some time back (a couple of years, I think), I wrote code for TM which
inspected the message to determine the most space-efficient encoding
(if 8bit/binary weren't possible).  So bodyparts containing mostly
US-ASCII printable characters got q-p encoding, and others got base64,
*irrespective of content-type*.  AIUI, pgnus uses content-type or
disposition as the primary heuristic.

[For large parts, it may be a useful optimisation to only scan perhaps
the first 1K and the last 1K and assume they are representative of the
whole.]

Re: Unintended base64 encoding

[Lars Magne Ingebrigtsen]

Toby Speight <Toby.Speight@streapadair.freeserve.co.uk> writes:

> Some time back (a couple of years, I think), I wrote code for TM which
> inspected the message to determine the most space-efficient encoding
> (if 8bit/binary weren't possible).  So bodyparts containing mostly
> US-ASCII printable characters got q-p encoding, and others got base64,
> *irrespective of content-type*.  

Seems nice.  I've now written the function, but what is the switchover
point between qp and base64?  Math genius wanted!

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Unintended base64 encoding

[François Pinard]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Toby Speight <Toby.Speight@streapadair.freeserve.co.uk> writes:

> > Some time back (a couple of years, I think), I wrote code for TM which
> > inspected the message to determine the most space-efficient encoding
> > (if 8bit/binary weren't possible).  So bodyparts containing mostly
> > US-ASCII printable characters got q-p encoding, and others got base64,
> > *irrespective of content-type*.  

> Seems nice.  I've now written the function, but what is the switchover
> point between qp and base64?  Math genius wanted!

The most efficient encoding might require creating more subparts to a part.
All QP or all 64 might not be the best way to go.  Once away from two
extremes, which is all QP or all 64, recognising that more even subparts
is only an half-hearted solution, why not rather consider optional full
compression with later 64 only?

Unless readability considerations matter and favour QP?  (Yes, I know! :-)

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: Unintended base64 encoding

[Lars Magne Ingebrigtsen]

François Pinard <pinard@iro.umontreal.ca> writes:

> The most efficient encoding might require creating more subparts to a part.
> All QP or all 64 might not be the best way to go.  Once away from two
> extremes, which is all QP or all 64, recognising that more even subparts
> is only an half-hearted solution, why not rather consider optional full
> compression with later 64 only?

I don't want to create further subparts -- if you split, say, a
Postscript file up into oodles of qp, 7bit and base64 parts, I'm
guessing that all the king's horses and all the king's men will have
some difficulty in putting Humpty Dumpty back together again.

So either qp or base64 will have to do.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Unintended base64 encoding

[Aaron M. Ucko]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Seems nice.  I've now written the function, but what is the switchover
> point between qp and base64?  Math genius wanted!

*raises hand* Ooh, ooh, call on me!

QP adds an overhead of roughly 2 characters per non-ASCII character.
("Roughly" because the line-wrapping stuff makes that number slightly
off.)  On the other hand, base64 always adds an overhead of 1/3
character per character.  The breakeven point occurs when these
overheads are equal; i.e., when about 1/6 of the characters are non-ASCII.

-- 
Aaron M. Ucko, KB1CJC <amu@mit.edu> (finger amu@monk.mit.edu)

Re: Unintended base64 encoding

[François Pinard]

amu@MIT.EDU (Aaron M. Ucko) writes:

> > [...] Math genius wanted!
> *raises hand* Ooh, ooh, call on me!

Please forgive me this tiny intrusion.  One of my friends is an active and
involved SF fan.  This is only recently that we communicated electronically.
I laughed a great deal when I saw his signature, with this quote appended:

   "Those who believe in telekinesis, raise my hand!"

Back to our entertaining Gnus-ish efforts :-)

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: Unintended base64 encoding

[Lars Magne Ingebrigtsen]

amu@MIT.EDU (Aaron M. Ucko) writes:

> > Seems nice.  I've now written the function, but what is the switchover
> > point between qp and base64?  Math genius wanted!
> 
> *raises hand* Ooh, ooh, call on me!

:-)

> QP adds an overhead of roughly 2 characters per non-ASCII character.
> ("Roughly" because the line-wrapping stuff makes that number slightly
> off.)  On the other hand, base64 always adds an overhead of 1/3
> character per character.  The breakeven point occurs when these
> overheads are equal; i.e., when about 1/6 of the characters are non-ASCII.

Okidoke; I've now made 0.1666 the limit.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen