Take odrcore 6.11.0

[andiwand]

odrcore 6.10.1 → 6.11.0, resolved against the tag. The release went out as a minor despite carrying a breaking change.

Paired with opendocument-app/OpenDocument.droid#634.

Two workarounds come back fixed, one does not

Three were filed from #183. Two go:

filed	fixed by	what goes here
core#730 target="_blank" on every view	core#756	the WKUIDelegate no longer has to catch served links
core#728 the text fallback	core#743	the charset check in CoreWrapper.translate
core#706 / core#726 no top-level fit	core#745	nothing — see below

The charset check was always a workaround for the core answering "text" to anything it did not recognise. Now decode throws and listFileTypes comes back empty, which the guard three lines above already catches — and it catches the NUL-padded binaries the charset check missed.

The link target needed new code rather than a deletion. Only external links carry target="_blank" now, so served links navigate in place and never reach createWebViewWith; what does reach it is the web, which went nowhere before and now goes to the browser.

The fit stays ours

viewportMode = .fitWidthByView was the headline of this PR and it is reverted. Driving both builds in a simulator, it makes an ODT render worse than today: the mode pins initial-scale=1.0 and leaves the fit to a script inside the view, and in WKWebView that script's zoom never lands, so the page sits at actual size with body text at ~2× and only its first third on screen.

ODT, portrait	differing pixels vs the shipping build
with fitWidthByView	11.4%
with it off, nothing else changed	1.2%

So the user script stays. Filed as opendocument-app/OpenDocument.core#761 with the emitted viewport for each mode.

Worth recording from the same run: on iOS 26 WKWebView fits a top-level page by itself at load, so in portrait the script is no longer doing anything. It is still needed on rotation — without it, turning the phone leaves the document at the old scale (9% of pixels differ). That is the half fit_width_by_view was meant to take over.

Picked up from Android

The spreadsheet limits are stated rather than inherited, the same numbers as droid#623 and droid#634: 100000 × 500 with a 500000-cell budget. Without this the bump silently moves them, since core#757 raised the default from 10000 rows and added the budget.

The apple binding makes this awkward: spreadsheetLimit is a TableDimensions boxed in an NSValue, and Swift has no @encode, so the type encoding is a string literal. Filed as opendocument-app/OpenDocument.core#759.

HTML is drawn by the system again. odrcore has no html type, so an .html decoded as text and the reader showed the page's source; html, htm and xhtml were in the extension list #183 replaced with "ask the core", and nothing took over. systemDrawsItBetter already means what is wanted, so html joins iWork in it, by type. public.xhtml conforms to xml and not to html, so both types are named — xml alone would catch flat ODF, which odrcore does render.

EPS, DXF and PSD stay out of the listing, and a probe says why: a WKWebView answers canShowMIMEType false for all three (com.adobe.photoshop-image, com.adobe.encapsulated-postscript, and DXF has no declared type at all). There was never a native rendering behind those three claims.

Markdown now opens as prose. It has no signature, so odrcore reads a .md as text and only the name can say otherwise; CoreWrapper.openFile opens again as the type the name states, under droid's own rule — a document, or a format the core cannot detect from its bytes. Csv is neither and stays the core's decision. This is what a131cf3 held back, so the listing gets its markdown line.

iWork keeps the system's rendering

odrcore reads .pages, .numbers and .key since core#732/738/739, so they stop being archives and the routing from #183 — it saw a container, the system knows a document — stops firing on its own. But src/odr/internal/iwork/PLAN.md has stages 3 and 4, styles and drawables, still open, so a .pages renders body text and anchored tables only. That is less than the phone draws, so the three are named explicitly instead.

Verified

69 tests, 0 failures; ODR Full, ODR Lite and ODR Screenshots all build; format clean. CI green.

Beyond CI, both builds were driven in an iPhone 17 Pro simulator on iOS 26 and photographed portrait → landscape → portrait for the text, sheet, office and pdf screens, then diffed frame for frame against the shipping build. Sheet is identical, pdf differs by 0.8–2% (the pdf fixes), office by 0.7%. That comparison is what found the viewport regression.

Not covered: a real device, and an iPad.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Y7ALzy5VB32UfQn263Tbnk