lizzo
New Member
Posts: 39
|
Post by lizzo on Oct 7, 2013 15:26:17 GMT -5
When exporting, one has a choice to include or exclude Notes. However, the manual does not mention exporting Wallet contents so that the contents are still linked to an individual. Does GEDCOM not permit that?
|
|
|
Post by Howard Metcalfe on Oct 7, 2013 18:08:15 GMT -5
When exporting, one has a choice to include or exclude Notes. However, the manual does not mention exporting Wallet contents so that the contents are still linked to an individual. Does GEDCOM not permit that? Hi Lou, Embedding multimedia objects such as pictures is allowed in the GEDCOM 5.5 standard but is not really defined in any detail to allow standardized import into any program I know of. A second method allows just a reference to a multimedia file to be embedded which is what I do. So it's not really a solution. Here is the text in the standard: 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} ]
This structure provides two options in handling the GEDCOM multimedia interface. The first alternative (embedded) includes all of the data, including the multimedia object, within the transmission file. The embedded method includes pointers to GEDCOM records that contain encoded image or sound objects. Each record represents a multimedia object or object fragment. An object fragment is created by breaking the multimedia files into several multimedia object records of 32K or less. These fragments are tied together by chaining from one multimedia object fragment to the next in sequence. This procedure will help manage the size of a multimedia GEDCOM record so that existing systems which are not expecting large multimedia records may discard the records without crashing due to the size of the record. Systems which handle embedded multimedia can reconstitute the multimedia fragments by decoding the object fragments and concatenating them to the assigned multimedia file.
The second method allows the GEDCOM context to be connected to an external multimedia file. This process is only managed by GEDCOM in the sense that the appropriate file name is included in the GEDCOM file in context, but the maintenance and transfer of the multimedia files are external to GEDCOM. Best, Howard
|
|
lizzo
New Member
Posts: 39
|
Post by lizzo on Oct 7, 2013 18:49:14 GMT -5
Thanks, Howard. Does this mean that the code you listed can be inserted (where?) so that media (Wallet contents) can be exported by PAW2U?
|
|
|
Post by Howard Metcalfe on Oct 8, 2013 10:14:30 GMT -5
Thanks, Howard. Does this mean that the code you listed can be inserted (where?) so that media (Wallet contents) can be exported by PAW2U? Hi Lou, The code that is exported by PAWriter is just the reference to the pictures. So when you export the data file and move it to another Mac, you must also move the Scrapbook folder with it to the same folder. (That of course assumes you have placed all the pictures into the Scrapbook.) No, the Scrapbook and its pictures are not otherwise exported. If there were some standard way of embedding the pictures in the data file, they would take up just as much space as they do in the Scrapbook; but there's not. The process is described in detail in the Reference Guide topic Basic Navigation > Accessing Pictures, which is too large to include in this post. This also decribes why all pictures should be placed in the Scrapbook, a matter of portability. So in order to backup the pictures, you must copy the Scrapbook. Hope this helps. Best, Howard
|
|
|
Post by herkittydaddy on Dec 29, 2013 15:44:30 GMT -5
May I ask, respectfully of course, why the scrapbook directory is with the application and not the data? If this has been discussed somewhere else and I missed it when searching, my apologies. (Please point me to that discussion.) This question arises out of my having more than one tree being worked on with the same machine. Thank you for your time!
|
|
|
Post by Howard Metcalfe on Dec 30, 2013 11:55:17 GMT -5
May I ask, respectfully of course, why the scrapbook directory is with the application and not the data? If this has been discussed somewhere else and I missed it when searching, my apologies. (Please point me to that discussion.) This question arises out of my having more than one tree being worked on with the same machine. Thank you for your time! Respectfully, the question has not been discussed elsewhere. There didn't seem to be a need to have more than one scrapbook shared among various data files. Most users have only one data file, and others have interrelated data files in which scrapbook entries can be shared. A central repository of source images seemed advisable. No change is now possible. This is the method that the Reunion program used when PAWriter was originally programmed, so the same concept was adopted as an acceptable feature, also allowing export of everything to Reunion should one wish to do that (One user has already accomplished that. ) Best regards, Howard
|
|