Mixing text and graphics with text/enriched and multipart/mixed
Martin R Raskovsky
==| Unless I'm missing something, this is really bad, but I don't see any way around
==| this with the standard as it is today.
Yes, you are missing something, it was Nathaniel Borenstein that pointed to
me that the spec has been explicity written to allow contiguous alignment of
images and text. As soon as I have the time, I will look at the relevant spec
and comment.
==| This and a few other gotchas we've had
==| in the past makes me wonder how many other real implementations of
==| text/enriched there are out there. I suspect not very many.
MMail does it correctly , look in http://www.atelier.co.uk
--------------
Dr. Martin R. Raskovsky e-mail: mar...@atelier.demon.co.uk
Atelier de Software Ltd. voice: +44 (1934) 822 983
Rookery Farm, Puxton fax: +44 (1934) 820 209
Avon, BS24. 6TL. England url: http://www.atelier.co.uk
Harald.T....@uninett.no
I read this as "functionality is not within text/enriched".
I hope that the currently active MHTML IETF working group will get
the specs right for shipping text-with-graphics inside text/html,
allowing us to support only one of the beasts.
Have fun!
Harald A
Martin R Raskovsky
Well, I can't find the spec, but I found what Nathaniel Borenstein told me:
From: Nathaniel Borenstein <n...@nsb.fv.com>
Subject: Re: Images within Text
Date: Fri, 5 May 1995 12:56:09 -0400 (EDT)
... it's a design decision in MIME. One of the main reasons why the multipart
boundary is defined to INCLUDE the CRLF that leads into it is precisely to
enable this sort of situation. That is, the CRLF before the boundary is a part
of the boundary, not a part of the preceding part, according to the MIME spec.
Terry Crowley
>> The only currently "standard" way of mixing rich text and graphics in MIME
>> that I know of is to use an enclosing multipart/mixed containing
>> text/enriched and image/* body parts. However, since each text/enriched
>> part needs to be complete in itself, we need to terminate the <<center>
>> directive before adding each image/* part. This, in turn, means that
>> we'll be forcing a newline to be displayed on the receiving end next to
>> each <<center> or <</center>.
I discovered this problem three or four years ago. As Nathaniel pointed out,
the original MIME spec was indeed careful about being able to generate body
parts (specifically text/richtext) that did not end in CRLF. Some interpreters
(e.g Andrew) then interpreted this to mean that the following object should
appear on the same line. However, the clarifications made when text/enriched
was written to more carefully specify line breaking issues around alignment
directives apparently broke this in the example you are giving.
However, the more important issue is that multipart/mixed places no concrete
requirements on the layout of the individual parts, certainly not to the
details of how a missing or present CRLF on one object should change the way
the following object is layed out. It was reasonably clearly understood at the
time MIME was written that the proper way to handle this was to have one
representation (e.g HTML) that specifies the relationship of a set of objects
and then use multipart/mixed (or some other multipart subtype) as the way of
packaging those objects.
If someone desired to enhance text/enriched to provide the necessary control
you want, the proper way of achieving this would be to support references
within the text/enriched to other objects (e.g. by Content-ID) in a containing
multipart/mixed object. Or to have some new multipart subtype that explicitly
requires text/enriched as the first object followed by any referenced objects
(one could make the argument that this more clearly reflects the semantics).
Terry
Pete Resnick
On 5/3/96 at 3:55 AM -0500, Martin R Raskovsky wrote:
>Well, I can't find the spec, but I found what Nathaniel Borenstein told me:
>
>From: Nathaniel Borenstein <n...@nsb.fv.com>
>Subject: Re: Images within Text
>Date: Fri, 5 May 1995 12:56:09 -0400 (EDT)
>
>... it's a design decision in MIME. One of the main reasons why the multipart
>boundary is defined to INCLUDE the CRLF that leads into it is precisely to
>enable this sort of situation. That is, the CRLF before the boundary is a part
>of the boundary, not a part of the preceding part, according to the MIME spec.
That doesn't help because each of the paragraph formatting commands like
<center>, which is what Lennart was using, will cause a line break and
commands cannot be continued across multipart boundaries. Anyway, whether
or not the CRLF is included in the MIME boundary turns out to be
irrelavent, even in text/plain. There is no implied presentation
information given by that fact. You are at the very least not guaranteed
that you'll get what you want out of any given package.
Harald is correct: There is simply no way to do this in text/enriched, at
least reliably. The only solution is to go to text/html, which includes a
mechanism for displaying inline images.
BTW Lennart, you should take a RFC 1896, since 1563 was obseleted by that.
(I was one of the co-authors, so I've got to push my wares!)
pr
--
Pete Resnick <mailto:pres...@qualcomm.com>
QUALCOMM Incorporated
Home: (217)337-1905 / Fax: (217)337-1980
Harald.T....@uninett.no
The question was not whether there is a newline after a bodypart or not,
but whether it is legal to assume that a <center> specification in a
text/enriched document has force outside the boundaries of the
text/enriched body part.
To me, the answer is a clear and resounding NO: The MIME strategy is that
bodyparts are independent, unless some bodyparts are specifically
specified to "control" others, such as in multipart/encrypted or
the suggested multipart/related of the MHTML group.
If we say that some portion of attributes set at an arbitrary position
within a bodypart influences the display of the next body parts in a
sequence, correct presentation of bodyparts becomes arbitrarily hard.
This is simply WRONG, no matter how Nathaniel wants to handle body parts
without a terminating NL.
Harald A