What it the correct way to add photos to a gedcom??

[Stephen Woodbridge]

Hi all,

I want to automate adding photos to my gedcom file.

I created a trivial file in PAF 5.2.18.0 and added a photo and got the
following file:

0 HEAD
1 SOUR PAF
2 NAME Personal Ancestral File
2 VERS 5.2.18.0
2 CORP The Church of Jesus Christ of Latter-day Saints
3 ADDR 50 East North Temple Street
4 CONT Salt Lake City, UT 84150
4 CONT USA
1 DEST PAF
1 DATE 23 Dec 2012
2 TIME 17:12:31
1 FILE test.ged
1 GEDC
2 VERS 5.5
2 FORM LINEAGE-LINKED
1 CHAR UTF-8
1 LANG English
1 SUBM @SUB1@
0 @SUB1@ SUBM
1 NAME Stephen Woodbridge
0 @I1@ INDI
1 NAME Stephen /Woodbridge/
2 SURN Woodbridge
2 GIVN Stephen
1 SEX M
1 _UID 51190DB94CBF254F8654B3F06C2E42343CF0
1 CHAN
2 DATE 23 Dec 2012
3 TIME 17:11:18
1 OBJE
2 FORM jpg
2 FILE Misc photos\Steve-large.jpg
2 TITL This is a caption.
2 NOTE Bla bla bla.
2 _SCBK Y
2 _PRIM Y
2 _TYPE PHOTO
2 _SSHOW Y
0 TRLR

I tried to create the same in Gedcom.pm but I get these warnings:

FORM is not a sub-item of OBJE
FILE is not a sub-item of OBJE
TITL is not a sub-item of OBJE
*:0: FILE is not a sub-item of OBJE
*:0: TITL is not a sub-item of OBJE
*:0: FORM is not a sub-item of OBJE

The output file appears to be created as requested, but I'm not sure why
I'm getting these warnings.

I also noticed that PAF adds a lot of _TAG items to the file. Is this
part of the standard for application specific tags?

Thanks,
-Steve

[Stephen Woodbridge]

So after reading the bits and pieces of the 5.5 grammer I see:

MULTIMEDIA_LINK: =

[ /* embedded form*/
n OBJE @<XREF:OBJE>@ {1:1}
| /* linked form*/
n OBJE {1:1}
+1 FORM <MULTIMEDIA_FORMAT> {1:1}
+1 TITL <DESCRIPTIVE_TITLE> {0:1}
+1 FILE <MULTIMEDIA_FILE_REFERENCE> {1:1}
+1 <<NOTE_STRUCTURE>> {0:M}
]

and it appears that <<MULTIMEDIA_LINK>> is allow under an INDI record:

INDIVIDUAL_RECORD: =

n @<XREF:INDI>@ INDI {1:1}
+1 RESN <RESTRICTION_NOTICE> {0:1}
+1 <<PERSONAL_NAME_STRUCTURE>> {0:M}
+1 SEX <SEX_VALUE> {0:1}
+1 <<INDIVIDUAL_EVENT_STRUCTURE>> {0:M}
+1 <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>> {0:M}
+1 <<LDS_INDIVIDUAL_ORDINANCE>> {0:M}
+1 <<CHILD_TO_FAMILY_LINK>> {0:M}
+1 <<SPOUSE_TO_FAMILY_LINK>> {0:M}
+1 SUBM @<XREF:SUBM>@ {0:M}
+1 <<ASSOCIATION_STRUCTURE>> {0:M}
+1 ALIA @<XREF:INDI>@ {0:M}
+1 ANCI @<XREF:SUBM>@ {0:M}
+1 DESI @<XREF:SUBM>@ {0:M}
+1 <<SOURCE_CITATION>> {0:M}
+1 <<MULTIMEDIA_LINK>> {0:M}
+1 <<NOTE_STRUCTURE>> {0:M}
+1 RFN <PERMANENT_RECORD_FILE_NUMBER> {0:1}
+1 AFN <ANCESTRAL_FILE_NUMBER> {0:1}
+1 REFN <USER_REFERENCE_NUMBER> {0:M}
+2 TYPE <USER_REFERENCE_TYPE> {0:1}
+1 RIN <AUTOMATED_RECORD_ID> {0:1}
+1 <<CHANGE_DATE>> {0:1}

So this looks like a bug in Gedcom Vers 1.16 that I downloaded from CPAN
last night.

Thoughts?

-Steve

[Ron Savage]

Hi Stephen

I suggest you log a bug report at:

https://rt.cpan.org/Public/Dist/Display.html?Name=Gedcom

Although don't hold your breath :-(.

--
Ron Savage
http://savage.net.au/
Ph: 0421 920 622

[Ron Savage]

Hi Stephen

On 24/12/12 09:32, Stephen Woodbridge wrote:

See here for some info on those types of tags:

https://metacpan.org/module/Genealogy::Gedcom::Reader::Lexer#FAQ

[Stephen Woodbridge]

Hi Ron,

Thanks I did not know where to write it up.

https://rt.cpan.org/Ticket/Display.html?id=82196

In case anyone want to track it.

Thanks,
-Steve