Just curious: has anybody else experienced LibreOffice Writer crashing when trying to open the .docx RM10 produced Narrative Report?
LibreOffice Version: 25.2.2.2 (X86_64) / LibreOffice Community
Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac
CPU threads: 12; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded Writer
If you would share your DOCX file, others could see if it crashes on their LibreOffice and also in Microsoft Word and other software that supports the format.
Do all such reports crash LibreOffice, e.g., same report but smaller group of people, same report but no citations, âŚ
I downloaded and installed the latest. Yes, it did crash. I then checked if the file could be opened by the first Google result for online viewing a .DOCX file (JumpShare). It opened it fine for viewing.
Thanks guys for the replies.
@TomH the example .docx is here:
@kbens0n by latest Iâm assuming you mean LibreOffice 25.2.2
Iâm thinking that this issue might possibly be related to 25.2.2 because I donât recall this issue being present when earlier tests done last fall when I first purchased RM. Accordingly, have uninstalled 25.2.2 and will install 24.8.6 next - will report back after system restart.
Yes, and I did send a crash report, also.
Just an aside, I uploaded the .DOCX to Zamzar online and converted to .ODT
The file opened in LibreOffice just fine.
Issue is present in 24.8.6.2, though no crash report was offered to be sent and now Iâm unable to launch LibreOffice.
Yep, that âlockedâ file is likely being held open by some LibreOffice component (.DLL or Windows Services). Ending the (soffice.bin) Process (Tree) from Task Manager ~may~ allow the program to be reinitialized.
I also downloaded in .odt direct from Google Docs and opened in 25.2.2.2.
docx also crashes 25.2.2.2. Crash report sent.
@BobC - thank you for confirming
In the FWIW column - I mentioned above trying an earlier test last fall, though now believe that RM10 version tested then was not current (v10.0.5 build 30 Jan 2025)
The LibreOffice message offering to send the crash report popped after
The âyou can soon find the report âŚâ maybe helps?
It doesnât help with the problem with LibreOffice, but I use RMâs *.docx files heavily with Microsoft Word, and I have never had a crash. It makes it hard to suggest that RM has a bug with their *.docx files when Microsoft Word handles them just fine.
In my opinion, RM does have a problem if not an actual bug with their *.docx files when it comes to NEHGS and NGSQ reports which are my go to reports for descendant narratives. Other formats of narrative reports may have the same problem, but those are the only ones I use. My alleged bug does not cause Microsoft Word to crash, but itâs still a problem for me. Namely, RMâs *.docx files have huge amounts of excessive white space in transitional parts of the reports, for example in the transitional white space between a person and their spouse.
If that were the only problem, I could clean it up very easily and quickly with Microsoft Word using global search and replace. But there are also misplaced XE entries that appear right in the middle of that excessive white space. The XE entries are Index Entries that RM puts into the *.docx file so that Microsoft Word can generate the Name Index and the Place Index. The misplaced XE entries right in the middle of the excessive white space makes it very hard for me to clean up the excessive white space. Itâs a wild guess and a shot in the dark since I donât use LibreOffice, but I wonder if those misplaced XE entries are causing LibreOffice to crash. I doubt it, but itâs something to consider
@thejerrybryan Thank you for your input which may be related to LO crashings and my choise of NGSQ (modified register).
To be clear, I donât mean to be pointing fingers at LO or RM. Just the observed issue.
I stripped out LibreOffice quite a while ago; all thatâs left is LibreCAD. Iirc, Both OpenOffice and LibreOffice had issues with RM7âs RTF export - not crashing but screwed up.
Google Docs - 66 pages (direct from your link)
Microsoft Office 365 - 58 pages (downloaded from Google Docs)
Atlantis Word Processor Lite 4.3.5.3 - 48 pages (re-downloaded from Google Docs)
All seemed to render it well; I guess the variations in the number of pages have to do with differences in default styles. Atlantis gets to the 4th child on the first page while Google Docs only to the 1st. The Names and Places Indexes were not expanded. I do not know if the DOCX file exported from Google Docs is identical to the file that you uploaded.
@TomH - Thatâs rather interesting that loading the RM10 .docx file into docs.google and then downloading the same from docs.google as a .docx file allows it to be opened in LO without issue. Almost like a cleaner. If nothing else that seems like a possible workaround or sorts, styling notwithstanding.
In the wake and for my own workaround, Iâve been selecting the PDF option and then placing the PDF into AffPub2, Page Layout & Design Software | Affinity Publisher where other bits can be added; e.g., a descendant fan chart.
I found that opening a RM RTF in Microsoft Word (some old desktop version like 2016 or 2012) and resaving it as RTF or as DOC would allow LibreOffice to open it without the screw-ups it had with the original. Also, the Atlantis developer was helpful in pointing out where RM was not following RTF specs but kindly patched his software to accommodate the exception. I reported it to RM Inc but I donât recall that it was corrected. And then they abandoned RTF in favour of DOCX with a different report writer.
Back in RM7 I discovered I could not open RM generated narrative.docx files in LibreOffice Writer, it would crash LO when I tried to open the docx file.
I tracked the problem down to LO Writer, not RM or MS Office Word. This is as best I recall the issue details.
When RM7-10 saves a narrative report, it provides indexes for surnames an places at the very end of the file. To see them, these need to be expanded by the user manually when they open the file using Word (F9).
As best I recall, the issue was my RM data I had Fact Place & Place Detail fields that had 4 and 5 levels, that is 4-5 commas separating fields ex. (building, ward, city, county, state, country). MS Word allows relatively deep nesting of the levels. However, I think LO Writer only allows about 3 levels. When LO Writer opens the .docx file and encounters that âF9 expansionâ codes, it crashes.
Work-around:
Generate RM Narrative Report narrative reports.docx.
Open file in MS Word
Delete the indexes at the end of the narrative reports file
Save modified .docx file
Open file in LO Writer, it opens fine, but you obviously youâve lost the nice indexes cross-references.
I just re-verified crash problem and kludgy work-around fix on my current setup.
VirtualBox 7; Win10 guest; MS Office 2021 Word; RM 10.0.5
Linux Ubuntu 24.10; LO 24.8.x.x
FYI: I no longer have LO installed on a Win10 machine to test it as I have mostly migrated to the Linux world. When I isolated the problem years ago it was using Win7, RM7 and the current versions of Office & LO at the time. Back then I was experimenting with generating simple RTF/DOCX/ODF documents directly from the RM sqlite DB.
Very minor correction. RM7 did not generate *.docx files. Rather, it generated *.rtf files. But that doesnât change anything about the thrust of your message. In the RM7 days, there were occasionally reports of *.rtf files that could be opened in Microsoft Word and that could not be opened in LibreOffice or one of the other free alternatives to Microsoft Word.
By the way, this is first time I remember the problem as having been identified as an excessive number of levels in the Place Index. Thatâs good to know.
Another workaround would have been to turn off the index option at the time RM generated the report. But of course, I really like those indexes.
Just a quick thought-- you could also uncheck include place details in the reportâif places still too long such as you still have Kansas City, Jackson Co. Mo, United States, then you could:
If the index is the only thing that causes the crashes and not the use of all 4 or 5 levels in the narrative, you probably could just copy the index, edit it and then replace it.
@Gjohn Thank you John for adding to this discussion.
@nkess & @thejerrybryan Iâve started searching where in RM10âs Narrative Report Settings the indices could be turned off but was unsuccessful.
FWIW
The issue isnât confined to Narrative reports. I just tested this using the Family Group Sheet and LO crashed when attempting to open the .docx. I havenât tested it with other publishing options but now anticipate that the issue will be present.
Buzbee, Bruce, Getting the Most Out of RootsMagic 10, page 233,
When printing a report to a Word (DOCX) file RootsMagic will not actually build the index at the end of the report(since RootsMagic has no way of knowing how your word processor will paginate the report). Instead, RootsMagic will âmarkâ each person in the Word file so that your word processor can build the index itself. This is extremely useful in case you want to add more text, photos, or make other changes.
RootsMagic will add instructions on how to generate the index to the Word document.
The so-called âmarkingâ and the added âinstructionsâ possibly are related to LibreOffice crashing when the the place level detail fields number was >?
To test this idea and to try and find the unknown number, I started with 3 levels; i.e., city, county, state. The location checker wanted me to add United States, but for this first test, I declined. Result: LibreOffice crashed.
For the 2nd test, I started with 3 levels; i.e., county, state, country which sated the location checker, but not LibreOffice.
For the 3rd test, only 2 levels; i.e., state and country, and still LibreOffice crashed.
For the 4th test, only country, still LibreOffice crashed.
For the 5th and final test, no places were entered, and still LibreOffice crashed.
Even though there were zero places, is a Place Index extant?
Crash reports were sent in all 5 cases; below are a few of them.
