Reassigned to MIchael.

Graphics are only embedded in the WinWord .doc format. Original, RTF 
was not created to store embedded graphics. That is the standard, 
Writer remains firm with. So this behaviour is NOT a bug.

I'm sorry, but this is NOT what RTF 1.4 specs says. RTF 1.4 specs has
been written back when Word 6 was released, and I remember having had
that kind of things in even ealier version (I just need to unpack my
books to find the dead tree document).
See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnrtfspec/html/rtfspec_16.asp
for the 1.6 specs online.
I can provide you both 1.4 and 1.5 specs if you really wish too.

Have you guys honestly looked at the RTF spec? Graphics can be
embedded inside of RTF files in addition to WinWord files, and it is
the industry standard to handle graphics this way. RTF has several
keywords for this, including: shppict, pict, and I'm quite sure that
Writer handles these (valid, defacto standard) keywords on importing
RTFs. I'll attach what a normal RTF document with an image in it looks
like. Hub has already posted a link to the RTF 1.6 specification (in
PDF) which describes embedded images in quite some detail. 

http://xml.openoffice.org/ describes your mission for full
inter-operability with other WordProcessors/Existing Products,
standards compliance, and general "openness" in everything that you
do. Please don't say that this is limited to your XML format alone.
This would be a crying shame, especially since about 1billion products
support RTF and about 0 products not developed @ Sun support your XML
format.

Dom Lachowicz, AbiWord and wvWare Maintainer/Lead Developer

Created attachment 719 [details]
A RTF file with *only* an embeded image (smiley-faced balloon)

Fields are since rtfspec 1.2 defined and the import field works since 
WinWord 2.0 version. And I see no reason to change the current 
implementation. What I accept is, that export of embedded pictures 
can write then as \pict. But this means that informations can be 
lost. And so this is for me only a little missing feature of the RTF 
export.

You write it exist definitions about the pict format, thats true only 
the specific RTF tokens, but it exist no definitions about what has 
to write as binary data.

Can you explain how using \pict can cause a loss of data ? I don't see
how it could. BTW I must say that \pict is not even recognized by the
importer. Check the sample document. 
And AbiWord (to take an concrete example)
only export pictures that way (using PNG). And it works in Word, Ted,
etc.

As for the current way to export images, I must say that Word 2000 is
unable to open such a file (I get no pictures) ; neither is Windows
2000 WordPad or Ted (on Linux). So I don't know were that idea come
from, but surely not by testing with that programs.

And you ask for the binary data of the \pict. I encourage you to
re-read the specs, you'll see that there is a keyword to specify the
nature of the stream (JPEG, PNG, BMP, Metafile, etc.) and how binary
data is encoded within such a stream.

And to add the cherry on the top, I must say that fields, despite
being vaguely document, is the most obscure and most sub-standard
thing in the RTF file format.

I'm sorry to argue like that, but I strongly feel that
StarOffice/OpenOffice is wrong on its way to do that.

At a minimum, Writer should be able to import the RTF document created
by Abi, because the document indeed does conform to the RTF 1.6
specification. If you wish to continue to export images via the RTF
fields mechanism, than I guess that's you're perogative and you are
entitled to do it. All I'm pointing out is that it is a substandard
and non-standard way to save images along with the RTF, and, if
anything, encourages dataloss by forcing the user to keep track of N+1
files (where N is the # of images in the document) instead of just 1
file with embedded image data.

Imagine that an OO user wants to send a document with embedded
pictures to an AbiWord or KWord user, and sees that RTF is supported
by all 3 WPs. So the user saves that document to disk, and then emails
it to his friend. The friend now opens the document and notices that
the pictures aren't there. This is dataloss at its finest. This is
beside the fact that there are now N more files on the HD inside of
the directory where the RTF was saved that have the potential to be
lost, deleted accidentally, etc... Heck, copying the RTF file to
another directory on the HD will break this, or uploading to a FTP
server, ...

No, RTF is not a compound document format really, but it does support
embedded images. There are often many ways to solve any given problem.
Not all of them share the same merits.

OpenOffice´s RTF-Filter only supports an older rtfspec than 1.6 (don´t
know at the moment if it´s 1.1 or 1.3, it was introduced before my
time at Star|OpenOffice). Since the winWord filter became more and
more important the RTF filter does not have such a high priority
anymore. So it won´t be upgraded anymore by us (both are MS formats,
and so we decided to enhance the wider spreaded one). That´s the
reason why embedded graphics are not supported by the RTF-Export,
because it would mean too much effort to implemnt a feature which has
too less demand in the public. Our forces are concentrated on the more
important MS file formats.

Hope, you now have patience for closing this issue.

Again, it is your right to "CLOSE WONTFIX" this bug. I'd much
prefer if you marked this as POSTPONED or FUTURE though, under a RFE.
That way if someone wants a neat little project to work on, it'll be
easy to find this, vote for this bug, etc... It would make for a nice
Project of the Week or something easy for a new (OpenSource, non-Sun)
developer to get started on. And, FYI, it only really took us a day to
implement this feature without the incentive of corporate backing (how
long does it take to write a base64 encoder/decoder? How long does it
take to find a GPL one using Google?).

WinWord is the de-facto standard lately, but RTF usage is still
extremely prevalent - so much so that MSWord's filters (those .cnv
files on your Windows hard-drive are really import/export DLLs)
actually convert an input file's data into RTF and pass the RTF stream
to WinWord (or get a RTF stream passed from WinWord and then save that
as HTML or what have you). Just thought that you'd like to know.

See issue 2165

I just tried to import an RTF file exported from Writer (644_m4) in 
the biggste most used, most common big apps. Not one imported the RTF 
file ewith the linked pictures.

Aha. You discuss standards here, but is OOo not supposed to work in 
the REALK world? No on ecan use your exported RTF files at all if 
they want the pictures imported too. That does not count? Why the 
heck then the big discussion about this fantastic open XML format 
when you cannot support RTF, which is more than wiedely used?

Well, I almost consider closing my OOo support website, this is the 
most horrible WONTFIX I have seen in my life. I am drowning in 
discussions about standards and evil MS and the fantastic XML, but 
one thing counts out there, and that is the problems that WE, the 
USERS struggle with.

This unusable RTF export renders Writer unusable for me. And why? 
Because Writer just HAS to write RTF like no one else. Good luck with 
the program, dudes, but I am leaving for MS Office ...

After 12 months of technical discussions I have yet to see the 
StarOffice and OOo developers understand what the users work WITH. 

I am currently connected to an open source project with 3000+ test 
users and THIS will cripple the tests we are going to perform. Thanks 
to you.

Ok. while we don't export these graphics, the .rtf attached to this
issue imports correctly in SRX644m13s1, i.e. either should work for
import in OOoBeta2. Export is another issue of course.

utomo > hub and others:
good news in 680 series (OOo 2.0), check it out when it is available in your 
platform.
:)