Family Historian User Group

This is an observation/fix on Report output to rtf files for monospaced fonts in tables not vertically aligned.

I still use a monospaced font for Report tabulated output, e.g. Census. However, I noticed that when a *.rtf Report file is viewed/edited in various editors (e.g. MS Word 365 and LibreOffice), in certain situations within a table, monospaced font data (e.g. Consolas) does not line up correctly vertically e.g.

(but the longer the line the worse it can get)

It seems that spaces are compressed to "make it fit better", which rather defeats the object of using a monospaced font!

This only happens in Print Layout and in and if printed. It displays fine in Draft or Web Layouts. FH PDF output is fine.

I tried many settings options but this is the only way I can find to make it work for MS Word 365.

- Do this only if you wish to copy headers/footers too > create a Break point (e.g new page) at the end of your document
- Copy all data you want (include the last break point if you want header/footers)
- Open a New blank document
- paste
- save. I have tested docx and a new rtf, and both work fine.

If you then view alt+F > options > advanced > Compatibility for each file. The original rtf file has many items under Compatibility Options, the copy/paste docx version has no compatibility options. The new rtf version has far fewer compatibility options. I tried cloning the same options to the original rtf file, but still no vertical alignment.

This option also worked, but not sure how compatible it would be elsewhere, it did not work well in Libre Office.
- save the *.rtf file as *.odt file, it then displays correctly.

So it looks like FH is passing some settings to the rtf file that cause this problem.

If anyone knows of another fix so that the original *.rtf monospaced table data does not compress spaces, info would be gratefully received.

I confirm that I can reproduce that effect but have no general solution.

It seems that Word auto-shrinks the font when the line is too long instead of wrapping the last word onto the next line, which upsets the monospacing you require.
If you manually insert a line break or adjust some other settings such as margins or point size or table column width so that those long lines do not reach the right margin then the monospacing is OK.

What would you expect Word to do with a long line like that?
If it automatically wraps then that might be even more disruptive to your neat tabulated layout, which is what happens in PDF output.

tatewise wrote: ↑

02 Nov 2022 22:25

What would you expect Word to do with a long line like that?

My point is that it is only the rtf output from FH that creates the problem, if it is copy/pasted into a new document, it does the alternative as you suggest, continues on the next line. and correctly aligned.

I do not understand why FH output does one thing, while a new "raw" document does another. It would be nice to be able to choose/amend.

I reported this to Family Historian support
"rtf report monospaced fonts in tables not aligned #908527"
who took more of an interest in it than I thought they would. After some tos and fros they "consider" it is a problem with MSWord or Libre Office. Despite that a RAW newly created Word document (docx or rtf) with the same data does not cause the problem, yet the rtf from FH does!

Should anyone be interested, I have created a cut down version of my output showing the problem in the Source Record 1 is from FH, 2&3 copied into a New RTF/DOCX document via MSWord. Of interest is the much smaller file size of the FH rtf output.
- DO NOT FORGET TO VIEW IN PAGE MODE, also ensure A4 landscape, as in other display modes it aligns correctly.
If anyone can adjust any settings to fix the FH rtf, or show where the difference is I would be interested to know, I have checked many things.

In the meantime should anyone want a workaround:

- Open the FH output rtf file in MSWord
- Copy all the data you want (e.g. Ctrl+A) (if you want header/footers, first create a break point, say new page, at the end of the document)
- Open a New blank document
- paste (depending on your default styles etc, some aspects like font spacing, indents might be different)
- save. I have tested save as docx and a new rtf, and both work fine.