Apache OpenOffice (AOO) Bugzilla – Issue 68777
Master document loses links to slave documents.
Last modified: 2008-04-15 13:26:44 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!).
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.