Created attachment 125781 [details] Direct export of FTM 2014 RTF prior to opening in Writer Opening an RTF exported by Family Tree Maker 2014-1, Writer ignores formatting (tabs, indents, soft returns) and deletes characters. Yet when I open an RTF from FTM 2006, Writer works as advertised. I've attached an RTF exported directly from Family Tree Maker 2014-1 prior to opening in Writer. Am also reporting this to MacKiev for them to check their end.
Created attachment 125782 [details] FTM 2006 file after opening in Writer This is what the 2014 file should look like.
It would be nice to see the intended look of the 2014 file as a PDF. Does it work OK in Microsoft Word? Do you have access to Word? If not, I can try it later. After we confirm the actual problems, we have to split this report to multiple ones, because one report should only be about one issue.
Created attachment 125919 [details] PDF Created from FTM 2014 Here's a PDF file using FTM 2014. I don't have access to Word, though.
In the summary you write "body overwrites header" - what does this mean?
Created attachment 125920 [details] Example of overwriting header See 2nd page of attachment.
Created attachment 125922 [details] What I thought were headers....
Okay, I thought the headers were screwing up, but looks like I might have been wrong. If you open the What I thought were headers atch, and look at pgs 2 & 3 - page break is out of place. I don't know if Libre entered it or if it's embedded in the exported file. But, the bold lines are dividing lines between generations, yet they're out of place, too. I apologize - I know I'm not explaining this very well.
Ok, the file actually looks like it should in LibreOffice 3.3 so this is a regression. I confirmed the problem on Linux, so changing OS to All. Bibisecters: look at the pdf in attachment 125919 [details] to see how it should be laid out. LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 Arch Linux 64-bit, KDE Plasma 5 Version: 5.3.0.0.alpha0+ Build ID: f3d26af51588af441f62fb69bb7a5432845226ac CPU Threads: 8; OS Version: Linux 4.6; UI Render: default; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on August 5th 2016
Just to confirm this is bibisectable: it works also in Version 3.6.7.2 (Build ID: e183d5b)
One difference I see between 3.6 and master is that the "Generation 1" paragraph has a large left margin on 3.6, and it's 0 on master. I plan to look at that.
Bibisecting using bibisect-44max.git: 868fae4fac0679d728ca6ec756a4c3b5fda43a77 is the first bad commit commit 868fae4fac0679d728ca6ec756a4c3b5fda43a77 Author: Matthew Francis <mjay.francis@gmail.com> Date: Sat Mar 14 21:40:46 2015 +0800 source-hash-1be0a3fa9ebb22b607c54b47739d4467acfed259 commit 1be0a3fa9ebb22b607c54b47739d4467acfed259 Author: Michael Stahl <mstahl@redhat.com> AuthorDate: Tue Jun 17 18:40:04 2014 +0200 Commit: Michael Stahl <mstahl@redhat.com> CommitDate: Tue Jun 17 18:42:07 2014 +0200 n#825305: writerfilter RTF import: override style properties like Word It would certainly be immediately obvious to any reader of the RTF spec that \sN will apply the style with index N to the current paragraph. But actually, that is not what Word does when it reads \sN... what it really does is to apply the style with index N, and then for every attribute in that style, apply the same attribute with a default value to the paragraph, effectively overriding what's in the style. If that doesn't make any sense to you, well, have you heard the joke about how many Microsoft engineers it takes to change a light bulb? Also, \pard apparently implies \s0. To implement that, change RTFSprms::deduplicate() to recursively look for style SPRMs that are missing in the properties, and put in default ones, currently just for 2 keywords \sa and \sb. This requires changing deduplicate() to be const and return a new value, since it is no longer idempotent, as the erased SPRMs would get defaulted on the next run. While at it, fix RTFValue::equals() which did not compare m_sValue. This fixes the testParaBottomMargin test that was broken by the fix for fdo#70578. Change-Id: I4ced38628d76f6c41b488d608a804883493ff00b :040000 040000 28e3aedf8721ecacc6cb7d7166ee96448d71d9ca 2824ba57aa0ff76d64e426af2ae5e20bc5e150a5 M opt Adding Cc: to mstahl@redhat.com
Ah, I know what's going on: \*\cs0 in the document describes a character style with the id 0, which is quite unusual, as the 0th style is normally a paragraph one; and our assumption blows up when trying to use that style name as a paragraph style name later, resulting in loosing paragraph properties. I'll fix this.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2de168e99ba9cd2539f1ddbeffad7e3eb71a7b1b tdf#100507 RTF import: don't set default para style to the 0th char style It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=faaec32b1b6f2a9f8fb0541a5355beddfec37432&h=libreoffice-5-2 tdf#100507 RTF import: don't set default para style to the 0th char style It will be available in 5.2.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.