Issue 68777 - Master document loses links to slave documents.
Summary: Master document loses links to slave documents.
Alias: None
Product: Writer
Classification: Application
Component: save-export (show other issues)
Version: OOo 2.0.2
Hardware: PC All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: eric.savary
QA Contact: issues@sw
Keywords: oooqa
Depends on:
Reported: 2006-08-18 16:54 UTC by Rainer Bielefeld
Modified: 2008-04-15 13:26 UTC (History)
4 users (show)

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

Screenshot showing link loss (290.49 KB, application/
2006-08-18 16:58 UTC, Rainer Bielefeld
no flags Details
unzip document and try to reproduce with ba_fuehler.odm (453.55 KB, application/x-compressed)
2006-08-18 17:07 UTC, Rainer Bielefeld
no flags Details
avi-movie demonstrating problem (watch navigator) (943.31 KB, application/x-compressed)
2006-08-25 07:27 UTC, Rainer Bielefeld
no flags Details
Patch for discussion, src680_m185 based. (6.01 KB, patch)
2006-10-23 10:30 UTC, Giuseppe Castagno (aka beppec56)
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description Rainer Bielefeld 2006-08-18 16:54:02 UTC
This problem is 100% reproducible for me with 
"2.0 German version WIN XP: [680m3(Build8968)]"
"2.0.2  German version WIN XP: [680m5(Build9011)]"
"2.0.X  German version WIN XP: [680m180(Build9056)]"
(others not tested)

I will try to create a test kit today!

Steps to reproduce:
1. open master document
2. Menu "File - Send - document as PDF attachment"
   PDF dialogue will open, and in this moment every second link to 
   slave document will be lost. The file name in the Navigator window 
   will be replaced by "Text", and the slave document becomes embedded.
   (pls. see screenshots!).
Comment 1 Rainer Bielefeld 2006-08-18 16:58:13 UTC
Created attachment 38630 [details]
Screenshot showing link loss
Comment 2 Rainer Bielefeld 2006-08-18 17:07:47 UTC
Created attachment 38631 [details]
unzip document and try to reproduce with ba_fuehler.odm
Comment 3 Rainer Bielefeld 2006-08-18 17:19:41 UTC
Also reproducible with "2.0.2  German version WIN 98: [680m5(Build9011)]" on an
other PC.
Comment 4 Rainer Bielefeld 2006-08-18 17:22:33 UTC
I checked with "1.1.4 (German) WIN XP: [645m52 (Build 8824)]": also reproducible.
Comment 5 michael.ruess 2006-08-21 09:39:55 UTC
Reassigned to ES.
Comment 6 eric.savary 2006-08-24 13:47:27 UTC
Mh... Rainer, I tested this on WinXP m178 and m181 and I cannot reproduce it.
Any comment?
Comment 7 Rainer Bielefeld 2006-08-24 16:46:48 UTC
I did some very easy tests:

- Bought a new notebook with preinstalled WIN XP
- connected to our network
- fetched OOo_2.0.2_Win32Intel_install_de.exe from other PC
- standard OOo installation
- standard seamonkey browser installation sm 1.0.4
  created mail account, so that I can test "send as PDF-attachment"
- Fetched Test documents '' from internet
- unzipped
- opened master document (navigator looked fine) 
- Menu "File - Send - as PDF attachment"
  PAFF, every second link to slave doc was lost.

May be something with my installation file, which was used for our 2 tested
2.0.2 installations (implausible, because also wisible with 2 other builds, but
you never know), so

- I uninstalled OOo 2.0.2 from laptop
- downloaded 2.0.3 German version from other server than usual
- installed 2.0.3 (only nonstandard: checked 3 Boxes for "Open MS Office ....")
- again opened master document (navigator looked fine) 
- Menu "File - Send - as PDF attachment"
  PANG, again every second link to slave documents was lost.

No idea why you can not see that effect, I cant believe that that is something
with all my 3  :-/

Something l10n? Implausible because of my successful reproduction with 2.0.X
(sorry, there was a mistake in my report, build 9056 is no German version). 

Something with Seamonkey? I can't believe that.

You really attached as PDF for an email?
Comment 8 Rainer Bielefeld 2006-08-25 07:27:52 UTC
Created attachment 38764 [details]
avi-movie demonstrating problem (watch navigator)
Comment 9 eric.savary 2006-08-25 10:57:32 UTC
I have to apologize, Rainer ("who can read is clear in advantage"???? ;) )!! :(
Of course "Send - E-mail as PDF" is NOT the same as "Ecport to PDF"... grrr!
Comment 10 eric.savary 2006-08-25 10:59:32 UTC
ES->OS: reproducible on all systems.
no regression, no data loss (the links are lost for every second file but the
modifier flag is not set) -> Office later
Comment 11 Giuseppe Castagno (aka beppec56) 2006-10-16 10:50:26 UTC
While I was trying to figure out how to add the functionality requested by issue
64555 I came across this issue and I found that the following patch points where
the problem could be:

--- sw/source/ui/app/docsh2.cxx.i68777  2006-09-17 00:34:10.000000000 +0200
+++ sw/source/ui/app/docsh2.cxx 2006-10-16 11:39:23.000000000 +0200
@@ -1313,7 +1313,7 @@
                                pDoc->UpdateFlds( NULL, false );
-                               pDoc->EmbedAllLinks();
+//                             pDoc->EmbedAllLinks();

by applying it the problem disappeared.

It's not a solution to the issue, that's for sure, but I don't understand what
the method SwDoc::EmbedAllLinks() is doing, so I'm not sure how I can lend a
hand on fixing this.

During one of my test I discovered that if I try to send the master document
using: 'File > Send...> Document as E-mail ', sending the document in its native
format, the links were not canceled (tried with 2.0.4, 9073).

Or may be the bug lurks even deeper in the nested function calls ;-) ?
Comment 12 Oliver Specht 2006-10-16 14:20:19 UTC
It doesn't make much sense to call the code you mentioned for PDF attachments
but this code is shared with the send/document as e-mail.

