GEDCOM's embedded OBJE
Andrei Douglas
the ability to embed binary data into GEDCOM files?
How many genealogical programs support this tag?
How they support it? - ignore, read only, read/write, loose?..
How often do you, folks, meet .ged filed with embedded binaries?
Is it great feature all programs should use, or is it obsolete and
riduculus? (I read an author who insisted embedded files are easier
and safer to maintain because "you cannot loose it" unlike link to a
file which "you can move or forget to include". For my peronal opinion
embedded files are much more vulnerable in text file which everybody
can change...)
Pascal
Andrei Douglas <stra...@genealogysoft.com> a écrit :
> What is opinion of the genealogy community on this GEDCOM feature -
> the ability to embed binary data into GEDCOM files?
According the pdf I have, draft 5.5.1, the support of embedded files
have been removed.
> How many genealogical programs support this tag?
I not tried many but none of them could do it, well not the way I would
like to...
> How they support it? - ignore, read only, read/write, loose?..
> How often do you, folks, meet .ged filed with embedded binaries?
My gedcom file uses objects but I don't embed them, just a link.
> Is it great feature all programs should use, or is it obsolete and
> riduculus?
Objects are great, I like them :)
I link them to a source record as a "proof". Usually it's just photos.
Pascal
Peter J Seymour
Gedcom 5.5 should be regarded as the "stable" version. It is not clear
whether the program you are promoting currently supports inline images,
but then that may be the point of the question.
Inline images should be less problematic these days with the
availablility of greater disk capacity, faster processors, more RAM and
so on. From that point of view there is no substantive reason for not
supporting them. However, my investigations indicate that different
programs may implement the "specification" differently at a detail level
and that an inline image from one program may not not process correctly
in another. Something of a pitfall for the unwary.
The bottom line is that if the support is for "full" Gedcom 5.5, they
ought to be included.
Regards
Peter
David Harper
Given that some genealogy programs can't even handle CONC and CONT tags
for blocks of text in a correct and consistent manner, I'm not at all
confident that they can handle embedded binary data!
The other problem with embedded binary objects is file bloat. You only
need to embed a few dozen photographs, and soon your GEDCOM file is many
megabytes in size. That will dramatically slow down the import process,
even assuming that the program knows how to handle an OBJE tag at all.
David Harper
Cambridge, England
singhals
EVEN assuming he can make it work better/more consistently
cross-platform cross-program than CONC/CONT, I for one
wouldn't want to receive such a GED. If I'm looking in a db
to see whether I've got GGGGM's death-date, I don't want to
sit there waiting while the dag-nabbed program loads dozens
of photos. Your computers may be faster or your patience
more infinite than mine, but I'll bet there are a lot of
folks like me out there who don't want to squeak up for fear
of being ridiculed.
Cheryl
Andrei Douglas
> Gedcom 5.5 should be regarded as the "stable" version. It is not clear
> whether the program you are promoting currently supports inline images,
> but then that may be the point of the question.
No, I decided not to support blobs. Actually I even couldn't find any
sample file with blobs to test the program.
(The only samples I found later on http://www.heiner-eichmann.de/gedcom/gedcom.htm
- good things to test your software, BTW)
> Inline images should be less problematic these days with the
> availablility of greater disk capacity, faster processors, more RAM and
> so on. From that point of view there is no substantive reason for not
> supporting them.
There is some contradiction (more in GEDCOM authors' point than in
your point) - GEDCOM was invented in times of weak 286th machines (or
earlier?), so these inline blobs made the situation even worse
(compare to linked objects)...
(Let's do not blame on GEDCOM authors though - they did not know about
XML and probably HTML that time!... :o)
> However, my investigations indicate that different
> programs may implement the "specification" differently at a detail level
> and that an inline image from one program may not not process correctly
> in another. Something of a pitfall for the unwary.
Yes! By my experience almost all programs deviate from the GEDCOM
standard, sometimes in such a weird and hard-to-explain manner, that
no wonder blobs would be incompatible between different programs...
> The bottom line is that if the support is for "full" Gedcom 5.5, they
> ought to be included.
Probably yes. To be "pure" GEDCOM supporter I probably need to support
them... maybe just read-only (rip blobs off the files on import - put
them in files - make links to them).
Thanks for your opinion, Peter!
Andrei
Andrei Douglas
> need to embed a few dozen photographs, and soon your GEDCOM file is many
> megabytes in size. That will dramatically slow down the import process,
> even assuming that the program knows how to handle an OBJE tag at all.
Even if it doesn't know blobs the situation will not be much better -
it will need to skip all blobs lines anyway...
And yes, you are right - who would like to import megafile just to
read a pair lines of comments to a person - that what happens quite
often...
Thank you for your opinion, David!
Andrei
Pascal
Andrei Douglas <stra...@genealogysoft.com> a écrit :
> No, I decided not to support blobs. Actually I even couldn't find any
> sample file with blobs to test the program.
> (The only samples I found later on
> http://www.heiner-eichmann.de/gedcom/gedcom.htm
> - good things to test your software, BTW)
Done...
Nice file, thanks :)
Pascal
Wes Groleau
> I and many others would support the point you make on your website that
> Gedcom 5.5 should be regarded as the "stable" version. It is not clear
The GEDCOM 5.5.1 spec is clearly labeled not to be used to develop
software. On the other hand, since it seems obvious that there
ain't gonna be no 5.5.2, it's not very nice to keep us from using
whatever improvemments we find in it. (Not like they can stop us,
anyway.)
--
Wes Groleau
Free speech has its limits
http://Ideas.Lang-Learn.us/WWW?itemid=99
Nigel Bufton
"Andrei Douglas" <stra...@genealogysoft.com> wrote in message
news:3d3efec7-0088-4b0d...@k13g2000hse.googlegroups.com...
I have been trying to work with BLOBs. Having decoded and reformed the
embedded text into the "image string", what does one do with it? Is bitmap
data? If so, how does one know what the bitmap header info should be? The
GEDCOM 5.5 documentation only describes decoding - it doesn't describe what
type of image data results.
Nigel
Andrei Douglas
> embedded text into the "image string", what does one do with it? Is bitmap
> data? If so, how does one know what the bitmap header info should be? The
> GEDCOM 5.5 documentation only describes decoding - it doesn't describe what
> type of image data results.
As I understand it works like this: the whole file (with header, etc)
should be encoded + FORM tag (in OBJE tag) should specify the type of
file.
Nigel Bufton
-----------------------------------
That's what I thought. The problem is that the only apparent living example
(in the "Torture" test files) does not contain a multiple of 4 characters
per the standard; the last line has 30 instead of 28 (or 32) characters.
That's why I wondered if there might be some relevance pertaining to the two
additional characters.
Nigel
Peter J Seymour
out there. Have you tried searching on some combination such as "HEAD"
and "OBJE" and so on?
Peter
Nigel Bufton
"Peter J Seymour" <mo...@pjsey.demon.co.uk> wrote in message
news:g4vkb5$233$1$8302...@news.demon.co.uk...
Got it!
I found only one other (searching for "0 HEAD" "1 BLOB"), and it works!
For posterity, the following is a bitmap (bmp) of a small red cross in a
white rectangle.
1 BLOB
2 CONT
0pYe2........M1....8....H....A/...E..U/......E5/........................
2 CONT
zzzzzzzzzzzzzzzzzzzzzzzzzzzz....................zzzzzzzzzzzzzzzzzzzzzzzz
2 CONT
zzzz....zzzzzzzzzzzzzzzzzzzz.........wzz.wzz.wzz.wzz.wzz........zzzzzzzz
2 CONT
zzzzzzzzzzzz....zzzzzzzzzzzz.........wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz
2 CONT
........zzzzzzzzzzzz....zzzzzzzz.....wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz
2 CONT
.wzz.wzz.wzz.wzz....zzzzzzzz....zzzzzzzz.....wzz.wzz.wzz.wzz.wzz.wzz.wzz
2 CONT
.wzz.wzz.wzz.wzz.wzz.wzz....zzzzzzzz....zzzz.....wzz.wzz.wzz.wzz.wzz....
2 CONT
.................wzz.wzz.wzz.wzz.wzz....zzzz....zzzz.....wzz.wzz.wzz.wzz
2 CONT
.....wzz.wzz.wzz.wzz.wzz.....wzz.wzz.wzz.wzz....zzzz.........wzz.wzz.wzz
2 CONT
.wzz.....wzz.wzz.wzz.wzz.wzz.wzz.wzz.....wzz.wzz.wzz.wzz.............wzz
2 CONT
.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz........
2 CONT
.....wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz
2 CONT
.............wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz
2 CONT
.wzz.wzz.............wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz
2 CONT
.wzz.wzz.wzz.wzz........zzzz.....wzz.wzz.wzz.........wzz.wzz.wzz.wzz.wzz
2 CONT
.........wzz.wzz.wzz....zzzz....zzzz.....wzz.wzz.wzz.........wzz.wzz.wzz
2 CONT
.wzz.wzz.........wzz.wzz.wzz....zzzz....zzzzzzzz.....wzz.wzz.wzz.wzz.wzz
2 CONT
.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz....zzzzzzzz....zzzzzzzz.....wzz.wzz.wzz
2 CONT
.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz....zzzzzzzz....zzzzzzzzzzzz....
2 CONT
.....wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz.wzz........zzzzzzzzzzzz....zzzzzzzz
2 CONT
zzzzzzzzzzzz.........wzz.wzz.wzz.wzz.wzz........zzzzzzzzzzzzzzzzzzzz....
2 CONT
zzzzzzzzzzzzzzzzzzzzzzzzzzzz....................zzzzzzzzzzzzzzzzzzzzzzzz
2 CONT zzzz....zzzz
Many thanks,
Nigel
Nigel Bufton
-----------------------------------------------
Contrary to other opinions expressed, the BLOB was probably ahead of its
time and its removal in the 5.5.1 proposal was arguably premature.
The intent of GEDCOM is data transfer between systems, and the BLOB is ideal
for this. The alternative is to have to collect all the separate object
files together with the GEDCOM and transfer the collection. Admittedly,
BLOB inflates the GEDCOM file, but without the need to collect all the other
files. If the GEDCOM is zipped, the likely difference in total is
relatively small.
We should remember that GEDCOM 5.5 dates back to the 1990s. At that time,
object references in GEDCOMs were considerably rarer - in fact imaging as a
whole was far removed from what it is today. Computing power, internet
speeds, and online availability of genealogy information has changed the
shape of genealogy databases and the volume of non-text information that is
gathered nowadays.
The Complete Genealogy Builder (currently in development) will support BLOB
and non-BLOB GEDCOM 5.5 export methods. The BLOB method will be recommended
for sending the entire database to others or to transfer between systems,
simply because it ensures that all data elements are included in a single
file (which can of course be zipped), without having to locate all the
pieces with the risk of missing some.
Perhaps other genealogy program authors will also reconsider the advances
over the past ten years and realize that BLOB support is a concept whose
time has probably arrived.
Nigel
www.tcgr.bufton.org