Once editing and Behold file format, will the following result in truncation to conform to GEDCOM?
5908: 2 SOUR Citation Text: © Wiltshire Family History Society 2004 - Wiltshire Baptism CD (CDP1) Year : 1795 Date : MAY 18 Surname : BROWN Forename : STEPHEN Relationship : S Parents : WILLIAM & ANNE (NEAT) 5TH CHILD B APR 27TH Parish : CHISELDON
** Behold will read the entire line.(#3): This line including terminator is 288 characters long but it should be not be more than 255.
It will convert into a "2 SOUR" line followed by as many "3 CONC" lines as are required.
So does that warning greater than 255 comes as a result of an incorrect GEDCOM export?
Lines longer than 255 characters are illegal in GEDCOM. So yes, it is incorrect. Programs should not export lines longer than 255 characters.
I have just run into the same issue, but with text containing multi-byte UTF-8 characters. In this case, Behold 220.127.116.11 does not seem to count the characters correctly.
23580: 2 CONT hat gegenwÃ¤rtig 750â€¢ Einwohner und war frÃ¼her eine rein landwirtschaftlich orientierte Landgemeinde mit einer schÃ¶nen KirchenWehranlage. Heute gibt es nur noch 5 selbstÃ¤ndige Bauern, alle Ã¼brigen mÃ¤nnlichen und weiblichen Einwohner arbeiten in I
** Behold will read the entire line.(#3): This line including terminator is 262 characters long but it should be not be more than 255.
The actual text is:
hat gegenwärtig 750• Einwohner und war früher eine rein landwirtschaftlich orientierte Landgemeinde mit einer schönen KirchenWehranlage. Heute gibt es nur noch 5 selbständige Bauern, alle übrigen männlichen und weiblichen Einwohner arbeiten in I
Looking at the log file in NP++, it looks to me as though there are only 255 chars in the text, including the trailing CR/LF line terminators.
This may or may not have been addressed for your next release, but I thought it might be worth mentioning now - just in case ;-)
This seems like it might be that the file has a BOM (Byte Order Mark) that is inconsistent with the 1 CHAR set specified in the file, or the GEDCOM file might not match the 1 CHAR set. Would you mind sending me at least the log file, and (if you don't mind) the GEDCOM file as well, and I can see what's going on.
Sent a shortened version of the files which shows the problem to you off-list.
It has no BOM but is encoded as UTF-8 and is recognized by Behold as UTF-8 and has
1 CHAR UTF-8
even so, Behold complains about the missing BOM.
But that is supposed to be one of the advantages of UTF-8 - BOM not required. ;-)
even though it is a headache for programmers who have to handle those files.
Thanks, Arnold for sending this. The problem is fixed and will be included in the upcoming version 1.1.
Also, in Version 1.1, I've made the missing BOM a warning, since although Behold handles this, some programs won't correctly process a UTF-8 file without the BOM.
Despite the incorrect messages, the current version of Behold should still display your data correctly.
You must login to post your reply.
Also check out my freeware programs: GEDCOM File Finder and Double Match Triangulator
Copyright © Louis Kessler
All Rights Reserved