Multipart media

Ideas
1

The gedcom standard (v5 and v7) provides that multiple files can be associated with a media. Clearly, this is not the case for media in Gramps.

Is this a feature that is planned?

This could be useful in many cases. Three come to mind to illustrate my question but for sure there are many others:

  • a double-sided document, such as a postcard or a letter,
  • the multiple pages of a newspaper,
  • the contents of a file, such as a military file.

So we could use a PDF or TIFF format that accepts multipart. But the gedcom standard goes further where a media can include two (and more) files, one of each of these two types for example.

2 Likes
2

Features for restoring the Tree and Media Objects separately would also be useful. (And doing the same with GEDCOM7’s GedZips.) There are oddities with OS cross-compatibilities and managing (or flattening) paths that might evolve more effectively if the functionalities were segregated.

That includes features re-linking paths to objects and managing filenames.

GrampsWeb and Narrated Web Site reorganize media to suit their own intelligent file management concepts.

Some aspects of multiple object Media records are touched upon in the following recent thread:

2 Likes
3

Maybe all file paths should be stored in JSON objects?

e.g

{
“D”: {
“sources”: {
“subfolder 1”: {
“subfolder 2”: {
“subfolder 3”: {
“subfolder 4”: {
“filename.pdf”: {
“protocol”: “file”,
“system”: “Windows”
}
}
}
}
}
}
},
“UNC”: {
“sources”: {
“subfolder 1”: {
“subfolder 2”: {
“subfolder 3”: {
“subfolder 4”: {
“filename.pdf”: {
“protocol”: “UNC”,
“system”: “Windows”
}
}
}
}
}
}
},
“HTTP”: {
“sources”: {
“subfolder 1”: {
“subfolder 2”: {
“subfolder 3”: {
“subfolder 4”: {
“filename.pdf”: {
“protocol”: “HTTP”,
“system”: “Web”
}
}
}
}
}
}
},
“Linux/Unix”: {
“sources”: {
“subfolder 1”: {
“subfolder 2”: {
“subfolder 3”: {
“subfolder 4”: {
“filename.pdf”: {
“protocol”: “file”,
“system”: “Linux/Unix”
}
}
}
}
}
}
}
}

In addition, the full original string could be a part of that object, that way it would never be any problems with OS cross-compatibilities or URL’s.
The file path is then generated for the GUI and is of course clickable…

IT could as well be an XML objects, this was just a quick example to maybe be able to get around some problems that can occur.

These objects can also easily be read and write out to a Gedcom file in whatever format it demands, or other formats as needed.

It would also be easy to store multiple file paths for multiple objects in this format AND it will be human readable.

4

It’s not really planned, but it seems like a good idea. I have no objection to this functionality being added.

The Gedcom standard would provide us with a specification. The only things that I don’t understand is why the MULTIMEDIA_LINK lacks a reference to the file for the cropped area. Does it assume the first file?

1 Like
5

We should probably use the python Path object for paths. These could be serialised in a Posix format for readability.

Urls can simply be strings.

6

Do you want I add a request in Mantis?

1 Like
7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.