Description: When importing an image it would be friendly to save some metadata. The most important of this would be the original file name. I've lost count of the number of times I've extracted an image from LO to reuse wishing that when I saved it I knew the original file name (so I could simply go find the original). It would also be really useful to get this metadat in some kind of "properties" dialogue. Steps to Reproduce: Import a file (image etc) Save the file or try to find the original file details - they are gone Actual Results: Import a file (image etc) Save the file or try to find the original file details - they are gone Expected Results: Saved the metadata: filename: xxx.jpg path: /home/fred/bloggs/images/ date import: 12 Feb 1956 Reproducible: Always User Profile Reset: No Additional Info: I realise that all this info won't always be there but most can be stashed in the image format's metadata headers so it should be possible. For privacy some people would probably like to clear this.
Adding UX to the conversation as especially the privacy aspect needs some consideration.
Some info might be useful and is shown anyway with the image. Following [1] interoperability keywords are * keywords * description * date and time* * orientation * rating * copyright* * creator* * location created * location shown where those with asterisks seems most important to me (exif [2] has much more info) plus file name, which is not part of the digital still image meta data but in the more general definition [3] * Means of creation of the data * Purpose of the data * Time and date of creation* * Creator or author of the data* * Location on a computer network where the data was created* * Standards used * File size * Data quality * Source of the data* * Process used to create the data Not an easy topic. [1] https://en.wikipedia.org/wiki/Metadata_Working_Group [2] https://en.wikipedia.org/wiki/Exif [3] https://en.wikipedia.org/wiki/Metadata#Definition
Thanks folks for looking at this: For me the priority would be filename, path and date - Personally I'm not bothered about the rest but I was surprised that LO doesn't preserve or allow manipulation of this data. Personally I think that all concerns could be addressed at the point of import: Import (without metadata) Import (with metadata) and an "edit metadata" option for the image.
What has OASIS and the ODF TC worked out from past sessions? Delving too far into Exif or XMP for the benefit of raster images, with no appreciable support for other graphics seems kind of short sighted. I'd much rather see a fully fleshed out treatment of Dublin Core [1] as the basis for metadata attribute assignment in XML of all objects held in ODF, not just raster images. Might be doable with XMP. But, I don't think we want the overhead of manipulating Exif/TIFF binary headers for images that we convert and manipulate internally in SVM/BMP anyhow. IHMO keeping track of metadata during the image/graphic object lifecycle would be better handled as with the rest of an object's properties and all objects with common methods. That has benefit of allowing us to "anonymize" the objects attributes when that is preferred/required for privacy. =-ref-= [1] https://en.wikipedia.org/wiki/Dublin_Core
(In reply to ffs from comment #0) > path: /home/fred/bloggs/images/ > date import: 12 Feb 1956 Please mind! I don't see these two above here in the various links on meta data :)
Regina, has ODF dedicated fields for those information, or a) does it make sense to enhance the format first or b) should we (ab)use some meta tag? Regarding the actual fields it doesn't matter too much whether it's based on DCMES (c4) or MWG (c2). But we should take care on the actual request (where did I take an image from, locally). Plus, we should not override relevant fields. "Source" might be an option. And for this reason (and for simplicity) I vote against editing the meta data.
(In reply to Heiko Tietze from comment #6) > Regina, has ODF dedicated fields for those information, or a) does it make > sense to enhance the format first or b) should we (ab)use some meta tag? No, ODF has no hidden additional information for the image itself. The user can put information into the general <svg:desc> element of the containing <draw:frame> element. It is possible to store information in a <meta:user-defined> element in the <office:meta> element. In the UI those are in File > Properties, tab 'Custom Properties'. The user is free in the name (key) of such property, only that it has to be unique. The content (value) can be arbitrary text. If a user take the image name as key and the URL as value, he can save the information together with the document. Both suggestion needs explicit actions by the user. I would not do such things automatically. But it sounds like a task for a script, which can be installed as extension.
I would advise (as the OP) that this should be a default feature if LO and not an optional script. Ideally it would be optional (but by default on) in the insert image dialogue "keep source filename [yes]". The reason being is that ideally I'd like this to have been the default the last few years so I can recover the original now - no optional script will allow me to go back in time once I realise this information isn't being stored by default and by the time anyone realises it is too late. There are reasons not to store this information an to allow it to be opted out, edited or deleted, but for the average users it will be useful. Personally I'd stick it in the metadata of the image rather than a private LO tag.
Created attachment 149879 [details] Document properties in inkscape (In reply to ffs from comment #8) > Personally I'd stick it in the metadata of the image rather than a private > LO tag. We need to take care about compatibility, ie. roundtrips of the odf with other tools like OpenOffice, Calligra, with alien formats such as from MSO and when exporting/importing the image as SVG, for example. As of SVG, Inkscape has some tags shown in the attachment. Those are saved in the metadata <metadata id="metadata5"> <rdf:RDF> <cc:Work rdf:about=""> <dc:format>image/svg+xml</dc:format> <dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> <dc:title>Test</dc:title> <dc:date>11.3.2019</dc:date> <dc:creator> <cc:Agent> <dc:title>HT</dc:title> </cc:Agent> </dc:creator> <dc:rights> <cc:Agent> <dc:title>CC0</dc:title> </cc:Agent> </dc:rights> <dc:publisher> <cc:Agent> <dc:title>HT</dc:title> </cc:Agent> </dc:publisher> <dc:identifier>none</dc:identifier> <dc:source>self-made</dc:source> <dc:language>English</dc:language> <dc:subject> <rdf:Bag> <rdf:li>test</rdf:li> <rdf:li>rectangle</rdf:li> </rdf:Bag> </dc:subject> <dc:description>This is a test.</dc:description> <dc:contributor> <cc:Agent> <dc:title>RH</dc:title> </cc:Agent> </dc:contributor> <cc:license rdf:resource="http://creativecommons.org/publicdomain/zero/1.0/" /> </cc:Work> <cc:License rdf:about="http://creativecommons.org/publicdomain/zero/1.0/"> <cc:permits rdf:resource="http://creativecommons.org/ns#Reproduction" /> <cc:permits rdf:resource="http://creativecommons.org/ns#Distribution" /> <cc:permits rdf:resource="http://creativecommons.org/ns#DerivativeWorks" /> </cc:License> </rdf:RDF> </metadata> Sounds like some work for the developers.