* GEDCOM 7.0

The place to post news about genealogy products and services that might be of interest to other Family Historian users.
User avatar
ColeValleyGirl
Megastar
Posts: 2721
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: GEDCOM 7.0

Post by ColeValleyGirl » 26 Feb 2021 13:40

fhutils includes the capability (in setIUPDefaults) to set the plugin default font to match the Property Box Font (on the assumption that the user has set the Property Box Font to something they can read.

User avatar
tatewise
Megastar
Posts: 21304
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: GEDCOM 7.0

Post by tatewise » 26 Feb 2021 13:44

Internally within FH relative Rich Text values may have some merit, but not in the GEDCOM file without a default.
Yes, my plugin could lookup the default in the Windows Repository but that does not fix the FH GEDCOM file itself.

Helen, we are not talking about the Plugin IUP display font but the HTML/RTF font specified in the GEDCOM file.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
NickWalker
Megastar
Posts: 1490
Joined: 02 Jan 2004 17:39
Family Historian: V7
Location: Lancashire, UK
Contact:

Re: GEDCOM 7.0

Post by NickWalker » 26 Feb 2021 13:47

The default font/size is the FH Property Box Font/Size.
Nick Walker
Ancestral Sources Developer

http://www.ancestralsources.com

User avatar
ColeValleyGirl
Megastar
Posts: 2721
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: GEDCOM 7.0

Post by ColeValleyGirl » 26 Feb 2021 13:50

Mike, Nick asked
The user controls the default font and font size via the Family Historian properties so can't your plugin use that? (I don't know if plugins can access that information).

User avatar
NickWalker
Megastar
Posts: 1490
Joined: 02 Jan 2004 17:39
Family Historian: V7
Location: Lancashire, UK
Contact:

Re: GEDCOM 7.0

Post by NickWalker » 26 Feb 2021 13:52

tatewise wrote:
26 Feb 2021 13:44
Yes, my plugin could lookup the default in the Windows Repository but that does not fix the FH GEDCOM file itself.
That suggests it is broken in some way. This is not really an issue unless you want to export the RTF text, which is not something I've done in the last 16 years of using Family Historian and I expect the vast majority of users are the same. I do appreciate some people do and that's where plugins like yours are very useful. So you could add the default font to your exported HTML version which would presumably 'fix' it?
Nick Walker
Ancestral Sources Developer

http://www.ancestralsources.com

User avatar
tatewise
Megastar
Posts: 21304
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: GEDCOM 7.0

Post by tatewise » 26 Feb 2021 14:26

Nick, where have you used RTF text in FH for 16 years when it only arrived in FH V7 recently?
The Export > GEDCOM File... command allows RTF codes to be retained or converted to plain text.
But as the Help says "other genealogy applications are unlikely to support all of them and may support none of them."
That is certainly true.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
NickWalker
Megastar
Posts: 1490
Joined: 02 Jan 2004 17:39
Family Historian: V7
Location: Lancashire, UK
Contact:

Re: GEDCOM 7.0

Post by NickWalker » 26 Feb 2021 14:33

Well obviously (or so I assumed) I meant the text that is now in RTF. I mean source text, notes, etc. I've never exported those in 16 years. I have occasionally exported a very privatised version of my tree to upload to ancestry but I wouldn't include the source text and notes (rich or plain!).
Nick Walker
Ancestral Sources Developer

http://www.ancestralsources.com

User avatar
tatewise
Megastar
Posts: 21304
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: GEDCOM 7.0

Post by tatewise » 26 Feb 2021 15:11

Understood, but many users compose 'stories' in Notes and include them in Reports. Users have been asking here about how to incorporate Rich Text Notes into Reports. They also want them retained when they migrate their GEDCOM to GedSite, TNG, etc, etc... Theoretically, FH should not need my Plugin to support such aspirations.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
NickWalker
Megastar
Posts: 1490
Joined: 02 Jan 2004 17:39
Family Historian: V7
Location: Lancashire, UK
Contact:

Re: GEDCOM 7.0

Post by NickWalker » 26 Feb 2021 15:55

I would definitely include them in reports too, but only in FH and not exporting them. I do think that probably the vast majority of users would not export their data (except perhaps uploads to sites like ancestry) and I expect thats why Calico don't make a massive effort in that area. There is perhaps also an argument that it isn't in a company's interests to make it too easy to move to a competitor. The pain of losing some of the data/formatting would put a lot of people off. I know you will argue that therefore this might put people off moving to FH in the first place but I don't think that's something that the majority of people will consider.
Nick Walker
Ancestral Sources Developer

http://www.ancestralsources.com

User avatar
tatewise
Megastar
Posts: 21304
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: GEDCOM 7.0

