Jump to content


Member Since 26 Apr 2008
Offline Last Active Today, 07:45 AM

Topics I've Started

TreeShare, Event Notes, Paragraphing - HTML

07 May 2018 - 12:58 PM

Take a look at this Occupation Note as displayed on Ancestry:

It has font styling (bold, italics, underline), new paragraphs, line breaks, a table AND an image. And it all came via TreeShare from the RootsMagic Occupation Note!


Cool!, you say. Too bad. It represents what could be and, at the very least, that TreeShare is NOT the problem in preserving paragraphing between the two ends. TreeShare happily passes HTML markup including the <p> new paragraph and <br> line break tags, along with a whole lot more. And the Ancestry Citation display happily renders them. The issue is that RootsMagic is not sending HTML markup in lieu of CR/LF control codes nor is it doing the reverse on receipt. It does for font markup!


It seems that RootsMagic uses or supports HTML for some things such as bold, italics and underline but not for most others, including paragraph and break. So blaming Ancestry or its API used by TreeShare for the loss of formatting is misplaced. While it would be a big deal to transform RM's editors and all its outputs to fully support HTML, it is no big deal to swap HTML tags for the current paragraph and line break control codes in a TreeShare transmission, reciprocally. If the API cannot support the control codes, then that swapping has to be done by RootsMagic.


I find it hard to believe that this has not been identified as the solution for this issue at the earliest detection of the problem. RM developers know what's in the API and what's in the application. We users are like the proverbial blind prophets describing the elephant.


Now here's what the RM Note Editor looks like for the content seen on Ancestry:



Now is the time for some good men to come to the aid of the party.

<p>{CR}<img src="https://s6.postimg.c...gic-square.png"

alt="" style="width: 90px; height: 90px;"></p>
<p>The quick brown ox<br>
jumped over the </p>
<p>lazy dog.</p>
<table border="3">
<td>Cell 1</td>
<td style="background-color: #66ffff;">Cell 2</td>
<td>Cell 3</td>
<td>Cell 4</td>

   ... and here's what comes back via TreeShare:



Now is the time for some good men to come to the aid of the party. <p>{CR}<img src="https://s6.postimg.c...gic-square.png"alt="" style="width: 90px; height: 90px;"></p> <p>The quick brown ox<br> jumped over the </p> <p></p> <p>lazy dog.</p> <p></p> <table border="3"> <tbody> <tr> <td>Cell 1</td> <td style="background-color: #66ffff;">Cell 2</td> </tr> <tr> <td>Cell 3</td> <td>Cell 4</td> </tr> </tbody> </table>

...stripped of the linefeeds but the HTML paragraph and break tags are intact. A regular expression search and replace on receipt could readily convert them to RM's control codes.


The image is on an online image host because neither editor supports the embedding of image files in a Note but it is possible that they could be so developed.


I initially hand-coded the little table but when it came time to try an image, I copied the content from the RM note editor over to the (free) BlueGriffon web page editor to add the image and colour a table cell. It's both a WYSIWYG and HTML code editor and easy to use. Then I copied what it had between the <body> and </body> tags back to the RM editor.

TreeShare Foibles - Family Facts, Inconsistencies, Phantoms et al

07 January 2018 - 11:00 AM

A discussion on FB has drawn me into the TreeShare spaghetti of issues. It started with the complaint about "Residence (fam)" fact label on an Ancestry Member Tree created by a TreeShare Upload being changed to "Residence (family)" when the fact was updated to AMT for a change that had been made in RM. TreeShare no longer matches these otherwise identical facts so the fact on one side has to be added to the other and the remaining unmatched one deleted. Adding to RM may result in a custom individual fact type with "(family)" in the name - a source of confusion. Re-adding to AMT means deleting the renamed fact separately from both spouses. It gets more complicated because the TS Update to AMT only changes the value for the fact for one spouse - why not both?


I've pulled on a few spaghetti strings and tried to document my findings for other users to learn from, analyse, contribute to... and for RM developers to focus some corrective effort. They are Google Slides slideshows:


1. TreeShare Foibles #1 Family Facts (A)

2. TreeShare Foibles #2 Family Facts ( B) 

3. TreeShare Foibles #3 - Fact Update Causes Mismatch


What little use I have made with TS has been for download so I had not noticed that a TS upload of a RM family-type fact produces a special fact on AMT. I understand that all AMT facts are supposed to be individual-type but uploads result in the other spouse's name being hyperlinked from the fact on the AMT Facts and Timeline pages of a person's Profile, just as is seen for (some) Marriage facts generated on the AMT from an Ancestry Source Hint. I haven't found a way to create such spousal hyperlinks through the AMT UI and, somehow, these cross-linked individual facts do get transformed through a download or a TS Add update from AMT to RM into RM family-type facts. So if TS Upload and Download can create these "family" versions on either side, why can't TS Update propagate changed values from one family fact in RM to both individual facts for the spouses on AMT and, likewise, in the opposite direction?

Compressed Pedigree Chart

07 November 2017 - 11:04 AM

I needed a compact 6-generation pedigree chart as an illustration for a 2-page report for my local Society on my ancestors living at the time of Canada's Confederation in 1867. I had done one using the RM Pedigree Report for another member but he had half as many ancestors to cover - I'll describe it separately because it, too, was a challenging, learning experience. For my report, I gave the RM Ancestor Wall Chart a try. Here's the result, tucked into the lower left of the page:
Here's a comparison of a compressed pedigree to the original generated by RM.
Had I used the original, I wouldn't have had enough space for text. The overall process involved editing in RM Wall Chart to mesh the columns for the first 3 generations into the fourth column, exporting a PNG, cropping with Paint.net along with deleting the white space outside the boxes (its selection wizard makes that a 2-click operation) and inserting the revised PNG into the Word doc.
Editing in Wall Chart is tricky, partly because the objects RM generates have dimensions and locations that don't correspond to the default grid or to any practical grid and there are hard-coded dimensions that a link can revert to when moved. Without snap-to-grid, multiple columns or a single column can be selected and dragged and the links stay rectilineal. But, ultimately, they start crossing through adjacent boxes and vertexes need to be moved. Moving a vertex may result in a segment on an angle. This can be very hard to correct. Working in 200% zoom to move a vertex lowers the risk. Dragging a segment regenerates the rectilineal polyline that goes where you do not want it but you can start afresh on it.
Working with snap-to-grid may actually compound things - I'm not sure. I set the grid spacing to 0.1", select and group a column of boxes and then adjust the right and left sides to snap points and then move it. Link lines may need to be tweaked as they do without snap. At times, I have resorted to deleting the link and creating a new one (the blue L control, not the black L in shapes).
RM color coding has no effect on the chart text, only on the box fill. I wanted the boxes white and the names of those not alive in 1867 subdued. That was easily accomplished on this small chart by selecting multiple boxes and then changing the font colour through Properties.
I found the Chart Help to be superficial and suspect there are features that are not even described. Nonetheless, if you need a one-off as I did for this report, you aren't completely at the mercy of the standard output.