Jump to content


Member Since 26 Apr 2008
Offline Last Active Today, 04:43 PM

Topics I've Started

Tip: Posting images from Google Photos

26 August 2018 - 01:38 PM

I use Google Photos and Google Drive extensively but could never post an image from them to this forum until I discovered the trick that let me post this little one from Google Drive. It's a PNG file so I added that extension instead of JPG as in the example.
Photos Resources‎ > ‎Photos & Picasa FAQ‎ > ‎Google Photos‎ > ‎How to . . .‎ > ‎

How to get a direct link to an image (of a specific size)

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?