Post by tatewise » 26 Feb 2021 16:07

You are missing the point. The users are not moving to a competitor. In the case of GedSite and TNG and others, they are using web site builders that offer features not provided by FH and they want the rich text reproduced there rather than have to format it all over again. Formatted text is potentially more portable than Sentence Templates so attractive to such users.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
NickWalker
Megastar
Posts: 1490
Joined: 02 Jan 2004 17:39
Family Historian: V7
Location: Lancashire, UK
Contact:

Re: GEDCOM 7.0

Post by NickWalker » 26 Feb 2021 16:25

No I'm not missing the point, I do understand that some users want to export to 'companion products' but that wasn't the point I was making. If they make it easy to export data it is then easier to move to competitors. Calico have a finite amount of resources/developer time and they must decide which aspect of FH to allocate that developer time to. They could put a couple of months of developer time into making it seamlessly export the data to multiple products - this will cost them thousands of pounds in development time but will that be recouped in the number of additional sales they would make? How important is this to the majority of their customers?
Nick Walker
Ancestral Sources Developer

http://www.ancestralsources.com

User avatar
ColeValleyGirl
Megastar
Posts: 2721
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: GEDCOM 7.0

Post by ColeValleyGirl » 26 Feb 2021 17:08

As Nick says, it's a fact of life that any development team have a finite amount of resources and have to prioritise. Also, that helping people get data out of your product is not particularly commercially rewarding... whereas helping people get data into your product can be. This may suggest that GedSite and TNG will do the necessary work... or that the Export Gedcom Plugin will have to bridge the gap. I sincerely hope CP have more exciting things in their sights.

