* Export Gedcom Plugin - Rich Text Formatting conversion issue

[jbtapscott]

I've always used the Export Gedcom plugin for generating a Gedcom file for use by GedSite when creating my website.

Having upgraded both AS and FH to the latest versions and experimented with some of the basic RTF stuff (basically, text colours at this stage), I find that that the RTF conversion option on the plugin is not converting all text formatting in the Text from Source field on a Source record when I use the HTML5 option. By way of example, the FH file shows:

0 @S4923@ SOUR
1 TITL SMALL, Mary Ann - 1827 Baptism record
1 _TYPE Baptism (Parish Register Transcript)
1 PUBL Somerset Baptism Index D/P/HAM H 2/1/4
1 TEXT <clr="00007F"><b><fs="+1">Baptism</clr></b></fs>
2 CONT <clr="00007F">Reference: <clr="000000">Somerset Baptism Index D/P/HAM H 2/1/4</clr>
2 CONT <clr="00007F">Date: <clr="000000">17 Sep 1827</clr>

which gets converted to:

@S4923@ SOUR
1 TITL SMALL, Mary Ann - 1827 Baptism record
1 _TYPE Baptism (Parish Register Transcript)
1 PUBL Somerset Baptism Index D/P/HAM H 2/1/4
1 TEXT <div style="color:#00007F;"><b><div style="font-size:11pt;">Baptism</div></b></div>
2 CONT <div style="color:#00007F;">Reference: <clr="000000">Somerset Baptism Index D/P/HAM H 2/1/4</div>
2 CONT <div style="color:#00007F;">Date: <clr="000000">17 Sep 1827</div>

In essence, the second "clr=" is not being converted to HTML5 in the Gedcom for GedSite.

[tatewise]

Thank you for that feedback Brent and Happy New Year.

In the same way that every <b> has a matching </b> and every <fs=...> has a matching </fs> my plugin expects every <clr=...> to have a matching </clr> code, but in those lines they are not in matched pairs.
I don't know if that is allowed in rich text FTF format or whether FH has made a mistake.

Anyway, the code <clr="000000"> means black and the code </clr> means black, so as a workaround it should be possible to reformat those two lines as follows:
2 CONT <clr="00007F">Reference: </clr>Somerset Baptism Index D/P/HAM H 2/1/4
2 CONT <clr="00007F">Date: </clr>17 Sep 1827
i.e. Cancel all the current colours, then select just the label prefix and select blue.

Furthermore, John Cardinal at GedSite always insists that unadulterated FH GEDCOM format should be used.
I believe I discussed this rich text FTF scenario with him and he was not keen on the HTML 5 option.
That is why the default GedSite setting in my plugin is to (RETAIN) Retain rich text in FH format.
So, please contact John to see what he suggests.

[jbtapscott]

Thanks Mike, and a Happy New Year too!.

I should have made clear in the original message - this formatting came in from an AS AutoText RTF template. I will though have a play around in FH with a "clean" source record to see what FH records for this sort of text.

I did raise the issue with John C before raising it here as I was unsure what GedSite could / could not handle in terms of formatting codes so didn't really know where the problem lay. He commented:

"GedSite "passes through" most HTML tags that are present in notes and other text fields. Many of the formatting codes used in FH7 are HTML and so those work as expected. I am not sure what you specified in FH7 exactly, but the GEDCOM records indicate two different ways of specifying color, one that is HTML-compatible and one that is not:

<div style="color:#00FF00;">Reference: <clr="000000">Somerset Baptism Index C/P/HAM H 2/1/4</div>

The bold text above is not HTML. "clr" is not a valid HTML tag, and HTML tags don't have values assigned with an equal sign. The DIV tag is valid. It has attributes that can be assigned values, and the DIV has a style attribute that is used to set the color. That's how FH7 creates the "lurid green" you described. Because GedSite doesn't know what to do with "<clr="000000">", and the browser doesn't know what to do with it, it gets ignored by both.

It's too bad that FH7 didn't use HTML for more of its formatting codes.
I am planning to add support for the FH7 formatting codes, including CLR, but that isn't available yet..."

[NickWalker]

In the same way that every <b> has a matching </b> and every <fs=...> has a matching </fs> my plugin expects every <clr=...> to have a matching </clr> code, but in those lines they are not in matched pairs.
I don't know if that is allowed in rich text FTF format or whether FH has made a mistake.

The FTF format is certainly not HTML (although borrows some of its tags) - it is really a specially coded version of RTF. It doesn't require tags for colour to be paired up. </clr> just means 'revert to the default text colour (black)'. Similarly for fonts </font> means revert to the default font. So it is perfectly legitimate to change colour (or font) without first reverting back to the default colour (or font). This is an example of a note created in FH7:

Code: Select all

1 NOTE This is <clr="FF0000">red <clr="0000FF">blue <clr="008000">green <clr="FFFF00">yellow </clr>and back to normal

[tatewise]

Thank you Nick. I have just run some experiments that confirm what you say.
Unfortunately, the FH documentation on FTF is not very clear on that point and I assumed matched pairs of tags like HTML.
I have tried in vain to find some online FTF documentation but everything I found looks nothing like the FH formats.
I will have to revise the Export Gedcom File conversion algorithms for HTML. Drat

John's comment that "It's too bad that FH7 didn't use HTML for more of its formatting codes." is misplaced as it is just coincidental that a few of the FTF codes are the same as HTML.

[NickWalker]

The page I used for this (I spent a frustrating couple of months or more fighting with the RTF side of AS) is in the help guide for plugins (Family Historian Plugin Help) on the FTF Syntax page.

[tatewise]

Yes, that is the Help page I am talking about, but all its examples illustrate everything in matched pairs just like HTML.

[tatewise]

There is an updated Export Gedcom File V4.1.2 (18578) with revised rich text to HTML 5 conversion to try.