Issue 23842 - RTF: Image is missing when exported file opened in MS word.
Summary: RTF: Image is missing when exported file opened in MS word.
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: OOo 1.1
Hardware: All Windows XP
: P3 Trivial with 10 votes (vote)
Target Milestone: ---
Assignee: michael.ruess
QA Contact: issues@sw
Keywords: ms_interoperability
Depends on:
Reported: 2003-12-24 02:05 UTC by utomo99
Modified: 2013-08-07 14:41 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Saving doc to RTF, Image is missing when opened in MS word. (13.41 KB, application/octet-stream)
2003-12-24 02:06 UTC, utomo99
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description utomo99 2003-12-24 02:05:52 UTC
Saving doc to RTF, Image is missing when opened in MS word. 
Also why image is saved outside the documents ? 
This can 
make make documents folders full of image if documents contain many image.
This also risky when somebody move the doc, but not include the image.
In MS Word, the image I think is embedded. CMIIW.
Comment 1 utomo99 2003-12-24 02:06:41 UTC
Created attachment 12094 [details]
Saving doc to RTF, Image is missing when opened in MS word.
Comment 2 utomo99 2003-12-25 13:15:06 UTC
This issue need to be fixed in OOo 1.1.1, to make OOo user easier to 
communicate with MS office user. 
This Issue important since we cannot send the files to MS office user. (image 
is missing)
And we cannot manage the file easily: we cannot rename the file (without rename 
all image name), we cannot easily copy the files, without copying the image one 
by one, and many other complicated things.


Comment 3 jack.warchold 2003-12-30 12:34:31 UTC
reassigend to mru
Comment 4 jack.warchold 2003-12-30 12:35:17 UTC
set target to OOo later

can you please take a look on this issue?
Comment 5 utomo99 2003-12-31 02:59:57 UTC
utomo > JW:
This happend with any documents, and any image, when saved to RTF.
Word user will not able to see any image, from RTF doc created by OOo.  
so it is serious bugs. 

please consider again about the target. 
Comment 6 docta 2004-01-02 09:19:55 UTC
The document doesn't even have to be created in OOo. Just saving a previously
created RTF file with a new name strips out the image.
I created an RTF document (with one image) in WORDPAD  then open it with OOo1.1
and saved it under a new name (WITH NO CHANGES) OOo removed the image and
renamed it.
OOo did the same thing with RTFs created in WORD 2002
2.0 is definitely too long to wait.
Comment 7 jack.warchold 2004-01-05 14:50:13 UTC
removed me from cc
Comment 8 tommasorusso 2004-01-08 13:31:40 UTC
This issue (rtf images saved in other files rather than inline) is duplicate of 
Issue 16895. Vote for that please, and (mru) close this one, as this is a 
request for a new feature strongly requested, but not a defect. Tommaso Russo
Comment 9 michael.ruess 2004-01-08 14:09:32 UTC
Regarding export of graphics as external links, Writer's RTF export complies
with a older RTF specification. This hasn't been actualizes until now and might
be adressed with issue 16895 which trusso mentioned above.

MRU->CMC: In this special case the graphic in the table at the beginning of the
doc is lost (whole graphic, not only the link), when the exported file is opened
in MS Word. Re-opened in Writer, it is ok.
Comment 10 utomo99 2004-01-09 05:19:27 UTC
Please remember that this problem is happend with _Any Image_, with _Any rtf_
documents saved by OOo. (created from OOo, or opened and edited by OOo and then
save again to rtf) all image is not shown at all in word/wordpad. 
probably also not shown in other word processor ? 
so, please consider the target. Thanks

If we put image outside file/folder:
- if the file contain many image, it will make the documents folder full of 
- If we need to rename the file name it will difficult, as we need to rename 
all image one by one. 
- If we want to copy/move the file also difficult. because we need to choose 
all image one by one. there is possibilities that we will mis some if the 
image number is big.
- If we need to send the file also difficult, as we need to select all image one
by one. 
This all are too complicated.

The separate image also simmiliar to html file

Maybe this all not easily solved. but we need to find temporary solutions, so
Word can view the image in rtf file created or saved by OOo. 


Comment 11 utomo99 2004-01-09 05:46:52 UTC
Utomo > MRU & CMC:
MRU->CMC: In this special case the graphic in the table at the beginning of the
doc is lost (whole graphic, not only the link), when the exported file is opened
in MS Word. 
The problem is not special case (not only inside table).
But Any Image, in Any RTF. including when we editing existing rtf file (created
by word/wordpad) also got this problem. 

Re-opened in Writer, it is ok.
>>Comment: Yes, in Writer is OK, also writer can open word RTF contain image
correctly/import is OK. so it is export problem. 