Re CP's choice of Rich Text versus HTML, it may be as simple as 'what editing controls are available from Microsoft?' Nick, you'll know better than anyone, is there an HTML-based equivalent for the rich text control you've used in AS? And if there isn't, would you have considered developing your own? (No need to answer -- that's a rhetorical question).

User avatar
BillH
Megastar
Posts: 1654
Joined: 31 May 2010 03:40
Family Historian: V7
Location: Washington State, USA

Re: GEDCOM 7.0

Post by BillH » 26 Feb 2021 17:18

I posted a question on rootstech of one of their experts as to why the sessions were pulled. This is his reply.

Bill, I learned late last night that FamilySearch decided they need more time to prepare for a public release of a new version of GEDCOM. Unfortunately, that will be after RootsTech.

Bill

User avatar
ColeValleyGirl
Megastar
Posts: 2721
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: GEDCOM 7.0

Post by ColeValleyGirl » 26 Feb 2021 17:26

BillH wrote:
26 Feb 2021 17:18
I posted a question on rootstech of one of there experts as to why the sessions were pulled. This is his reply.

Bill, I learned late last night that FamilySearch decided they need more time to prepare for a public release of a new version of GEDCOM. Unfortunately, that will be after RootsTech.

Bill
Or: "A wheel fell off and we're hunting for a scapegoat to blame the early release on."

Me? Cynical? :o

User avatar
BillH
Megastar
Posts: 1654
Joined: 31 May 2010 03:40
Family Historian: V7
Location: Washington State, USA

Re: GEDCOM 7.0

Post by BillH » 26 Feb 2021 17:33

ColeValleyGirl wrote:
26 Feb 2021 17:26

Or: "A wheel fell off and we're hunting for a scapegoat to blame the early release on."

Me? Cynical? :o
:lol:

User avatar
tatewise
Megastar
Posts: 21304
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: GEDCOM 7.0

Post by tatewise » 26 Feb 2021 18:56

Independently, I have heard that GEDCOM 7 was pulled for non-technical reasons similar to the answer given to Bill.

I would hope that CP had more faith in FH than needing to make it difficult for users to migrate to another product.
Anyway, for users to have enough data to make migration worthwhile they must have bought FH so CP already got paid.

Re "CP's choice of Rich Text versus HTML, it may be as simple as 'what editing controls are available from Microsoft?'"
What internal editing controls are available should not dictate the external API and GEDCOM formats.
(Most other products have a significantly different internal data structure than their import/export GEDCOM supports.)
Conversion between a defined subset of Rich Text and a defined subset of HTML is relatively straightforward.
So internal editing could use Microsoft Rich Text tools while the GEDCOM used HTML.
FH clearly does that type of conversion elsewhere as it cannot operate on a GEDCOM file structure internally.
It must convert the GEDCOM to/from an internal memory-based relational data structure of some sort.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
NickWalker
Megastar
Posts: 1490
Joined: 02 Jan 2004 17:39
Family Historian: V7
Location: Lancashire, UK
Contact:

Re: GEDCOM 7.0

Post by NickWalker » 26 Feb 2021 21:46

I would hope that CP had more faith in FH than needing to make it difficult for users to migrate to another product.
Anyway, for users to have enough data to make migration worthwhile they must have bought FH so CP already got paid
I've certainly not suggested CP are trying to make it difficult to migrate to another product, I just said I can understand why they would prioritise other developments ahead of that. If I developed similar software and had a choice between adding some great new features that my users would appreciate and make them want to continue to use it and buy it, or adding features to make it easier to migrate to a competitor... I can't imagine anyone making the second choice. As Helen said, its up to the competing products to make it easier to migrate to them.
Re CP's choice of Rich Text versus HTML, it may be as simple as 'what editing controls are available from Microsoft?' Nick, you'll know better than anyone, is there an HTML-based equivalent for the rich text control you've used in AS? And if there isn't, would you have considered developing your own?
Regarding Helen's question, I know there are lots of options out there for HTML controls, but I've not used them. I wonder if the decision to use RTF was influenced by the reporting side of FH and the ability to control things like page sizes and formatting - I wonder if HTML controls tend to be a bit less precise in terms of formatting, measurements, etc. I was actually a little surprised when I found out that RTF was being used rather than HTML but then I do have a lot of faith in CP and their judgement so there must have been a very good reason for it and I'm sure spent a long time debating the pros and cons. I also expect they began this work years ago, before they may have got any inkling of Gedcom 7 and its use of HTML.

I definitely wouldn't have developed my own HTML control if CP had used one. And if there wasn't a free or very cheap suitable control available (e.g. if CP had paid big money to use a third-party control) then I wouldn't have updated AS to support FH7 formatted text. It took me a huge amount of work to get the rich-text side of AS working and that was using the same MS control that CP used!
Nick Walker
Ancestral Sources Developer

http://www.ancestralsources.com

User avatar
AdrianBruce
Megastar
Posts: 1174
Joined: 09 Aug 2003 21:02
Family Historian: V6.2
Location: South Cheshire
Contact:

Re: GEDCOM 7.0

Post by AdrianBruce » 26 Feb 2021 22:45

Speculations follow:
BillH wrote:
26 Feb 2021 17:18
I posted a question on rootstech of one of their experts as to why the sessions were pulled. This is his reply.
Bill, I learned late last night that FamilySearch decided they need more time to prepare for a public release of a new version of GEDCOM. Unfortunately, that will be after RootsTech. ...
I'm not sure I buy the face value. This was a Release Candidate - even if issues appeared, well, that's what the Life Cycle is about... Either the issues are seriously fundamental (was it really that big to leave untouched fundamental issues?); or FS want a perfect release (in defiance of all the laws of probability); or something else is going on external to GEDCOM 7 itself. Looking at Louis Kessler's blog, he indicates that even the three items on James' Tanner's personal blog have been removed, which must have needed some serious leaning on JT.

I just come back to my first question - why have FS developed this? Speculation: Was it to be the precursor to a completely new method of loading GEDCOMs into the FS site? One that is way behind? Speculation 2: Or has it been stopped by the LDS hierarchy for the same "We are not a software house" logic that killed GEDCOM 5.5.1...

Probably, of course, none of the above....
Adrian

User avatar
mjashby
Megastar
Posts: 586
Joined: 23 Oct 2004 10:45
Family Historian: V7
Location: Yorkshire

Re: GEDCOM 7.0

Post by mjashby » 27 Feb 2021 10:01

I'm equally curious about the 'Why the sudden interest in developing GEDCOM 7?' considering that the LDS were so adamant that they wouldn't continue the traditional GEDCOM development after the 'new' FamilySearch (GEDCOM 6) format was stated to be their only focus for the future.

As far as the equally sudden withdrawal of the 'first release candidate' of GEDCOM 7 goes, the cynic in me keep whispering that maybe the suggestions of plagiarism, i.e. the lack of acknowledgement for the existing published work of others, whether made tongue in cheek or not, maybe struck home.

Mervyn

User avatar
AdrianBruce
Megastar
Posts: 1174
Joined: 09 Aug 2003 21:02
Family Historian: V6.2
Location: South Cheshire
Contact:

Re: GEDCOM 7.0

Post by AdrianBruce » 27 Feb 2021 12:39

mjashby wrote:
27 Feb 2021 10:01
... maybe the suggestions of plagiarism, i.e. the lack of acknowledgement for the existing published work of others, ...
I tend to doubt that - if anyone was on a sticky wicket, it was Tamura, though he did do plenty of acknowledgements. I don't think that FS need to acknowledge his work if they didn't use it - and a number of the contributors to G7 (mentioned in the presentation at least) were also contributors to Tamura's work, IIRC. No, I'm guessing it's something bigger.
Adrian

Post Reply