Created attachment 38630 [details]
Screenshot showing link loss

Created attachment 38631 [details]
unzip document and try to reproduce with ba_fuehler.odm

Also reproducible with "2.0.2  German version WIN 98: [680m5(Build9011)]" on an
other PC.

I checked with "1.1.4 (German) WIN XP: [645m52 (Build 8824)]": also reproducible.

Reassigned to ES.

Mh... Rainer, I tested this on WinXP m178 and m181 and I cannot reproduce it.
Any comment?

@es:
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 'linkloss_testkit.zip' 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?

Created attachment 38764 [details]
avi-movie demonstrating problem (watch navigator)

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!

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

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 @@
                                if(pWrtShell)
                                        pWrtShell->StartAllAction();
                                pDoc->UpdateFlds( NULL, false );
-                               pDoc->EmbedAllLinks();
+//                             pDoc->EmbedAllLinks();
                                pDoc->RemoveInvisibleContent();
                                if(pWrtShell)
                                        pWrtShell->EndAllAction();


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 ;-) ?

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.

-> 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.

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  http://www.openoffice.org/issues/show_bug.cgi?id=68777#desc12, 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:

pWrtShell->StartAllAction();
pWrtShell->EndAllAction();

do.
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.

Created attachment 39980 [details]
Patch for discussion, src680_m185 based.

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 

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.

cd: Target OOo 2.2.

cd->beppec56: Thanks for your patch. It's now part of CWS fwk56 and will be
integrated into OOo 2.2.

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.

cd->es: Please verify.

ES: verified in cws fwk56

Ok in OOF_m5

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

Reset target.

Éric, can you verify the problem? In that case we should change the type to
"DEFECT" and assign it to a developer.

Cannot reproduce on Win with OOo DEV300m5 using:
http://www.openoffice.org/nonav/issues/showattachment.cgi/38631/linkloss_testkit.zip

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.

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?

@es 
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 "movieshowingproblem.zip" shows. Butthis problem is solved, so we can
close this issue if someone else can confirm the "Worksforme" with a correct test.

@rainerbielefeld: if you can confirm that the problem is gone, it's enough to close.