MIME vs HTML

MIME vs HTML

[Lars Magne Ingebrigtsen]

Aha!  Now I know how Microsofties do MIME properly -- they don't.
Instead they do HTML with

<img src="cid:003e01be1642$a526f940$b86efea9@win">

tags inside, which allows an entire document consisting of many parts
to be rendered.  Which makes sense.

If Gnus is to render this properly, I guess Gnus will have to
transform these so that w3 can pick up the images properly...  (Gnus
will have to stop rendering the HTML in one window and copying it
over, though, since images don't survive that very well.  William --
any comments?)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Magne Ingebrigtsen

Re: MIME vs HTML

[William M. Perry]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> Aha!  Now I know how Microsofties do MIME properly -- they don't.
> Instead they do HTML with
> 
> <img src="cid:003e01be1642$a526f940$b86efea9@win">

  There's nothing wrong with this.  Perfectly reasonable given the age of
the CID URL draft. :)  I actually sent you email about how we could make
this easy for Emacs/W3 to support. :)

> tags inside, which allows an entire document consisting of many parts to
> be rendered.  Which makes sense.
> 
> If Gnus is to render this properly, I guess Gnus will have to transform
> these so that w3 can pick up the images properly...  (Gnus will have to
> stop rendering the HTML in one window and copying it over, though, since
> images don't survive that very well.  William -- any comments?)

  If GNUs can bind a variable or provide a function that would allow a
'cid' URL handler in Emacs/W3 to get the part and header information
associated with a content-id, I could just do:

(url-register-protocol 'cid nil 'url-identity-expander)

(defun gnus-mime-get-part-by-content-id (cid)
  "Returns a MIME part given it's content-id."
  .
  .
  .
  )

(defun gnus-part-content-type (part)
  "Returns the content-type of a MIME part"
  .
  .
  .
  )

(defun gnus-part-content-encoding (part)
  "Returns the content-encoding of a MIME part"
  .
  .
  .
  )

(defun url-cid (url)
  (set-buffer (get-buffer-create url-working-buffer))
  (let ((content-type nil)
	(encoding nil)
	(part nil)
	(data nil))
    (if (not (string-match "^cid:\\(.*\\)" url))
	(message "Malformed CID URL: %s" url)
      (setq url (url-unhex-string (match-string 1 url))
	    part (gnus-mime-get-part-by-content-id url))
      (if (not part)
	  (message "Unknown CID encounterred: %s" url)
	(setq data (gnus-part-body part)
	      content-type (gnus-part-content-type part)
	      encoding (gnus-part-content-encoding part))
	(if (= 0 (length content-type)) (setq content-type "text/plain"))
	(if (= 0 (length encoding)) (setq encoding "8bit"))
	(setq url-current-content-length (length data)
	      url-current-mime-type content-type
	      url-current-mime-encoding encoding
	      url-current-mime-headers (list (cons "content-type" content-type)
					     (cons "content-encoding" encoding)))
	(and data (insert data))))))

And voila!

-Bill P.

Re: MIME vs HTML

[Lars Magne Ingebrigtsen]

wmperry@aventail.com (William M. Perry) writes:

> I actually sent you email about how we could make
> this easy for Emacs/W3 to support. :)

Oops.  I forgot all about that...

>   If GNUs can bind a variable or provide a function that would allow a
> 'cid' URL handler in Emacs/W3 to get the part and header information
> associated with a content-id, I could just do:
> 
> (url-register-protocol 'cid nil 'url-identity-expander)
> 
> (defun gnus-mime-get-part-by-content-id (cid)
>   "Returns a MIME part given it's content-id."
>   .
>   .
>   .
>   )

(etc).

I added all of these, and then it turned out I had already written all 
these function.  :-)

The new version of url-cid is then:

