Family Historian User Group

I haven't tried this yet, but it might be of interest? It can now import from a Gedcom file.

http://parallax-viewpoint.blogspot.com/ ... r-v50.html

Helen

I wrote a Gedcom converter for an earlier version of Tony's programme some while ago and posted the information in Tree display html / website (15528). My converter is still valid as it does the conversion differently. Tony's programme is good for including trees in blog posts etc.

This is an example of a tree created with Tony's programme It can save a tree as HTML or SVG and depending on which option is chosen displays additional information when a person is hovered over or clicked on.

Colin, yes, I saw you're earlier post, but I thought it worth bringing attention to Tony's improvements as well.

Since it is now free to download without an invitation, I've added fhugdownloads:contents:utility_svg_family-tree_generator|> Utility ~ SVG Family-Tree Generator.

If that needs any refinement then please update that page or let me know.

I have added an additional sentence to the description on the knowledgebase.

tatewise wrote:Since it is now free to download without an invitation, I've added fhugdownloads:contents:utility_svg_family-tree_generator|> Utility ~ SVG Family-Tree Generator.

If that needs any refinement then please update that page or let me know.

Thanks for that Mike. However, the quoted link to my blog is a general one, that will move over time, rather than one pointing to a specific article. Any chance you could change it to:

http://parallax-viewpoint.blogspot.com/ ... r-v50.html

I have changed the link in the Knowledgebase.

@Tony Proctor:
I did think of using that specific article URL, but was concerned that it would miss any later blogs for SVG Family-Tree Generator.
What will happen to the current URL http://parallax-viewpoint.blogspot.com/ ... r-v50.html when you post a later update for this product?
Won't it be out of date?

The article would still be valid, and it points to the previous, more generic, articles. I don't use my blog much any more so I wouldn't hold your breath for an update. Better to visit the facebook group of the same name.

Tony

Sorry Tony, I could not find a suitable Facebook page - please give us a clue or URL.

BTW: If you don't use the blog much, why is http://parallax-viewpoint.blogspot.com/ unsuitable?

It's a facebook group rather than a page, Mike. Its name is also "SVG Family-Tree generator" and its location is https://www.facebook.com/groups/1740301252946074/. There is a good range of videos on there (unfortunately with me narrating) that try to take people through the various features.

Re: Blog, it's always best to cite a specific article rather than the general blog, even if it happens to be the last article (currently). Who knows what the future holds...

Thanks again. I know this is really a FH group but if you can think of a useful way of working with FH then I'm happy to consider it

...actually, one of my missing features is the importing of image-file references to use in the person boxes. The main reason for the omission is that the 5.5 and 5.5.1 GEDCOM structures are different, and some programs (such as FH) use custom tags.

The way my code handles images, though, means that it can support both local and remote ones together, with a single reference. Anyone interested in some collaboration?

There needs to be a clearer understanding of exactly what Media structures are under consideration.
Are both linked Media records and local Media objects to be supported?
See GEDCOM 5.5 Pages 26 & 33 and GEDCOM 5.5.1 pages 26 & 37.
In linked Media records, no products use the BLOB tag these days, and substitute a FILE tag instead.

So the only significant difference is that FORM and sometimes TITL are subsidiary to FILE, and that FILE may have multiple instances in GEDCOM 5.5.1.

The FH Export GEDCOM File command and Export Gedcom File Plugin can both use FILE rather than _FILE.
See glossary:gedcom_extension_list#multimedianote_file_date_keys|> Multimedia: _NOTE, _FILE, _DATE, _KEYS.
Also the Export Gedcom File Plugin can be customised to only use local Media objects that always have a level 1 TITL.

So the question is which of the GEDCOM Media tags are you planning to support?

If only the FILE tag is to be supported then both GEDCOM 5.5 and GEDCOM 5.5.1 can easily be accommodated.
If the FORM and TITL tags are also to be supported then they must allowed at two levels.

Supporting both the FILE and _FILE tags is not a problem, Mike. However, the fact that there may be multiple media files is a problem. Even eliminating all but "photo" could still yield more than one file-reference, so which do I put in the box. I guess I'm looking for some examples and practical guidance as to what people would like to see.

Multiple Media files can arise multiple ways.
Yes, in GEDCOM 5.5.1 any Media object/record may have multiple FILE tags, but I've never seen that used.
BUT any Individual record may have multiple Media objects/records in both GEDCOM 5.5 and GEDCOM 5.5.1.

Thus some genealogy products use a _PRIM Y custom tag to identify the 'primary' one, but the rest just use the first instance that is a graphical image file such as JPEG, PNG, etc. That then determines the image you should put in the box.

A further complication is that GEDCOM produced by online tress from such as Ancestry and FindMyPast put a URL in the FILE tag instead of a PC file path reference.

FH and some others, have custom tags that identify a part frame within the FILE image to pickout say the head & shoulders of one person from a group photo. The Export Gedcom File Plugin resolves that problem for FH by supplying cropped images for each of those cases.

