Details
- Reviewers
astippich ngraham - Group Reviewers
Baloo Frameworks - Commits
- R293:eacc7ac92ab0: Add "image/svg" as Type::Image to the BasicIndexingJob
Diff Detail
- Repository
- R293 Baloo
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Is indexing the contents of SVG images actually desirable? The fact that these files are internally represented by text rather than binary data is an implementation detail, and their contents are generally not useful since they're not intended to be human-readable.
Twice wrong ;-):
- This is just the document type, so it would be even useful for filename only searches
- The xmlextractor I have added recently to KFileMetaData handles Dublin Core metadata (e.g. Author, Keywords, ...) and text spans (i.e. content) in SVG.
Cool, that seems fine.
text spans (i.e. content) in SVG.
Is indexing any of this actually useful? I worry that it would be just noise in >99% of cases.
This text in an SVG file is an implementation detail, not user content like the metadata in a JPEG. For example, here's the textual content of a random Breeze icon:
https://cgit.kde.org/breeze-icons.git/tree/icons/devices/64/computer.svg
For example would it make sense to find SVG files when searching for "layer" or "matrix" or "connector"?
If we have a way to index only the genuine metadata (author, keywords, etc) but omit the text that comprises the icon's internal representation, that would work. Otherwise I think this would just add a lot of useless data to the DB.
No, thats the raw data, not text spans, e.g. <text>Some Text</text>.
See e.g. https://suchanek.name/programs/powerline/intro/3.svg
The content is e.g. "LaTex with PowerLine"