(defun url-cid (url)
  (set-buffer (get-buffer-create url-working-buffer))
  (let ((content-type nil)
	(encoding nil)
	(part nil)
	(data nil))
    (if (not (string-match "^cid:\\(.*\\)" url))
	(message "Malformed CID URL: %s" url)
      (setq url (url-unhex-string (match-string 1 url))
	    part (mm-get-content-id url))
      (if (not part)
	  (message "Unknown CID encounterred: %s" url)
	(setq data (buffer-string nil nil (mm-handle-buffer part))
	      content-type (mm-handle-type part)
	      encoding (symbol-name (mm-handle-encoding part)))
	(if (= 0 (length content-type)) (setq content-type "text/plain"))
	(if (= 0 (length encoding)) (setq encoding "8bit"))
	(setq url-current-content-length (length data)
	      url-current-mime-type content-type
	      url-current-mime-encoding encoding
	      url-current-mime-headers (list (cons "content-type" content-type)
					     (cons "content-encoding" encoding)))
	(and data (insert data))))))

And this function is called, and it seems to me that everything is
inserted as it should and stuff.  (After twiddling slightly with some
other stuff.)

However, w3 doesn't look like it wants to render the picture.  Here's
how Gnus displays the HTML:

> Denne e-mail'en er skrevet i Outlook Express. Teksten her er grønn. I venstre
> marg ligger det et bilde. Og her: [cid:003e01be1642$a526f940$b86efea9@win]har
> jeg satt inn et annet bilde, med "baseline" alignment.

So instead of the picture, w3 inserts a button...

Anyway, while we're talking about w3:  If there's a

<META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>

in the message, which is something Outlook Express seems to put into
everything it sends out, w3 will render this thusly:

html;charset=iso-8859-1 http-equiv=Content-Type>

Which is rather odd.  (This is with the w3 that comes with XEmacs 21.2 
(Aglaia).)

Oh, and stuff like

<STYLE>
<!--
body {
margin-left: 4em;
color: "#427D64";
font-size: 12pt;
font-weight: regular;
font-family: "Arial";
}
-->
</STYLE>

isn't parsed, but perhaps it shouldn't be?

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

Re: MIME vs HTML

[William M. Perry]

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

> wmperry@aventail.com (William M. Perry) writes:
> 
> > I actually sent you email about how we could make
> > this easy for Emacs/W3 to support. :)
> 
> Oops.  I forgot all about that...
> 
> >   If GNUs can bind a variable or provide a function that would allow a
> > 'cid' URL handler in Emacs/W3 to get the part and header information
> > associated with a content-id, I could just do:
> > 
> > (url-register-protocol 'cid nil 'url-identity-expander)
> > 
> > (defun gnus-mime-get-part-by-content-id (cid)
> >   "Returns a MIME part given it's content-id."
> >   .
> >   .
> >   .
> >   )
> 
> (etc).
> 
> I added all of these, and then it turned out I had already written all 
> these function.  :-)

  Sweet!

> The new version of url-cid is then:
> 
> (defun url-cid (url)
>   (set-buffer (get-buffer-create url-working-buffer))
>   (let ((content-type nil)
> 	(encoding nil)
> 	(part nil)
> 	(data nil))
>     (if (not (string-match "^cid:\\(.*\\)" url))
> 	(message "Malformed CID URL: %s" url)
>       (setq url (url-unhex-string (match-string 1 url))
> 	    part (mm-get-content-id url))
>       (if (not part)
> 	  (message "Unknown CID encounterred: %s" url)
> 	(setq data (buffer-string nil nil (mm-handle-buffer part))
> 	      content-type (mm-handle-type part)
> 	      encoding (symbol-name (mm-handle-encoding part)))
> 	(if (= 0 (length content-type)) (setq content-type "text/plain"))
> 	(if (= 0 (length encoding)) (setq encoding "8bit"))
> 	(setq url-current-content-length (length data)
> 	      url-current-mime-type content-type
> 	      url-current-mime-encoding encoding
> 	      url-current-mime-headers (list (cons "content-type" content-type)
> 					     (cons "content-encoding" encoding)))
> 	(and data (insert data))))))

  This will be in the next version of Emacs/W3... gotta upgrade myself to
pgnus soon I guess. :)

