* Export Gedcom File V4.1.2

[tatewise]

Please find attached Export Gedcom File plugin Version 4.1.2 Date 01 Jan 2021 in a compressed ZIP file.
Use right-click Extract All... to unpack to its .fh_lua file.
[ EDIT: Attachment deleted and replaced by later Attachment ]

It has a variety of updates from the Plugin Store V4.1 covering rich text FTF to HTML corrections, handling accented characters in file paths, removing Sorts Dates from FTM exports, reformatting of Templated Source Title & Short Title, Project only Fact Sets, memory garbage collection, etc.

This posting is referenced from several other threads that reported issues which are hopefully fixed in this version.

If no significant negative feedback arises then I hope to publish this version next week, when Calico Pie should be back from holiday, and finish updating the associated Help pages.

[victor]

I export Gedcom file to FTM 2019 from time to time. I work on FH which is my default tree.
Once I have exported the file I synchronise it to Ancestry which leads me to more information on any particularly names. It also gives me links to Family Search for the names.
As to sort I have not bothered with that as more interested in what appears on Ancestry and Family Search.

Victor

[tatewise]

Victor, you may find the FH -> RootsMagic -> Ancestry (Work-in-Progress) (18572) thread of interest.

[jbtapscott]

Thanks Mike - I have given this a quick try this morning. Initial Gedcom segment was:

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 <div style="color:#00007F;"><b><div style="font-size:11pt;">Baptism</clr></b></div>
2 CONT </div><div style="color:#00007F;">Reference: <div style="color:#000000;">Somerset Baptism Index D/P/HAM H 2/1/4</clr>
2 CONT </div></div><div style="color:#00007F;">Date: <div style="color:#000000;">17 Sep 1827</div>
2 CONT </div><div style="color:#00007F;">Address: <div style="color:#000000;">St Andrews Church</clr>
2 CONT </div></div><div style="color:#00007F;">Place: <div style="color:#000000;">High Ham, Somerset, England</div>
2 CONT </div><div style="color:#00007F;">Name: <div style="color:#000000;">Mary Ann Small</clr>

I have attached sample from my GedSite generated website as a straight cut/paste here looses the colour.

S4923 Screenshot 1.jpg (27.01 KiB) Viewed 7208 times

A couple of observations:

• I don't know if it has any relevance, but I noticed that each row in the Gedcom ends alternatively with </div> and </clr>

• The output on my website now has a new line for each colour (viz. the text after the colon is not on the same line as the text before), whereas the output from the original export had it all on one line albeit with the same colour text.

I will pass this observation on to John C and will also carry out some more testing including selecting the RTF: Retain option in the plugin

[tatewise]

Thank you for that feedback. It seems the plugin is still not handling the </clr> tag correctly.
It is probably those invalid HTML tags that are upsetting the GedSite layout.
Let me investigate.

[ronk]

Mike,

Just to let you know that V4.1.2 fixed something in the export to TNG which I had not got around to reporting. In TNG, a Notes with "2 CONT Cited Source: [nn]" above has been properly replaced by a [nn] inline to the footnoted source.

Externally, the only noticeable change is the "preparing dialogue" for the plugin dialogue takes a bit longer before the settings prompt appears.

Thanks,

Ron

[tatewise]

Thank you, Ron, yes that was another pending fix for TNG.

Brent, try the attached Export Gedcom File plugin Version 4.1.3 Date 02 Jan 2021 in a compressed ZIP file.
Use right-click Extract All... to unpack to its .fh_lua file.
[ EDIT: Attachment deleted and replaced by later Attachment ]

That should handle the FTF better, although I can think of cases that may not get the style completely correct.
The snag is that FTF does not follow the nested structure rule like HTML.
e.g.
<clr="00007F"><fs="+1">Baptism</clr> Register</fs> is valid FTF giving Baptism Register
<div style="color:#00007F;"><div style="font-size:11pt;">Baptism</div> Register</div> HTML gives Baptism Register
i.e. The first </div> terminates the font size and the colour continues to the second </div>
So the order of the color and font-size tags need reversing, but not easy to detect and achieve in plugin script.

[jbtapscott]

