I’m having two problems with narrative reports saved in MS Word format: (1) Excessive spacing between paragraphs, (2) Italics are printing as regular text. The on-screen report and the PDF output report look good with spacing and italics.
Attached photos show parts of a narrative report in PDF, in MS Word with formatting codes showing, and in MS Word without codes. The highlighted MS Word with codes shows what seems to be excessive paragraph marks and line breaks. And especially between the last line of the narrative and the listing of the “Preparer”
Attached photos of endnote citation both PDF and MS Word. Highlighted Word portions should be italics. The font is SegoeUI but I’ve also tried it with Times New Roman.
In the report settings, I have “Paragraphs” set to “New paragraph after facts with notes.” This example does not have any notes.
I’m a frequent user of RM’s narrative reports with MS Word output. I have never seen the italics problem you describe. But I can confirm the problem of excessive space between paragraphs. I call it the “excessive vertical white space” problem. As you mentioned, the on-screen report and the PDF version of the report do not have the excessive vertical white space.
When I am printing RM’s reports on paper for public consumption, I always need to do some cleanup before printing anyway, saving the reports as *.docx files and editing them with MS Word. So I just clean up the excessive vertical white space as a part of the overall cleanup process. My process is not perfect in cleaning up all of the excessive vertical white space, but it cleans up most of it.
What I basically do is two steps. The first step is to replace all occurrences of new line with a paragraph marker. This requires using the code ^l for new line and ^p for a paragraph marker in the MS Word global replace dialog… This is to prepare for the next step because the new lines and the paragraph markers can be all mixed together. The second step is to replace of all occurences of three consecutive paragraph markers with two consecutive occurrences. This requires replacing ^p^p^p with ^p^p. I repeat until there are no more changes.
The listing of the Preparer requires a little special attention. Not only is there excessive vertical white space before the Preparer text, there is excessive vertical white space within the Preparer text. But I just do that with local editing, rather than trying to do some sort of global search and replace.
I probably need to look at italics again to be sure I’m not seeing the same italics problem you are seeing.
Correction: I am actually seeing the italics problems. All italics are being lost in the .docx file. I guess I had just failed to notice the problem before.
I also should mention one situation where my workaround for the vertical white space problem is not effective. Namely, I include a name index and a place index in my reports. That means that RM includes XE entries in the *.docx file. The XE entries are Index Entries that MS Word uses to build the name index and the place index. For the most part, the XE entries are right next to the name or place that is being indexed and they don’t produce any excessive white space. But sometimes there is an XE entry that is sort of floating in space in the middle of the excess vertical white space. The presence of the XE entries in the middle of the vertical white space will prevent my workaround for the excessive vertical white space from being effective. I can obviously go through my document page by page looking for this residual white space. But that’s nowhere near as easy as just doing a global replace.
I was willing to work through the excessive white space problem. But I have a family reunion coming up in a few weeks where I may want to use RM7 to print my reports rather than using RM10 because of the italics problem.
Jerry, thanks for confirming the issues. Renee, could you please capture these two issues as bugs (see my initial post above)? (BTW, the loss of italics formatting occurs in both the endnotes and within the narrative text.)
Interesting that you mention using RM7 to print narrative reports. I was wondering how well that would work. I just tried it, using the checkbox for “Extra details (RM specific)” in the Gedcom Export Options dialog box. It worked well bringing the file back into RM7. It kept my source templates and the narrative report looked good. I had to make a few RM settings, e.g. I don’t print Census facts, but instead Residence facts. So I had to adjust that in the Fact type list. Also of course fonts. Loss of italics in the MS Word file in RM10 would be another show stopper for me, but maybe I continue with this RM10/RM7 approach and hopefully the team can address this.
I did not realize that I had a problem with the italics in RM10’s narrative reports until I saw your message. I have a family reunion coming up in three weeks. I put RM9 into production in June 2023, and I maintained all my data in both RM7 and RM9/10 until July of this year (lots of extra work and double data entry for over a year). Until then, I could have easily printed my report with current data in RM7, but I have now lost the ability to do that. I do have access to an SQLite script that worked to revert an RM9 database to RM7 that I could use to produce my report for the reunion, assuming the script still works in RM10. I’ll have to play with it to see what my options are.
So Jerry what I was mentioning a couple of messages ago was exporting Gedcom from RM10, including the “Extra details (RM specific)” option and importing into RM7. It produced the needed narrative (no excessive spacing, italics included) in RM7, using the RTF Save option in 7, with a couple of caveats that I’m seeing having to do with the fact type list. Customization of the fact type list in RM10 did not carry over into RM7, specifically fact “Use”, “Include”, and “Sentence template.” I’ve kept track of sentence templates that I’ve customized. And for some facts I’ve added “Description” to “Use”. For census facts I’ve changed “Include” on “Narrative Reports” to No, because I use Residence fact instead.
Screen shots attached include (1) A comparison of the Database properties where the numbers match up; you can see how the merged citations in 10 “expanded” to many citations in 7. (2) Burial fact in the fact list showing my customizations in 10 that I had to re-edit in 7. (3) Burial fact in my person’s edit screen in 7 before I made those fact list changes. (4) … and after I made those changes. Specifically in this example where RM’s Use of the Burial fact does not include Description by default, that data did not get lost; it “re-appeared” when I edited the fact list.
I don’t use shared facts or roles, so I only have a few “Principle” fact sentence templates that I’ve customized. Otherwise it might be a bigger task.
I hope you aren’t laughing at this too hard at this point. But maybe it would be helpful with that reunion coming up.
What you have discovered is a well known phenomenon for experienced RM users. Namely, GEDCOM transfer of data between RM and RM can be a very lossy operation, even when the Extra details (RM specific) option is included. And RM’s Drag and Drop method for copying data within the same version of RM historically has used GEDCOM as its data transport mechanism. So Drag and Drop historically has also been a very lossy operation. Here is a link to a page which discusses those losses.
The most current version of RM uses a direct database to database copy for drag and drop rather than using GEDCOM. The best I can tell, the data losses have been much reduced with the direct copy, but I do know that the direct drag and drop still has the problem of not retaining record numbers for each person. And there still may be other data losses with the new drag and drop. It has not yet been analyzed as thoroughly as was the old drag and drop. Of course, you are going from RM10 to RM7, so your issue is data losses with GEDCOM and not data losses with drag and drop. There is no drag and drop between RM10 and RM7.
The last complete rewrite of RM was going from RM3 to RM4. I converted from RM3 to RM4 fairly quickly and easily, only to discover several months later that I was unable to create the printed report I needed for a family reunion. I tried reverting from RM4 to RM3 using GEDCOM, but the data losses were too great. I finally was able to create the report I needed using RM4, but not without a great deal of effort and stress. The stress was because I had a hard deadline of the family reunion event. So I promised myself never again to rush into a new version of RM after a complete rewrite.
I therefore was very slow to convert to RM8/9/10. I never converted to RM8. I converted to RM9 in June of 2023. But I converted only after writing a rather massive SQLite script that compared an RM7 database to an RM9 database at a very detailed level. And I also did a very thorough and successful test an SQLite script written by Tom Holden which reverted an RM9 database to RM7. Even after all that, I did complete double data entry into RM7 and RM9 and ultimately unto RM7 and RM10 all the way up until July of 2024. I used my massive compare script to be sure my double data entry into RM7 and into RM9 wa accurate.
At that point, the double data entry just became unbearable and I quit doing the double data entry. Also, I had succeeded in running the narrative report I needed for a family reunion using RM10. I had found my workaround for the vertical white space problem, and I had failed to notice the italics problem. So I was thinking I was all ready to go. But the italics problem has me worried. My next step is going to be to try Tom’s script for reverting RM9 to RM7 to see how well it works reverting RM10 to RM7. There’s a lot of stuff that can’t be reverted because there are so many new features in RM10 that were not there in RM7. But I don’t need those features reverted just to be able to run a report. RM10 will still be my production database.
We shall see what happens. I’m doubtful that the italics problem will be fixed in time for me to run my report in RM10. The reunion is in three weeks, and I need to take the report to the printer in two weeks. If I can’t get the reversion script to work between RM10 and RM7, I will have to run the report without italics using RM10.