The embedding of links prevents sending of documents that are linked to other
docs that are unavailable for the recipient. 

Sending e-mail documents should either work on a temporary copies of the source
document or the embedding should be undo-able.
Comment 13 Giuseppe Castagno (aka beppec56) 2006-10-18 12:41:14 UTC
-> os.
Thanks for the hint. I didn't see any CWS taking charge of this issue, so I'll
try to figure out something.
I'll keep asking here if I run into something I don't understand.
Comment 14 Giuseppe Castagno (aka beppec56) 2006-10-23 10:28:34 UTC
The patch I'm going to attach is a proposal to solve the issue for the PDF
export while e-mailing.
I'm not sure it solves it correctly, but doing an analysis of the code I pointed
out in, it seems
ok, there is:

pDoc->UpdateFlds( NULL, false ) :	not sure if this is needed while exporting PDF;
pDoc->EmbedAllLinks():		while exporting to PDF this is not needed, the export
filter renders the linked file;
pDoc->RemoveInvisibleContent()	same as above, the invisible content is rendered
better while exporting than deleting and restoring it after the fact.

I'm not sure of what the remaining functions:


OS, if you spare time, can you explain me what they do?

From these observations I disabled the calls to $-1òü.uno:PrepareMailExportòý
and òü.uno:MailExportFinished" when the file being send is a PDF export of the
one at hand.
It seems working well so far, but I didn't do a full QA, of course. Lacking in
resources for that ;-).

While carrying on these tests, I discovered that this issue affects (with
different impact grades) every e-mail attachment sent, in which the format of
the sent document is different from the one of the original document.
For example when you are sending a Microsoft Word version of an ODT document
containing links to an external file, you hit this same issue.
It seems to me that in these other cases the best solution would be to save them
temporarily and then send through e-mail the tmp version.
Comment 15 Giuseppe Castagno (aka beppec56) 2006-10-23 10:30:27 UTC
Created attachment 39980 [details]
Patch for discussion, src680_m185 based.
Comment 16 Oliver Specht 2006-10-23 12:57:52 UTC
Target changed to 2.x, Issue type changed to patch.

->beppec56: Start/EndAllAction are necessary to block layout operations and
other change notifications while the document is modified.

pDoc->UpdateFlds() updates the fields in the document (see Insert/Fields/Other)

Reassigned to cd because the changes are in sfx2 
Comment 17 carsten.driesner 2006-11-01 08:12:04 UTC
cd->beppec56: Thanks for your patch, it looks ok. I set the target for this
issue to OOo 2.2 and I will add your patch to one of my CWS.
Comment 18 carsten.driesner 2006-11-01 08:12:35 UTC
cd: Target OOo 2.2.
Comment 19 carsten.driesner 2006-11-03 07:56:54 UTC
cd->beppec56: Thanks for your patch. It's now part of CWS fwk56 and will be
integrated into OOo 2.2.
Comment 20 Giuseppe Castagno (aka beppec56) 2006-11-03 08:13:31 UTC
beppec56->cd: You are welcome. Sorry if I didn't show up earlier, but I'm
experimenting with different Linux distros and having only a single notebook, I
wasn't able to answer. Have a nice weekend.
Comment 21 carsten.driesner 2006-12-06 12:37:08 UTC
cd->es: Please verify.
Comment 22 eric.savary 2006-12-15 15:31:28 UTC
ES: verified in cws fwk56
Comment 23 eric.savary 2007-02-01 16:01:22 UTC
Ok in OOF_m5
Comment 24 Rainer Bielefeld 2007-12-13 07:30:14 UTC
Today "2.3.1  Multilingual German version WIN XP: [680m9(Build9238)]" again
destroyed a complex technical documentation when I sent some pages as PDF email :-(

So reopened
Comment 25 pavel 2007-12-22 20:49:58 UTC
Reset target.

Comment 26 Mathias_Bauer 2008-04-15 10:11:25 UTC
Éric, can you verify the problem? In that case we should change the type to
"DEFECT" and assign it to a developer.
Comment 27 eric.savary 2008-04-15 11:04:22 UTC
Cannot reproduce on Win with OOo DEV300m5 using:

with "Fikle - Send - E-mail as PDF"

Master doc and pdf have both 20 identical pages.

Please attach a new sample doc or describe which sub docs are missing.
Comment 28 Rainer Bielefeld 2008-04-15 12:34:23 UTC
I checked with "2.4.0  Multilingual version German UI WIN XP:
[680m12(Build9286)]"  and also with "3.0.0 Beta  Multilingual version English UI
WIN XP: [Dev-300m5 (Build9290)]", with these versions the ugly effect is no
longer visible, while a comparison test with 2.0.2 still showed the problem. Can
that be cnofirmed by someone else?
Comment 29 Rainer Bielefeld 2008-04-15 12:55:08 UTC
The problem was NOT that document pages were lost, the problem was that linked
slave document contents became integrated text contents, as I wrote in my report
and as "" shows. Butthis problem is solved, so we can
close this issue if someone else can confirm the "Worksforme" with a correct test.
Comment 30 eric.savary 2008-04-15 13:26:44 UTC
@rainerbielefeld: if you can confirm that the problem is gone, it's enough to close.