Repository navigation
PDF Tools: honest Edit on real-world PDFs (pdf.edit_check, plain refusals, a browser-printed test page) - #501
Merged
Merged
Conversation
ymote
added a commit
that referenced
this pull request
Oct 11, 2026
The coordinator's contract text for #501: pdf.edit_check's arguments and answer, its plain refusals, and the correction that an edited paragraph keeps its own font only when that font can show the new text (otherwise the engine draws a stand-in, which edit_check reports first). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Home's main activity is exported, so any installed app can start it with intent extras, and Makepad copies `makepad.<NAME>` extras into the environment. OctoSense code read several of them in release builds. - shell: `launch_input` is the one reader of MAKEPAD_APP_CONFIG. Its test actions, Mail's demo mailbox and module open parameters apply only in a development build (cfg(dev_mode): debug or --features dev-mode); a release build ignores them and logs that once. Desktop --test-action command-line flags are unchanged. - kernel: the launch proxy (makepad.OCTOS_PROXY) applies only in a development build; new `dev-mode` feature, forwarded from the shell through ai-host. - AppCard: every MAKEPAD_* hook (provisioning, seeding, auto prompt, fake GPS, proxy, dumps) goes through `launch_var`, development builds only; new `dev-mode` feature, forwarded from the shell through the module. - OpenHarmony: EntryAbility forwards no launch parameters unless build-home-ohos.py --dev-mode stages it (a separate bundle id required). - Android: Home's `dev-mode` feature comes from build-home.py's `--dev-mode` (App Studio's, #477): standalone only, never the installed Home's identity under its signer, and ROM staging refuses it. So a build that reads launch input is never the installed Home. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Docs and scripts that passed `makepad.*` launch extras to release packages now name a development test build: `rom/scripts/build-home.py --dev-mode` under a separate package name on Android, `build-home-ohos.py --dev-mode` on OpenHarmony, `--features dev-mode` for the desktop mail demo, and `DEV_MODE=1` / `--features dev-mode` for AppCard's own tools. `provision-appcard-llm.sh` requires PACKAGE=dev.makepad.octosense.<suffix>. AGENTS.md states the rule; English and Chinese docs change together. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A desktop's environment is the local user's, like a command-line flag, so `MAKEPAD_APP_CONFIG` (test actions, Mail's demo mailbox, module-open settings) and AppCard's `MAKEPAD_*` hooks are read in every desktop build. The gate applies only on Android and OpenHarmony, where a launch Intent extra or launch parameter can come from another app: there a release build ignores them and only a development build reads them. - crates/shell/src/launch_input.rs: `honoured` keys on `cfg(native_mobile)`; tests say a phone release build ignores it while a desktop build (any profile) and a phone development build read it. - apps/appcard: `launch_set_in(mobile, development, ...)` — a desktop reads the hooks, a phone only in a development build. - Docs restored to plain desktop `cargo run` commands; the phone and OpenHarmony guidance keeps the development-build note. AGENTS.md states the desktop/phone split. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Protects a release Home now, without waiting for a makepad sweep: the shell's pinned makepad gains the Studio/OCTOS_PROXY launch-input gate from OctoSense-org/makepad#119 as the next stacked runtime patch over the pinned base, so a shipped Android Home ignores a Studio host or app proxy from an Intent extra. The OpenHarmony template part of #119 is not carried here, since Home builds its own OpenHarmony entry ability. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Text editing worked on simple PDFs and broke on real-world ones. On a page a
web browser printed, the engine reads a title drawn in several fonts as one
paragraph per piece; text a paragraph's subset font lacks is set in a
stand-in (Helvetica or Times) that runs over the pieces after it; and
Chinese text is refused with the engine's build note ("set CRAFT_FONTS_DIR
to a craft-fonts checkout").
pdf.edit_check takes pdf.edit_text's arguments and answers {keeps_font,
font, box, covers, off_page}: the font the edit would be drawn in, where the
edited text would be, how many other lines it would newly run into, and
whether it would leave the page. It runs the engine's own editor
(pdfcraft-edit's rewrite_block and replace_line, what text_edit runs) on a
copy opened from the open document's working bytes and drops it: no engine
command, nothing written, the read-only and security checks the engine
makes. pdfcraft-edit joins the pins at the same ymote/pdfcraft revision; it
was already in the graph.
pdf.edit_text and pdf.edit_check now refuse in words for a person, still
invalid: ("PDF Tools can't edit Chinese, Japanese or Korean text yet.";
other scripts name the characters; a locked or read-only PDF; a stale
paragraph number).
pdftools_fixture --edit-sample writes a page as a browser prints it: a title
in five pieces in unnamed Type 3 fonts, and Chinese text in an embedded
CID-keyed TrueType subset (glyphs drawn here as placeholders). The tests use
it to hold the check to what the edit then does (same font, same box), and
show the refusals change nothing. Release timings: a check takes 0.4-0.6 ms
on the samples and 16-19 ms on a 3.4 MB browser-printed page of 399
paragraphs.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The Edit panel asks the engine what the edit would do (pdf.edit_check) when
a paragraph is clicked and again when typing, the alignment or the colour
pauses, and says it under the Font box: that the paragraph's font can't show
the new text, so it is set in Helvetica, Times or Courier; that the text
needs more room and runs into N lines nearby; that part of it falls off the
page; or, in red, why the engine won't make it, in the service's plain
words. A paragraph that is one piece of a line the PDF stores in pieces says
how many. While there is a warning Apply reads "Apply anyway"; an edit not
checked as it stands is checked first and made at once only if there is
nothing to say. An older engine without the check edits as before.
The Font box names fonts as a person would ("Menlo Regular", not
"ABCDEF+Menlo-Regular"; "Unnamed font" for a browser's Type 3 fonts).
The model tests cover the new pure functions, and now also parse the whole
script, views and handlers included, which the model VM never ran: one
parse error there fails the whole app when it loads. READMEs in English and
Chinese describe Editing text and the --edit-sample page.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A hidden desktop shell on a headless weston showed the notes pushing Apply and Cancel out of the card in the shell's default window (an app area of 1292 x 662). With notes showing, the card now takes the panel's height: the fields (Font and the notes, Alignment, Colour) scroll, and Apply and Cancel stay at its foot. Without notes it is design 08's card, as before. The notes are shorter, the consequence first: "Set in Helvetica: this paragraph's font can't show all of this text.", "Longer than its box: it runs into 2 lines of text nearby.", "The PDF stores this line in 5 pieces: only this one changes." Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A desktop shell built at c50104d, with the real pdf engine, on the Linux build host's private headless weston (another session was running OctoSense on the Mac), driven over the remote bridge on the --edit-sample page, light and dark, at the runtime's 64 ms script budget: the five-pieces note, the font and room warnings with Apply anyway in view, the plain refusal of Chinese text inline and on Apply, an edit made anyway (the engine's result overlaps as the panel said) and one made at once. Frames cropped to the app's 1292 x 662 area, a receipt, and READMEs in English and Chinese; README's Status lists it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The coordinator's contract text for #501: pdf.edit_check's arguments and answer, its plain refusals, and the correction that an edited paragraph keeps its own font only when that font can show the new text (otherwise the engine draws a stand-in, which edit_check reports first). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ymote
force-pushed
the
fix/pdftools-honest-edit
branch
from
October 11, 2026 18:16
092c084 to
dabda6d
Compare
ymote
marked this pull request as ready for review
October 11, 2026 18:16
Contributor
Author
|
Merged in a train (#488 → #501 → #495) on two local runs of the train head 37008bb, which contains this PR's head dabda6d. Merged in order with
Run 2's table
Notes:
Run 2's first attempt on the same head stopped at one failure outside this train: GitHub's native Windows acceptance ( |
ymote
added a commit
that referenced
this pull request
Oct 11, 2026
Moves the pdfcraft engine and its patched PDF stack from 615ff308 to 51f09eea: ymote/pdfcraft's merge of storytold/pdfcraft main (f22b5d42, 318 commits, ymote/pdfcraft#2) plus the fork's 4 MiB cap on the total of decoded page-label prefixes (ymote/pdfcraft#3), which upstream's code had dropped. All ten pdfcraft pins in the root Cargo.toml move, #501's pdfcraft-edit included. - The lock pins hayro-jbig2 to the engine's hardened copy. Its patch had been unused: crates.io's 0.3.1 outranked the vendored 0.3.0, so JBIG2 images were decoded without the engine's bounds on bitmap and dictionary pixels and on decoding steps that never advance. That also drops second copies of fearless_simd and hayro-ccitt. tests/skill.rs now fails if any of the five patches goes unused or isn't at the engine's revision. - vectorcraft moves to 2cd3a1ca (ymote/vectorcraft#1), whose PDF import takes the warning the engine's hayro-interpret adds (ContentTruncated). The patch reaches vectorcraft-pdf too, which otherwise stops compiling. Only the vector skill's revision lines change. - The pdf skill is regenerated: twelve new engine commands, each classified from its implementation in skill/safety-rules.json, and fill_sign_add is file now (its new `path` reads an image signature). ADR 0013's count of generated ids follows (4,569). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ymote
added a commit
that referenced
this pull request
Oct 11, 2026
Moves the pdfcraft engine and its patched PDF stack from 615ff308 to 51f09eea: ymote/pdfcraft's merge of storytold/pdfcraft main (f22b5d42, 318 commits, ymote/pdfcraft#2) plus the fork's 4 MiB cap on the total of decoded page-label prefixes (ymote/pdfcraft#3), which upstream's code had dropped. All ten pdfcraft pins in the root Cargo.toml move, #501's pdfcraft-edit included. - The lock pins hayro-jbig2 to the engine's hardened copy. Its patch had been unused: crates.io's 0.3.1 outranked the vendored 0.3.0, so JBIG2 images were decoded without the engine's bounds on bitmap and dictionary pixels and on decoding steps that never advance. That also drops second copies of fearless_simd and hayro-ccitt. tests/skill.rs now fails if any of the five patches goes unused or isn't at the engine's revision. - vectorcraft moves to 2cd3a1ca (ymote/vectorcraft#1), whose PDF import takes the warning the engine's hayro-interpret adds (ContentTruncated). The patch reaches vectorcraft-pdf too, which otherwise stops compiling. Only the vector skill's revision lines change. - The pdf skill is regenerated: twelve new engine commands, each classified from its implementation in skill/safety-rules.json, and fill_sign_add is file now (its new `path` reads an image signature). ADR 0013's count of generated ids follows (4,569). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.
Why
PDF Tools' Edit works on simple PDFs and breaks on real-world ones. On a page a web browser printed:
Nothing told the person any of this before Apply.
What
pdf service (
apps/pdf/host-service):pdf.edit_check(new,src/fit.rs) takespdf.edit_text's arguments and answers{keeps_font, font, box, covers, off_page}:It runs the engine's own editor (pdfcraft-edit's
rewrite_block/replace_line, whattext_editruns) on a copy opened from the open document's working bytes, then drops the copy. No engine command runs and nothing is written. The engine's read-only and security checks apply. On a typical page it costs 0.4 to 0.6 ms (release); on a private 3.4 MB browser-printed page of 399 paragraphs (not committed) it costs 16 to 19 ms.Plain refusals.
pdf.edit_textandpdf.edit_checkrefuse in words for a person, stillinvalid:(codes::edit_refused):pdfcraft-editjoins the pins at the sameymote/pdfcraftrevision. It was already in the graph, soCargo.lockonly gains one edge.pdftools_fixture --edit-sample <file>writes a page as a browser prints it. The glyphs are placeholders drawn here, with no font file copied. The page has:It reproduces all three failures. The tests hold the check to what the edit then does (same font, same box), and show that a refusal changes nothing.
PDF Tools (
apps/pdftools/bundle/main.splash):pdf.edit_checkwhen a paragraph is clicked, and again once typing, the alignment or the colour pauses.Docs:
apps/pdftools/README.mdandREADME.zh-CN.mdgain an "Editing text" section, a Status line and the evidence folder;apps/AGENTS.mddescribes the service method.Contract change: proposal for SERVICE.md "Edit"
SERVICE.md isn't changed here, because the coordinator owns it. Proposed text:
What ran
cargo test --locked -p octosense-pdf-service: 68 passed, 1 ignored (timings);first_call1 passed, 1 ignored;skill1 passed.cargo clippy --locked -p octosense-pdf-service --all-targets --no-deps -- -D warnings: clean.cargo test --locked -p octosense-shell --lib pdftools_model: 22 passed.python3 tools/setup.py --check --cargoandbash tools/check-shell-graph.sh -p octosense: ok.python3 -m unittest discover -s rom/tests -p 'test_no_local_paths.py': ok.cargo test --release --locked -p octosense-pdf-service --lib -- --ignored --nocapture timings.--edit-samplepage. It ran atc50104da; the evidence is inapps/pdftools/tests/evidence/edit-20261011/.c50104da.tests/ui.pyfrom PDF Tools on Linux: the journeys on a headless weston, and their evidence #495. It isn't committed yet.Known, not changed here
🤖 Generated with Claude Code