https://bugs.documentfoundation.org/show_bug.cgi?id=171552
--- Comment #1 from Thomas Tempelmann <[email protected]> --- Here's how to properly check the conformity: Build this code as a cmdline tool for macOS (name it "uti-conforms-to"), which uses the OS framework's "conformsTo" function: https://gist.github.com/tempelmann/0567400bfaceb424c893259a130ade60 If you run it to test the L.O. spreadsheet type, you get: % uti-conforms-to org.oasis-open.opendocument.spreadsheet public.content org.oasis-open.opendocument.spreadsheet conforms to public.content % uti-conforms-to org.oasis-open.opendocument.spreadsheet public.spreadsheet org.oasis-open.opendocument.spreadsheet does not conform to public.spreadsheet So, it shows that the type of .ods files does NOT conform to the public.spreadsheet type as it should. If you try the same for the UTI of a .numbers file, you get the correct answer: % uti-conforms-to com.apple.iwork.numbers.sffnumbers public.spreadsheet com.apple.iwork.numbers.sffnumbers conforms to public.spreadsheet Same for an .xslx (Excel) file: % uti-conforms-to org.openxmlformats.spreadsheetml.sheet public.spreadsheet org.openxmlformats.spreadsheetml.sheet conforms to public.spreadsheet Don't be fooled by the "kMDItemContentTypeTree" (e.g. as shown by the cmd "mdls") that lists "public.spreadsheet" as one of the types. That is not sufficient because that tree is only available to files indexed by Spotlight, and many files, e.g. those on file servers and possibly other locations, are not indexed - so a search tool can't easily determine this tree and has to rely on testing the file's direct UTI (kMDItemContentType) with the UTTypeConformsTo() function or the "-[NSWorkspace:type:conformsToType]" ObjC method or its Swift equivalent function, none of which would be able to tell that an ods file is a spreadsheet file, whereas it works for Excel and Numbers files. -- You are receiving this mail because: You are the assignee for the bug.