Thanks Mike. This change gave me the following in the Gedcom:

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 <div style="color:#00007F;"><b><div style="font-size:11pt;">Baptism</div></b></div>
2 CONT <div style="color:#00007F;">Reference: </div><div style="color:#000000;">Somerset Baptism Index D/P/HAM H 2/1/4</div>
2 CONT <div style="color:#00007F;">Date: </div><div style="color:#000000;">17 Sep 1827</div>
2 CONT <div style="color:#00007F;">Address: </div><div style="color:#000000;">St Andrews Church</div>
2 CONT <div style="color:#00007F;">Place: </div><div style="color:#000000;">High Ham, Somerset, England</div>
2 CONT <div style="color:#00007F;">Name: </div><div style="color:#000000;">Mary Ann Small</div>

But the output (after Gedsite processing), still gives the two line output:

S4923 Screenshot 2.jpg (28.35 KiB) Viewed 7145 times

Having read up a little via Google, I assume the linebreak after the colon is the result of using the <div statement as that seems to auto include a linebreak!

[PeterR]

Might <span …> work better than <div …>, or is that not an option?

[tatewise]

Sorry, thank you Peter, I now realise I should have been using span instead of div all along

Try the attached Export Gedcom File plugin Version 4.1.4 Date 02 Jan 2021 in a compressed ZIP file.
Use right-click Extract All... to unpack to its .fh_lua file.
[ EDIT: Deleted as now in Plugin Store. ]

However, this will still suffer the problem posted earlier:
<clr="00007F"><fs="+1">Baptism</clr> Register</fs> is valid FTF giving Baptism Register
<span style="color:#00007F;"><span style="font-size:11pt;">Baptism</span> Register</span> gives Baptism Register
i.e. The first </span> terminates the font size, and the colour continues to the second </span>
So the order of the color and font-size tags need reversing, but not easy to detect and achieve in plugin script.

[jbtapscott]

Thanks Mike - output to Gedcom is now showing:

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 <span style="color:#00007F;"><b><span style="font-size:11pt;">Baptism</span></b></span>
2 CONT <span style="color:#00007F;">Reference: </span><span style="color:#000000;">Somerset Baptism Index D/P/HAM H 2/1/4</span>
2 CONT <span style="color:#00007F;">Date: </span><span style="color:#000000;">17 Sep 1827</span>
2 CONT <span style="color:#00007F;">Address: </span><span style="color:#000000;">St Andrews Church</span>
2 CONT <span style="color:#00007F;">Place: </span><span style="color:#000000;">High Ham, Somerset, England</span>
2 CONT <span style="color:#00007F;">Name: </span><span style="color:#000000;">Mary Ann Small</span>

The website now shows:

S4923 Screenshot 3.jpg (44 KiB) Viewed 7098 times

Although the <span makes a difference, there is no linefeed (which the <div automatically gave) so we now have one long line!.

[tatewise]

I have tested all the other products that accept HTML 5 format and they all display the lines as expected.
(FindMyPast, MyHeritage Family Tree Builder, RootsFinder, TribalPages, ZoomPast)
So GedSite is the only product that behaves differently.
I have been in contact with John Cardinal who would like to handle the FH rich text FTF format directly and is the default.
So I am not keen to spend much more time on this particular scenario. Sorry.

[jbtapscott]

Thanks Mike - I'm okay with leaving it to John C

[tatewise]

Brent, I found time for a quick experiment or two.
I tried surrounding each line with <div>... </div> and also ending each line with <br>
e.g.
2 CONT <div> ... </div>
2 CONT <div> ... </div>
or
2 CONT ... <br>
2 CONT ... <br>

In two products I tested, that resulted in all notes being double spaced, so not a solution for them.

[ronk]

Mike,

Has anyone reported on the FH7 Export to Gedcom (plugin) to Legacy Family Tree yet? I had a somewhat successful export with Export Gedcom File V4.1.3 to LFT Statistics of individuals, family and media look OK, but sources and citations have jumped far too much, by a factor of nearly 10 times. Also, the LFT database size increased by 25% which I suspect is related. Would the plugin settings have been picked up from FH 6.2,? Regrettably, I no longer have an FH 6, but shall check if I've saved snapshots somewhere of the FH6 plugin Export to Gedcom to LFT settings.

Edit Update:
Looking further, It appears all Place records are being counted as Sources after import into LFT, nearly 3000 of them. They are getting a prefix of 'ZZ'. I will examine the gedcom a bit more, as well as LFT's import settings.

Ron

[tatewise]

Ron, I don't think there are significant changes to (LFT) Legacy features between plugin V3.9 and V4.1.3.
I still have FH V6 and can run old versions of plugins.