> And this function is called, and it seems to me that everything is
> inserted as it should and stuff.  (After twiddling slightly with some
> other stuff.)
> 
> However, w3 doesn't look like it wants to render the picture.  Here's how
> Gnus displays the HTML:
> 
> > Denne e-mail'en er skrevet i Outlook Express. Teksten her er grønn. I venstre
> > marg ligger det et bilde. Og her: [cid:003e01be1642$a526f940$b86efea9@win]har
> > jeg satt inn et annet bilde, med "baseline" alignment.
> 
> So instead of the picture, w3 inserts a button...

  Hmmm... sounds like the data is corrupt somehow (the glyph isn't being
parsed correctly by XEmacs).

> Anyway, while we're talking about w3:  If there's a
> 
> <META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>
> 
> in the message, which is something Outlook Express seems to put into
> everything it sends out, w3 will render this thusly:
> 
> html;charset=iso-8859-1 http-equiv=Content-Type>

  fucking microsoft.  '/' is not valid unless it is quoted there.  Grrrr.
I'll see what I can do for the next release.

> Oh, and stuff like
> 
> <STYLE>
> <!--
> body {
> margin-left: 4em;
> color: "#427D64";
> font-size: 12pt;
> font-weight: regular;
> font-family: "Arial";
> }
> -->
> </STYLE>
> 
> isn't parsed, but perhaps it shouldn't be?

  Where is it located?  Head, body, etc?

-Bill P.

Re: MIME vs HTML

[William M. Perry]

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

> wmperry@aventail.com (William M. Perry) writes:
> 
> > I actually sent you email about how we could make
> > this easy for Emacs/W3 to support. :)
> 
> Oops.  I forgot all about that...
> 
> >   If GNUs can bind a variable or provide a function that would allow a
> > 'cid' URL handler in Emacs/W3 to get the part and header information
> > associated with a content-id, I could just do:
> > 
> > (url-register-protocol 'cid nil 'url-identity-expander)
> > 
> > (defun gnus-mime-get-part-by-content-id (cid)
> >   "Returns a MIME part given it's content-id."
> >   .
> >   .
> >   .
> >   )
> 
> (etc).
> 
> I added all of these, and then it turned out I had already written all 
> these function.  :-)
> 
> The new version of url-cid is then:

[...]

> And this function is called, and it seems to me that everything is
> inserted as it should and stuff.  (After twiddling slightly with some
> other stuff.)
> 
> However, w3 doesn't look like it wants to render the picture.  Here's how
> Gnus displays the HTML:

[...]

> So instead of the picture, w3 inserts a button...

  Try this version of url-cid:

(defun url-cid-gnus (cid)
  (set-buffer (get-buffer-create url-working-buffer))
  (let ((content-type nil)
 	(encoding nil)
 	(part nil)
 	(data nil))
    (setq part (mm-get-content-id url))
    (if (not part)
	(message "Unknown CID encounterred: %s" url)
      (setq data (buffer-string nil nil (mm-handle-buffer part))
	    content-type (mm-handle-type part)
	    encoding (symbol-name (mm-handle-encoding part)))
      (if (= 0 (length content-type)) (setq content-type "text/plain"))
      (if (= 0 (length encoding)) (setq encoding "8bit"))
      (if (listp content-type)
	  (setq content-type (car content-type)))
      (setq url-current-content-length (length data)
	    url-current-mime-type content-type
	    url-current-mime-encoding encoding
	    url-current-mime-headers (list (cons "content-type" content-type)
					   (cons "content-encoding" encoding)))
      (and data (insert data)))))

