Claim the formats odrcore renders that iOS has no type for - #160
Merged
Conversation
The document browser decides what the user may pick from `CFBundleDocumentTypes`, and the four broad types claimed there miss seven formats odrcore renders: the flat XML documents (.fodt .fodp .fods .fodg), an ODF master template (.otm), and .xlm and .xlt. The first six resolve to a dynamic type, which conforms to `public.data` and nothing else; .xlt has a system type that conforms to no claim of ours. All seven were greyed out. `UTImportedTypeDeclarations` gives the six a real type - imported, since none of them is ours - and they join `LSItemContentTypes` along with .xlt's. The plist cannot read odrcore's table, so `DeclaredDocumentTypesTests` holds one against the other, as OpenDocument.droid does with its manifest. Reverting the plist fails it with exactly those seven. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UNugiHVRHVc1CGHgVGW7Dz
andiwand
force-pushed
the
claim-what-odrcore-renders
branch
from
August 16, 2026 08:14
3eb185d to
ad5bf94
Compare
This was referenced Aug 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The document browser decides what the user may pick from
CFBundleDocumentTypes. The app claims four broad types pluspublic.zip-archive, which is mostly right — that is what carries docx, doc, pdf and the ODF packages — but it misses seven formats odrcore renders:.fodt.fodp.fods.fodg.otm.xlm.xltThe first six resolve to a dynamic type — what iOS invents for an extension it has never heard of. It conforms to
public.dataand nothing else, so no claim short ofpublic.datareaches it..xltis stranger: iOS does knowcom.microsoft.excel.xlt, it just does not conform topublic.composite-contentthe waycom.microsoft.excel.xlsdoes. Either way the file was greyed out with no way in.UTImportedTypeDeclarationsgives the six a real type — imported rather than exported, since none of them is ours — and they joinLSItemContentTypesalong with.xlt's.Why not narrow the claims instead
The broad types are also what covers the formats odrcore does not render and the app hands to the system — rtf, html, the iWork formats. Replacing them with per-format entries would lose that. So this adds to them rather than replacing them.
The test
The plist cannot read odrcore's format table, so
DeclaredDocumentTypesTestsholds one against the other, which is how OpenDocument.droid keeps its manifest honest (SupportedDocumentTypes.kt). It reads the built app's plist rather than a copy, over the set droid callsCLAIMED_FILE_TYPES— everything withtranslateHtmlin the document category, plus txt and csv:Reverting the plist fails it with exactly the seven above; with it, all 35 tests pass and both schemes build.
🤖 Generated with Claude Code