Comment 12 caolanm 2004-02-04 18:05:45 UTC
Ok, lets just do this the right way for at least this class of graphics. For
these inline graphics we'll export the graphic as embedded content just like
word does, I've even added the backwards compatability extra wmf preview just
like word does so that the graphic is visible in wordpad.

That should make a big different to rtf import/export. We'll still have the
bigger issue of floating graphics and the correct way to handle drawings and ole
objects to attend to properly, but this is a major start.

So this example (and many like it) work in tuamfilterteam23 for inclusion in 2.0
Comment 13 utomo99 2004-02-05 03:21:25 UTC
Thanks Caolan. 
But I think OOo 2.0 is too late. 
I think it is important Issue, as this is very basic function which robably 
will be use by many people who use RTF. 
Please consider to include this fix in earlier version if possible, as you 
already have the fix. 
if possible in OOo 1.1.1, I will be happy. 

Comment 14 docta 2004-02-06 02:48:13 UTC
I definitely agree with utomo - 2.0 is _too_ long to wait.
If OOo didn't *take* images *out* of RTF documents that already have them
embedded, it wouldn't be too bad and it might be okay to wait until 2.0. But,
since the RTF files are useless after being opened/saved in OOo it is more
important to get it fixed, so that compatibility can be preserved.
Plus, since the fix is available, I think it should be added as soon as possible.

Thanks a bunch for fixing it, but quicker implementation would be nice too.
Comment 15 caolanm 2004-02-06 09:04:30 UTC
2.0 is too late for support for rtf graphics, 2.0 is also too late for rows that
can split over one page, 2.0 is also too late for unified drawing and fly
frames, 2.0 is also too late for "extra leading" support :-( If there is a
problem it is not with this or any one bug or feature, its with the 2.0
timeline. Feel free to discuss and try and move OOo to more frequent formal
quality milestone alone the route to 2.0 in the and
associated mailing lists. 

1.1.1 and 1.1.2 were explictly marked as being for bugfixes and regressions, so
as it stands for something to go back into 1.1.2 it would want to be a crashfix
or have worked properly in an earlier version. We never properly exported
embedded RTF graphics, so IMO this doesn't qualify for a 1.1.2, and anyhow it
hasn't even passed QA yet to know if I've missed all sorts of new problems I may
have introduced.
Comment 16 utomo99 2004-02-17 03:17:20 UTC
I Reopen this issue as this still problems on m24 which I tested. Please check 
again. Thanks
Comment 17 docta 2004-02-17 04:36:14 UTC
quote (from cmc):-"We never properly exported embedded RTF graphics, so IMO this
doesn't qualify for a 1.1.2" -end quote

Since this is such a long-standing problem (whether recognized as such, or not)
wouldn't it make sense to get it incorporated ASAP? Although, yes, there may be
"bugs" in the bug-fix, but as soon as they are worked out the fix SHOULD be
included in whatever subsequent release it can be reasonably put into.
I certainly would not want it incorporated prematurely, So I hope QA does not
find any problems with your fix.

Comment 18 caolanm 2004-02-17 14:34:25 UTC
Don't change the resolution of my bugs. I am the all seeing all knowing god of
my own bugs and verily I will slay those who reopen them without cause.

I believe this bug to be fixed in *my* workspace tuamfilterteam23 for inclusion
in 2.0, but it hasn't been included in 2.0 yet, so its not in m24, so "not
available in m24 please check" is neither unexpected nor new information to me. 

As soon as I have an install set for this that shows it working I'll pass it to
QA and then it'll be verified and then when it hits a available for download
verision it will get closed (well if it actually works).
Comment 19 utomo99 2004-02-18 03:02:00 UTC
Utomo > Caolan:
Sorry for reopening it. I tought it already included in m24, but after I test 
it I still got same conditions as m22. 
Thanks for the Info. and please let us know when it is available (in which m 
version), so we can test it. 
Comment 20 caolanm 2004-02-18 10:28:25 UTC
reopen to reassign to QA
Comment 21 caolanm 2004-02-18 10:28:55 UTC
cmc->mru: Picture rematerializes in tuamfilterteam23
Comment 22 michael.ruess 2004-02-24 10:07:37 UTC
Checked fix in CWS tuamfilterteam23.
Comment 23 michael.ruess 2004-02-24 10:17:28 UTC
Comment 24 tommasorusso 2004-02-24 10:53:44 UTC
Please let us know the release that will first incorporate this fix.
Is it already available for external users?
Comment 25 michael.ruess 2004-07-22 08:15:38 UTC
Checked in 680m47