Jump to content


Photo

TreeShare, Event Notes, Paragraphing - HTML

TreeShare Notes HTML

  • Please log in to reply
2 replies to this topic

#1 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5876 posts

Posted 07 May 2018 - 12:58 PM

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

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></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>

   ... 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.


Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#2 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 7956 posts

Posted 08 May 2018 - 09:37 AM

Confirming this is on the development list. 


Renee
RootsMagic

#3 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3088 posts

Posted 08 May 2018 - 07:23 PM

Tom's observations are much more complete and are a better idea than my previous suggestion of using something like {CR} on the ancestry side to represent carriage returns on the RM side. In any case, some of these kinds of problems between RM and ancestry are solvable in RM despite the differences in the data models between the two systems and despite the limitations in the ancestry API. Other kinds of problems such as the difference in the handling of Names will require changes to RM's data model.

 

I have done some things similar to Tom's HTML in RM's fact notes to create useful effects when RM data is placed onto a Web site. In this environment, HTML from an RM note sort of "just works" on a Web site. Sadly, the same things do not work when used with RM's reports. For example, I would practically kill sometimes to be able to put a table into one of RM's notes and have it show up correctly in RM's reports as Tom did to have the table show up correctly on ancestry.

 

Jerry