Spike (#33 phase 1): one drawn-checkbox heuristic shared by iOS and Android - #37
Open
SlyWombat wants to merge 2 commits into
Open
Spike (#33 phase 1): one drawn-checkbox heuristic shared by iOS and Android#37SlyWombat wants to merge 2 commits into
SlyWombat wants to merge 2 commits into
Conversation
…tforms (#33) The spike #33 asks for: prove the packaging and binding work on a small operation that already has assertions everywhere, before the text-edit layer depends on it. detectCheckboxSquares is that operation. core/ holds the C ABI and its one implementation. ABI rules so three toolchains can agree: C only, handles are void* (pass your FPDF_PAGE straight through, the header includes nothing from pdfium), caller-owned buffers with a count-then-fill call, and coordinates already converted to crop space — because getting that wrong is exactly #30, and it should happen once rather than in each binding. Android compiles it into the existing .so via CMake; the JNI entry point is now marshalling only, which is what its own header comment always claimed it was. iOS compiles it into the app target and reaches it through a bridging header. Both platforms' hand-written copies of the heuristic are deleted. Windows is deliberately not in this commit: it is the only shipping product and needs an MSVC/CMake step in its pipeline, so it goes last, with IPdfEngine preserved as an adapter. Not merged into the release either — this is a spike whose result feeds ADR-002.
Written from PR #37's results rather than from reasoning, in ADR-001's shape: 21 Android instrumented tests and 37 iOS tests green against one implementation, +2,140 bytes of APK (+0.014%), one CMake line on Android, a bridging header on iOS, and both hand-written copies of the heuristic deleted. Status is PROPOSED, not ACCEPTED, because the Windows leg is unbuilt — and the spike's most useful finding is *why*: that leg is a distribution decision, not a coding one. No pdfium import library is vendored (generating one from the DLL works — 461 symbols, verified), and the local VS 2017 Build Tools have the compiler but no Windows SDK, so adding a native build step would break local builds of the only shipping product until someone installs it. Vendor a prebuilt or require the SDK: that choice belongs to whoever maintains the Windows release, and it is written up with the recipe in #38.
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
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.
Phase 1 of #33, as that issue specifies it: prove the packaging and binding work on
a small operation that already has assertions on every platform, before the
text-edit layer depends on it.
detectCheckboxSquaresis that operation.This is a spike, not release work. It is not meant to ride along with the 1.1
payload that just merged. What it produces is the evidence for ADR-002.
The exit criterion from #33
This PR does Android and iOS. Windows is deliberately left out, per the
migration order in #33: it is the only shipping product, it needs an MSVC/CMake
step added to its pipeline to produce
megapdf_core.dll, andIPdfEngineshouldbe preserved as an adapter so no
MegaPDF.Appcode changes. Tracked separately.What landed
core/megapdf_core.{h,cpp}— the ABI and its one implementation. The rules thatlet three toolchains agree:
void*— pass yourFPDF_PAGEstraight through. The headerincludes nothing from pdfium, so binding code needs only that one file.
trivial.
it happens once here instead of in each binding.
Android compiles it into the existing
.so(one CMake line; no second binary toship, no runtime ABI boundary) and its JNI entry point becomes marshalling only —
which is what
engine.cpp's own header comment always claimed it was. iOS compilesit into the app target and reaches it through a bridging header. Both hand-written
copies of the heuristic are gone.
What CI decides
The existing fixture assertions are the check:
CheckboxTeston Android andCheckboxTestson iOS already assert exact rects fromfixture.pdf, and they nowexercise the shared implementation instead of two separate ones. If they still pass
unchanged, the architecture is proven for the rest; if the packaging fights back,
we learned it for the price of one small function.
🤖 Generated with Claude Code