Thanks for the detailed reply, Mike. If anyone wants to email me an example then I'll work on a prototype

Tony

There are three attached GEDCOM files derived from the Family Historian Sample Project but adapted to include most data structures, so that I can test migration to other products, and thus should be ideal for your purposes.

Test Export Gedcom File Command.ged was produced by using the File > Import/Export > Export > GEDCOM File command with the Destination set to Family Tree Maker that ensures Media records use the FILE tag. It employs both local Media objects and linked Media records. Most FH custom tags are retained.

Test Export Gedcom File Sdr UTF8.ged was produced by using Tools > Plugins > Export Gedcom File with the (Sdr) Standard GEDCOM Draft 5.5.1 export mode and (PART~LMO) Part Frames via Local Media Objects media conversion. Thus only local Media objects are employed and all custom tags are converted to standard tags.

Test Export Gedcom File RMT UTF8.ged was produced by using Tools > Plugins > Export Gedcom File with the (RMT) Roots Magic Tree export mode and (PART~LMO) Part Frames via Local Media Objects media conversion very similar to above, but includes the _PRIM Y tag for each primary Media object.

You could create your own family trees in Ancestry or FindMyPast and export GEDCOM files to get examples.
No subscription is needed, just set up a free account.

Thanks Mike. The mechanics of finding the file-references, and the variation in structures, is the easy bit (level numbers don't matter to me as my loader builds a hierarchical object model from the file) -- the harder bit is generating usable thumbnail image references for the SVG/HTML output. FH uses local file references, but the browser really wants remote ones (at least if you going to share it). Obviously my dual-reference notation will help since a single reference can then expand to either a local file (for when editing the tree) or a remote file (for the browser). When the FH file references are relative (e.g. Media\Census\Image.jpg) then it easy to add a root prefix (e.g. $ROOT:Media\Census\Image.jpg), but some of the references are absolute.

Those files appear to have "lineage loops" in them, Mike, and they fail to export the content as *.txt files for SVG.EXE.

As far as I can see, there are linked marriages: F7=I17+I24, F33=I24+I13, and F6=I13+I16. However, a child of F6 is I17. Can you check this out?

Tony

I guess by local file references you mean PC file paths, and by remote ones you mean webspace URL.

Most products are PC based and they all use local PC file paths for Media. What else could they use?

The FH relative file references (e.g. Media\Census\Image.jpg) are something of a red herring. Anyway, although advisable, there is no guarantee that FH users will use relative file references, and most products don't even offer that option.

SVG Family-Tree Generator will only need a tiny subset of the Media files, i.e. one per Individual box.
So I suggest it copies those few image files to the same folder as the SVG/HTML scripts.
Then the SVG/HTML scripts can use relative URL such as <img src="image.jpg"/> throughout.

I am investigating the the "lineage loops".

Although somewhat unusual that "lineage loop" is perfectly feasible.

I13 may have died in say 1970 and his son I17 had an ongoing affair with his father's widow I24 (who is not I17's birth mother).
That ongoing affair resulted in illegitimate children I18 and I19.
The son I17 also married I72 with child I68 and adopted his illegitimate child I19.

I19 has two sets of parents, but that is quite common in user trees with fostering/adoption.

That kind of loop arises quite often where relatives have certain relationships.
FH copes in diagrams by displaying two boxes for the one individual in two relationships, optionally linked by a ribbon.

I know it's feasible, Mike, but sufficiently rare that I decided to trap on it. It was worth checking ...

tatewise wrote:There are three attached GEDCOM files derived from the Family Historian Sample Project but adapted to include most data structures, so that I can test migration to other products, and thus should be ideal for your purposes.

I've written and tested the code to import thumbnails, Mike, but the general interest seemed to be low (elsewhere) so I haven't rushed it out. It should cope with 5.5 and 5.5.1 (but not BLOBs), and several custom tags (incl. FH ones). It even makes sense of Ancestry's utterly useless URL image references in their GEDCOM export.

I may hang on to it for a while longer in case I think of some newer features.

No rush.
BLOBs are never used these days, so no problem there.
I thought the Ancestry URL worked as one would expect providing the original online tree is Public &/or you are signed-in to an Ancestry account that is granted access. So, if it is the user's own tree and they are signed-in, then the URL should work and thumbnails should be feasible. However, it is possible I am mistaken, but certain that some online trees work that way.

tatewise wrote: I thought the Ancestry URL worked as one would expect providing the original online tree is Public &/or you are signed-in to an Ancestry account that is granted access. So, if it is the user's own tree and they are signed-in, then the URL should work and thumbnails should be feasible. However, it is possible I am mistaken, but certain that some online trees work that way.

No their URLs do not take you directly to the image file. It's bizarre! It's possible to massage them to generate a usable image reference, though, and I've seen others doing the same thing (e.g. for custom tree-printing tools).

I even added an option to automatically download local copies so that they all appear in the Tree Designer. It made it very slick!