I have exported my test project to Legacy which is very similar on both FH V6 and FH V7.
1) Using FH V6 and Plugin V3.9
2) Using FH V7 and Plugin V4.1.3
The Legacy File > File Properties are remarkably similar and certainly no factors of 10 times.
Where are you obtaining your sources and citations statistics?
If you use View > Master List > Source does anything look unusual?
Are there a lot of entries starting with ZZ with Place names in the title?

[ronk]

Statistics are from LFT. I should have less than 100 sources.

Yes, in LFT's source list, as well as directly in the gedcom, the 'ZZ' records appear.
0 @S140@ SOUR
1 ABBR ZZ Place Record: Ramsey Co, MN
1 MEDI Place Details
1 AUTH Place Rec Id [P76]
1 TEXT Map Plot:
2 CONT Latitude: N44.9963986
2 CONT Longitude: W93.0615978
0 @S141@ SOUR
1 ABBR ZZ Place Record: Marathon Co, WI
1 MEDI Place Details
1 AUTH Place Rec Id [P78]
1 TEXT Map Plot:
2 CONT Latitude: N44.850452
2 CONT Longitude: W89.8505012

I will need to check my plugin settings for Export to LFT, since LFT didn't create the 'ZZ' place records and list them as sources.

[ronk]

I think this setting is causing the issue with source creation:

lft setting.jpg (20.99 KiB) Viewed 6930 times

No idea why it is set that way, or what is should be for LFT.

Ron

[tatewise]

OK, on the plugin Extra Options tab, assuming you used default settings before, click the Reset these LFT+ Options button and check the Place Record 0 @P%d+@: setting is Gedcom 5.5.1 Lat/Long as I suspect Put in Source Rec Abbr is false inherited setting from FH V6.

The major changes in FH V7 may mean a similar tactic of resetting options for other target products may be needed if migrating from FH V6 as the inherited Plugin settings may not be ideal. It is advice I intend to add the Help pages soon.

[ronk]

Yes, resetting the options does change it to what you noted, but back on the basic options, 'brief' is indicated rather than 'full', changing it to 'full' reverts those settings so the place setting is the to put in source again. Could that have caused the issue for me? I had thought I always did a 'full' export, but now I am not so sure.

Update: well it did the first time, I thought, but switching between 'full' and 'brief' didn't change the Extra Options the second time. Now I am confused.

[ronk]

I may have to do an 'image' restore off my second laptop to recover my FH6 environment and see what settings I had. I jumped to FH7 on both laptops forgetting about LegacyFamilyTree. That might be useful anyway, to have FH6 in the wings on my secondary 'test' laptop. This 2 laptop situation is why I lamented early on that the old version can't be kept somewhere on the same laptop with new one, notwithstanding the fact that FH's folder structure is much more complicated than LFT.

[tatewise]

The (+) Full Data and (-) Brief Data options for each GEDCOM Export Mode save independent 'sticky' settings for each of the Main/Extra/Other Options tabs.

So whatever you set on those tabs only applies to one specific export mode.
That is why the buttons are labelled Reset these LFT+ Options and Reset these LFT- Options respectively.

The (-) Brief Data mode will typically set some Extra Options to Remove unimportant data like Named Lists.

The Help has always said: "These settings are remembered independently for the (+) Full Data and (-) Brief Data option of each GEDCOM Export Mode."

[ronk]

Using 'Brief' (I suspect that's what I had in FH6.2), and the reset LFT options, the sources now look correct in LFT. Only errors on input to Legacy were 800 of these:

Main Record: 0 @I2273@ INDI
Sub Section: 1 EVEN
* Unrecog. Line for an Individual Record: 3 MAP

Some also for FAM records.

May still pursue the restoration of FH6 to clean this up.

[tatewise]

Which version of Legacy are you using? I have Standard Edition 9.0.0.368

Those are Place field MAP ~ LAT/LONG geocode data supported by the latest Legacy versions which is why the plugin option is new, unless there is a special case for custom EVEN facts. If the MAP field is conditional on the type of fact then my Plugin will need revising.

If you don't want that then change the Place Record 0 @P%d+@: extra option to Remove entirely.

[ronk]

Ahh, that makes perfect sense. I am using LFT 7.5 primarily, but also have the latest LFT 9 as well. Purchased when it was released. I haven't switched to V9 because I don't particularly like the new look, and it runs slower than LFT 7.5, and of course, much slower than FH 7. I have been playing with it periodically to see if speed improves. It's a bit sluggish when displaying photos with the pedigree/descendant charts. Of course, have been spoiled, only a few seconds between fast and slow

I will omit the Place Record 0 @P%d+@ setting for the old LFT as you indicate, and report back.