(defun url-cid (url)
  (if (not (string-match "^cid:\\(.*\\)" url))
      (message "Malformed CID URL: %s" url)
    (setq url (url-unhex-string (match-string 1 url)))
    (cond
     ((fboundp 'mm-get-content-id)
      ;; Using Pterodactyl Gnus or later
      (url-cid-gnus url))
     (t
      (message "Unable to handle CID URL: %s" url)))))

and apply this patch to w3-display.el

Index: w3-display.el
===================================================================
RCS file: /usr/people/wmperry/.cvs/w3/lisp/w3-display.el,v
retrieving revision 1.227
diff -c -w -c -w -r1.227 w3-display.el
*** w3-display.el	1998/11/22 21:30:38	1.227
--- w3-display.el	1998/11/29 04:51:14
***************
*** 781,786 ****
--- 781,787 ----
  (defun w3-finalize-image-download (url buffer &optional widget face)
    (let ((glyph nil)
  	(node nil))
+     (url-uncompress)
      (message "Enhancing image...")
      (setq glyph (image-normalize (cdr-safe (assoc url-current-mime-type
  						  w3-image-mappings))


> Anyway, while we're talking about w3:  If there's a
> 
> <META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>
> 
> in the message, which is something Outlook Express seems to put into
> everything it sends out, w3 will render this thusly:
> 
> html;charset=iso-8859-1 http-equiv=Content-Type>
> 
> Which is rather odd.  (This is with the w3 that comes with XEmacs 21.2 
> (Aglaia).)

  Fixed in the next beta (b29, out tomorrow at some point).

-Bill P.

Re: MIME vs HTML

[Lars Magne Ingebrigtsen]

wmperry@aventail.com (William M. Perry) writes:

> > html;charset=iso-8859-1 http-equiv=Content-Type>
> 
>   fucking microsoft.  '/' is not valid unless it is quoted there.  Grrrr.
> I'll see what I can do for the next release.

Works perfectly in b30.

> > Oh, and stuff like
> > 
> > <STYLE>

[...]

> > </STYLE>

[...]

>   Where is it located?  Head, body, etc?

This, too, is handled by b30 correctly.

The previous message I posted should demonstrate how a typical
"advanced" Outlook Express message should look.  One needs the latest
w3 and pgnus 0.56 to view it correctly.

One funny thing about this is that after running w3 on the article,
the background color, as well as the background image, is set
permanently in the article buffer forever after, which might not be
optimal...  :-)

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

Re: MIME vs HTML

[William M. Perry]

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

> wmperry@aventail.com (William M. Perry) writes:
> 
> > > html;charset=iso-8859-1 http-equiv=Content-Type>
> > 
> >   fucking microsoft.  '/' is not valid unless it is quoted there.  Grrrr.
> > I'll see what I can do for the next release.
> 
> Works perfectly in b30.
> 
> > > Oh, and stuff like
> > > 
> > > <STYLE>
> 
> [...]
> 
> > > </STYLE>
> 
> [...]
> 
> >   Where is it located?  Head, body, etc?
> 
> This, too, is handled by b30 correctly.

  Great.

> The previous message I posted should demonstrate how a typical "advanced"
> Outlook Express message should look.  One needs the latest w3 and pgnus
> 0.56 to view it correctly.

  Looks great!

> One funny thing about this is that after running w3 on the article, the
> background color, as well as the background image, is set permanently in
> the article buffer forever after, which might not be optimal...  :-)

  Definitely not with those colors...  This is probably because I set the
specifier for the default face on the _buffer_ - I thought you did your
HTML drawing in a separate buffer?

-Bill P.

Re: MIME vs HTML

[Lars Magne Ingebrigtsen]

wmperry@aventail.com (William M. Perry) writes:

>   Definitely not with those colors...  This is probably because I set the
> specifier for the default face on the _buffer_ - I thought you did your
> HTML drawing in a separate buffer?

I did, but I changed it to use the render in the article buffer so
that pictures and stuff would survive.

One solution would be to have the undisplayer function reset the
buffer background (and stuff) to what it was before w3 did, er,
stuff.  Is there a w3 function that might be called to "normalize" the 
buffer?

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

Re: MIME vs HTML

[Lars Magne Ingebrigtsen]

wmperry@aventail.com (William M. Perry) writes:

>   Definitely not with those colors...

One weird thing -- if I view the multipart/related thing is viewed as
the first article, the HTML-rendered text is shown with the picture as
the background, as it should be.  But if I then kill the article
buffer and view it again, the HTML-rendered text is given a white
background, which gives the HTML-rendered text an, er, blocky look.
The un-HTML-rendered text still uses the picture background.

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

Re: MIME vs HTML

[William M. Perry]

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

> wmperry@aventail.com (William M. Perry) writes:
> 
> >   Definitely not with those colors...  This is probably because I set the
> > specifier for the default face on the _buffer_ - I thought you did your
> > HTML drawing in a separate buffer?
> 
> I did, but I changed it to use the render in the article buffer so that
> pictures and stuff would survive.
> 
> One solution would be to have the undisplayer function reset the buffer
> background (and stuff) to what it was before w3 did, er, stuff.  Is there
> a w3 function that might be called to "normalize" the buffer?

(defun remove-w3-properties (&optional buffer)
  (setq buffer (or buffer (current-buffer)))
  (mapc (lambda (prop) (remove-specifier (face-property 'default prop) buffer))
	'(background background-pixmap foreground)))

(remove-w3-properties (get-buffer gnus-article-buffer))

What about that?  Or...


*** mm-view.el~ Sun Nov 29 11:54:37 1998
--- mm-view.el  Mon Nov 30 17:02:36 1998
***************
*** 83,88 ****
--- 83,90 ----
           handle
           `(lambda ()
              (let (buffer-read-only)
+               (mapc (lambda (prop) (remove-specifier (face-property 'default prop) (current-buffer)))
+                     '(background background-pixmap foreground))
                (delete-region
                 ,(set-marker (make-marker) (point-min))
                 ,(set-marker (make-marker) (point-max)))))))))

This seems to do the trick for me.

-bp

Re: MIME vs HTML

[William M. Perry]

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

> wmperry@aventail.com (William M. Perry) writes:
> 
> >   Definitely not with those colors...
> 
> One weird thing -- if I view the multipart/related thing is viewed as the
> first article, the HTML-rendered text is shown with the picture as the
> background, as it should be.  But if I then kill the article buffer and
> view it again, the HTML-rendered text is given a white background, which
> gives the HTML-rendered text an, er, blocky look.  The un-HTML-rendered
> text still uses the picture background.

  Try this patch... It's not quite doing the right thing with face
specifiers for the non-default face.  This just makes it stop caching faces 
that have a background-image specified.  I'm not even sure how big a win
the face cache is.

-Bill P.

Index: w3-display.el
===================================================================
RCS file: /usr/people/wmperry/.cvs/w3/lisp/w3-display.el,v
retrieving revision 1.228
diff -c -w -c -w -r1.228 w3-display.el
*** w3-display.el	1998/11/29 05:08:56	1.228
--- w3-display.el	1998/11/30 22:07:14
***************
*** 299,307 ****
  	(font-set-face-foreground w3-face-face (car w3-face-color)))
      (if (car w3-face-background-color)
  	(font-set-face-background w3-face-face (car w3-face-background-color)))
      (setq w3-face-cache (cons
  			 (cons w3-face-descr w3-face-face)
! 			 w3-face-cache)))
    w3-face-face)
  
  (defun w3-normalize-spaces (string)
--- 299,308 ----
  	(font-set-face-foreground w3-face-face (car w3-face-color)))
      (if (car w3-face-background-color)
  	(font-set-face-background w3-face-face (car w3-face-background-color)))
+     (if (not (car w3-face-background-image))
  	(setq w3-face-cache (cons
  			     (cons w3-face-descr w3-face-face)
! 			     w3-face-cache))))
    w3-face-face)
  
  (defun w3-normalize-spaces (string)

Re: MIME vs HTML

[Lars Magne Ingebrigtsen]

wmperry@aventail.com (William M. Perry) writes:

> +               (mapc (lambda (prop) (remove-specifier (face-property 'default prop) (current-buffer)))
> +                     '(background background-pixmap foreground))

Yup; that did the trick.  I've applied it to 0.58.

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

Re: MIME vs HTML

[Lars Magne Ingebrigtsen]

wmperry@aventail.com (William M. Perry) writes:

>   Try this patch... It's not quite doing the right thing with face
> specifiers for the non-default face.  This just makes it stop caching faces 
> that have a background-image specified. 

This patch fixes the problem.

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

Re: MIME vs HTML

[Joe Wells]

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

  Lars> <META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>

  Lars> in the message, which is something Outlook Express seems to put into
  Lars> everything it sends out, w3 will render this thusly:

  Lars> html;charset=iso-8859-1 http-equiv=Content-Type>

This is the only possible legal interpretation of the purported HTML
document.  There's a standard defining these things, you know.

-- 
Joe

Re: MIME vs HTML

[Hrvoje Niksic]

Joe Wells <jbw@cs.bu.edu> writes:

> >>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
>   Lars> <META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>
> 
>   Lars> in the message, which is something Outlook Express seems to put into
>   Lars> everything it sends out, w3 will render this thusly:
> 
>   Lars> html;charset=iso-8859-1 http-equiv=Content-Type>
> 
> This is the only possible legal interpretation of the purported HTML
> document.  There's a standard defining these things, you know.

The trouble is that users expect us to fix things so they work, no
matter how abhorrent the source of the brokenness.  Here is a
beautiful diatribe by Kyle Jones on that topic:

    From: kyle_jones@wonderworks.com (Kyle Jones)
    Newsgroups: gnu.emacs.gnus
    Subject: Re: `AW:' not recognised as reply indicator
    Date: 14 Mar 1997 01:07:46 -0500
    Organization: Wonderworks Inc.

    Jens Lautenbacher  <jens@lemcbed.lem.uni-karlsruhe.de> wrote:
     > Lars Magne Ingebrigtsen <larsi@trym.ifi.uio.no> writes:
     > 
     > > Florian Weimer <fw@cygnus.stuttgart.netsurf.de> writes:
     > > 
     > > > I've recently encountered some messages which where using
     > > > `AW:' as reply indicator (abbreviation for the German word
     > > > `Antwort', AFAIK generated only by MS Exchange).  Of course,
     > > > the software which produces such awkward messages should be
     > > > fixed, but I think it would be a good idea to make the regexp
     > > > in `gnus-simplify-subject' user-customisable.
     > > 
     > > It's never a good idea to cater to broken software.  Using "AW:"
     > > instead of "Re:" is broken.
     > > 
     > 
     > But it's the wrong end that suffers from your decision not to
     > cope with this gracefully (that means me). *I* use gnus, so
     > people on the other end will get non-broken messages. *I* will
     > get these AW: type mails (and thats from people who must use
     > this damned billy toy) and its *me* who will get a totally
     > fudged out threading because gnus doesn't want to cope with
     > it....
     > 
     > PLEASE....

    I can't help but laugh, because this is major deja news with
    regard to me, VM and all kinds of brokenness in other more
    popular software.

    Like it or not, we are in the minority.  The minority always
    suffers, unless they have money or nuclear weapons.  This means
    you and me.

    Lars and I suffer because there is no end to the Internet access
    crapware emerging from the nether regions of PC software vendors.
    You suffer because dung rolls downhill and there are limits to
    the amount of it we are able (or willing) to shovel for you.

    The other day I found myself thinking that there isn't any real
    incentive to strive for interoperability.  Given the amount of
    brokenness out there and vendors colossal indifference to it, the
    amount of work seems the same as it was in the old days when
    everything was proprietary.  The truth is probably that things
    were just impossible back then, so little was exepcted by the
    users.  But you begin to see how bad the situation is when people
    trying to adhere to standards feel like Sisyphus eternally
    rolling a monstrous dungball uphill.  (Then again, maybe I just
    need to take a vacation.)

    The point of article is to say... We're in this together.  Take
    out your frustration on Microsoft.  If you have nuclear weapons,
    use them.  Otherwise just stop buying their software.  Gates
    doesn't need any more money.  The world is what we make it.