35 commits

Author	SHA1	Message	Date
andodeki	c1d1e67f3a	feat(pdf): shadings — the sh operator was parsed and thrown away ... ADR 0028, the first of Phase 7's eight bullets. content.rs contained `PdfOp::Shading(_name) => {}`. The operator was lexed, given its own variant, matched during interpretation, and discarded. A page whose background is a gradient rendered as nothing. Nothing caught it for the usual reason: a blank region is a legal thing for a page to contain, so "drew nothing" and "drew what was asked" are indistinguishable without an assertion naming the expected colour. The golden corpus had no shading page, so there was nothing to be wrong. Two of the three pieces already existed — function.rs evaluates the colour function and colorspace.rs converts it to RGB. What was missing was the geometry between them. Sampling rather than a gradient primitive: a PDF shading is defined by an arbitrary function, possibly a sampled table or a PostScript program, and neither reduces to a stop list without loss. A device with a native gradient can still recognise the two-stop case from the samples. "No colour here" is None, not black. Black is a colour a shading can legitimately produce, so returning it for "outside an unextended shading" would paint a rectangle the author never asked for and the caller could not tell the two apart. Types 1-5 exact. Coons and tensor patches are flattened to their corners, which loses the curvature, and is_approximate says so rather than leaving a caller to assume fidelity. An unknown type is refused by number: a mesh drawn as a flat fill is a plausible-looking wrong answer. paint_shading is a new trait method, so the compiler found every implementor. The Makepad renderer records the request in pending_shadings, mirroring pending_xobjects — it cannot resolve a /Shading resource because it does not own the page dictionary, and recording the request is what stops the operator vanishing a second time. That holds even for types we refuse, so a host can warn the user. Four mutations, all killed. The first — discarding sh again — fails three tests. Stated plainly and left unticked: the mesh path is written but NOT exercised by any real stream. shading.rs is at 68% and the uncovered part is exactly parse_mesh and triangulate. Mesh support should be treated as unproven, not working: the code runs and produces triangles, and nothing yet demonstrates they are the right triangles. That is the position image.rs was in before ADR 0016 found the JPEG decoder was a stub. The Phase 7 status line is a table from the start this time — one row per spec bullet, seven of them saying "not started". Per ADR 0021, written before the work rather than after it. pdf: 1321 passed (was 1291). pdf-ui: 1366. Coverage 87.60%, floors met.	2026-08-18 17:30:39 +00:00
andodeki	258fa3259e	Merge origin/main: resolve xref/document conflicts, add makepad_table	2026-08-16 22:53:23 +03:00
andodeki	82eb6b9c73	feat(pdf): internal links that actually go somewhere ... ADR 0017 left destinations.rs at 0% coverage as an open item. The obvious reading is "an untested module". The real one is worse: nothing called it. It was pub use'd from lib.rs and referenced from nowhere else in the workspace. 0% was not a gap in the tests, it was the symptom of dead code, and nothing else was doing the job. Meanwhile PdfAnnotation read a link's target as dict.get_name("Dest") - a *name* /Dest and nothing else. Not /Dest [4 0 R /Fit], and not /A << /S /GoTo /D ... >>, which is how internal links are written in practically every real document. The corpus has had one since Phase 6, in annotations/links.pdf, and no test asserted where it went: Link { uri: None, dest: None } -> action=None Clicking it did nothing. No error, no warning - the viewer got no action and correctly performed none. A link to nowhere and a link the reader cannot parse look identical from outside. The viewer was already wired for this: PdfAction::GoToPage exists, is matched in test_host.rs, and was never constructed by anything. A complete delivery path with nothing at the source. Now: all three legal spellings parse, named destinations resolve through the /Names /Dests tree *and* the pre-1.2 /Root /Dests dictionary, and resolution happens in page_annotations where the catalogue is in reach. XYZ keeps Option per component because null is meaningful there and only there - it means "leave unchanged". Reading it as 0.0 scrolls to the origin at 0% magnification. Zoom 0 means the same as null and is normalised. Lookup uses a deliberate shallow resolve. Deep-resolving a destination array replaces [4 0 R /Fit] with the page dictionary and destroys the only thing identifying the target - the defect that once emptied every AcroForm (ADR 0006) and every annotation reference (ADR 0004). GoToAction now requires /S to be GoTo. The old code ignored /S and took /D from whatever it was handed, so a /GoToR (another file), /Launch (a program) or /JavaScript carrying a /D was reported as a local page jump. Refuse by verb, same policy as ADR 0012. An unresolvable destination is left unresolved, never defaulted to page 0: silently landing on page one is the worst outcome because it looks like the link worked. Seven mutations, all killed. M1 - removing the /S check - reported as surviving on the first attempt. It had not survived: the patch string omitted an interleaved comment so the mutation never applied and I measured the unmutated build. A harness that does not verify its own mutation says "weak test" when the truth is "never ran", and the conclusion would have been to delete a real security check. Every mutation now asserts it applied. destinations.rs 0% -> 98.65%; total 83.42% -> 83.86%. Floors added for destinations.rs and annotations.rs, verified to fail when breached. AnnotationType::Link changes shape (dest: Option<String> -> destination: Option<Destination>) and AnnotationAction gains GoToDestination; the old field could not express an explicit destination, so keeping it meant keeping the bug. AnnotationAction loses Eq because a destination carries f64 coordinates. pdf: 724 passed (was 695). pdf-ui: 769 passed (was 725). ADR 0018.	2026-08-16 19:34:01 +00:00
nigig-ci	34fecf1924	build: pin every git dependency to a full 40-character SHA (Phase 0.2) ... The repo has a CI gate requiring full-length revs, added deliberately in 5e71457 with a comment explaining that an abbreviated rev resolves only while no other object shares its prefix -- a property of the repository's current object count, not a guarantee. Git's abbreviation length grows as a repo grows, so a short pin silently becomes ambiguous, and an attacker able to push to the fork can try to manufacture a colliding prefix. That gate has been failing. 42 declarations across 34 crates used abbreviated revs: 41x rev = "ecf5a572" (the current makepad pin) 1x rev = "5efe6e24c" (map/tests/makepad_test_app, left behind by the ce0eaae bump) Resolved both against the remote and rewrote them: ecf5a572 -> ecf5a572ab62a1c1598909971f602f99083671cc 5efe6e24c -> 5efe6e24c9f732e9f11b783757f196f4f1c402b2 Verified this changes the LABEL and not the dependency: Cargo.lock holds exactly one makepad commit id and zero references to the old one, so nothing was silently upgraded. The stray makepad_test_app pin did move to the current rev, which is the intent -- it pointed at a stale branch head. Cargo.lock also picks up unrelated churn (brotli et al in, makepad-android-state/jni-sys out). That staleness is PRE-EXISTING, not caused by this change: confirmed by stashing every edit and running `cargo metadata` on a pristine tree, which produces the identical diff. Gate now passes: $ grep -rn 'rev = ' --include=Cargo.toml . | grep -vE 'rev = "[0-9a-f]{40}"' (no output)	2026-08-16 18:35:39 +00:00
andodeki	ce0eaae935	fix(build): bump makepad pin to ecf5a572, restoring the test feature ... 86c9595 synced the fork to upstream/dev at abd70f4, which dropped three fork-local optional dependencies from widgets/Cargo.toml and their re-exports from lib.rs. They were fork additions, so the merge lost them. Every Makepad UI target then failed to resolve: package `nigig-pdf-makepad` depends on `makepad-widgets` with feature `test` but `makepad-widgets` does not have that feature. help: available features: default, serde failed to select a version for `makepad-widgets` The "available features" list is misleading: with no `test` feature on widgets 2.0.0, cargo falls back to the stale old/widgets copy, which is 1.0.0 and offers only default and serde. Same fallback that produced the bogus makepad-fonts-chinese-bold error in an earlier sync. libs/makepad_test was never removed - only the manifest entries and the re-export. The fork's ecf5a572 restores both. This bumps all 34 crates. Verified against the real fork, not a local copy: TEST_TARGET=pdf-ui 682 passing (was: failed to resolve) TEST_TARGET=pdf 637 passing Pin bump only: every hunk changes the rev and nothing else.	2026-08-16 17:39:48 +00:00
andodeki	6a18886185	feat(pdf): Type 3 fonts and streaming interpretation — Phase 2 complete ... The last two items of NIGIG_PDF_FEATURE_PARITY_PLAN.md Phase 2. Design and merge criteria in REVIEWS/adr/0014-pdf-type3-fonts-and-streaming.md. TYPE 3 FONTS DREW NOTHING A Type 3 font's glyphs are not outlines - they are content streams, listed in /CharProcs and mapped to text space by /FontMatrix. Probing a document with one: fonts on page: ["T3"] T3: subtype=Type3 base=Unknown -> are the glyph procedures reachable? no CharProcs field exists -> is /FontMatrix exposed? no field exists The font was detected and then nothing could be done with it. /CharProcs and /FontMatrix appeared nowhere in the crate, so the procedures were unreachable and the text was silently invisible - a page that renders, reports no error, and is missing content. New pdf-document/src/type3.rs parses /FontMatrix, /CharProcs, /Differences, /Widths, /FontBBox and the font's own /Resources, and resolves a character code to its glyph procedure's decoded bytes. /FontMatrix is applied as written rather than assumed to be the common 0.001 scale - Type 3 fonts routinely use other matrices, which is the point of the entry. A missing /CharProcs entry is a typed error naming the glyph, not a blank. A THIRD BUG, FOUND WHILE WIRING d0/d1 The interpreter parsed both operators and discarded them: PdfOp::Type3Width(_wx, _wy) => {} PdfOp::Type3BBox(_x1, _y1, _x2, _y2) => {} They are how a Type 3 glyph declares its advance, so even a renderer that could draw the glyphs would stack them all at one point. Wiring them to the device exposed that `d1` takes SIX operands - wx wy llx lly urx ury - and the parser read four, so the "bounding box" was really the advance and the advance was lost entirely. Now `Type3BBox { wx, wy, bbox }`, reading all six. STREAMING INTERPRETATION parse_content_stream materialised every operator into a Vec before interpreting any of them: peak memory proportional to the whole content stream, on a stream walked once and discarded. Adds ContentStreamIter and interpret_streaming, with parse_content_stream reimplemented on top of the iterator so there is ONE tokeniser rather than two that can drift. Equivalence is proven, not asserted: a test compares both paths across every corpus fixture, and a streaming_interpreter fuzz target compares them over arbitrary bytes, which is where a divergence would actually hide. 4 corpus fixtures, 13 acceptance tests, 9 unit tests. Mutation-checked: reverting d0 to a no-op fails glyph_advances_reach_the_device. Phase 2 is now complete; the plan is updated with an item-by-item audit. Several entries were already done (inline images, Do, text state, shading); the plan's "biggest gap" was xref streams, closed in ADR 0013. TEST_TARGET=pdf 615 -> 637, TEST_TARGET=pdf-ui 660 -> 682. rustfmt and clippy -D warnings clean.	2026-08-16 17:28:44 +00:00
andodeki	86c9595729	chore: update makepad fork to latest upstream/dev (abd70f4) ... Updated makepad fork to include all latest APIs needed by map widget: - pack_vector_vertices and VECTOR_PACKED_FLOATS_PER_VERTEX - TileArchiveReader for MKMap archive support - get_tile_decoded method on MbtilesReader - set_trust_fill_winding and fill_fringe_into on Tessellator - retain_queued method on TagThreadPool - set_camera_delta method on DrawRotatedText This resolves all compilation errors in the map widget code.	2026-08-16 17:18:31 +00:00
andodeki	bd01604e65	docs(pdf): Phase 1 status, and stop pdf-ui failing for an environmental reason ... Phase 1 of NIGIG_PDF_FEATURE_PARITY_PLAN.md. Findings verified by running them, written up in REVIEWS/PDF_PARITY_PHASE1_STATUS.md. Three of the five exit criteria are met: the workspace is green on the new rev (pdf 606 passing), both pins are already at 5efe6e24c, and the upstream baseline is documented - libs/pdf_parse is 4,575 lines with no save/write path at all, against nigig-pdf's 25,845 lines with writing, encryption, signatures, structure tree and transparency. nigig-pdf supersedes both libs/pdf_parse and widgets/src/pdf_view.rs; nothing in either is a capability we lack. The remaining two criteria need fork work this repo cannot do. WHY THE UI SUITE CANNOT PASS YET The six #[ignore] markers were removed from pdf-makepad/tests/ui.rs and the docs now claim the suite runs without a Studio hub. The markers went but the tests did not start passing - TEST_TARGET=pdf-ui was simply red. Three layers, each found by fixing the one in front of it: 1. studio/hub/src/build_manager.rs:398 spawns the build with `sh -lc`. The -l makes it a LOGIN shell, which discards the inherited PATH and rebuilds it from /etc/profile, where ~/.cargo/bin does not appear. cargo is not found and the child exits 127 in 0.4s. This breaks any rustup-based CI, not just this sandbox. `sh -c`, or resolving cargo through the CARGO env var, would fix it. 2. Past that the build runs (88s) and the failure becomes 101. libs/makepad_test sets MAKEPAD=headless for the child, but platform/src/os/linux/windowing_backend.rs only knows X11 and Wayland - there is no headless backend and the env var is not consulted. The app selects X11, finds no display, and segfaults (139). This is the real Phase 1 fork task: "terminal/standalone mode" needs a backend, not just an env var the harness sets. 3. Under xvfb-run the app starts properly and OpenGL initialises, so the binary is fine - but the hub spawns its child outside that display. The markers are restored, with a reason pointing at the status document. A red suite everyone knows to disregard stops reporting the next real regression, which is strictly worse than an explicit skip. Also fixes a latent build break this exposed: the fork's app_main! macro expands to #[cfg(native_activity)], a cfg this crate never declares, which is a hard error under -D warnings. Declared as expected-but-unset via [lints.rust] check-cfg rather than silencing unexpected_cfgs wholesale, which would also hide our own typos. One genuine improvement on this rev: pdf-makepad now builds in release inside the workspace. That was previously blocked by a Makepad os::linux feature-unification bug. TEST_TARGET=pdf 606 passing, TEST_TARGET=pdf-ui 651 passing + 6 ignored.	2026-08-16 16:48:02 +00:00
andodeki	c66ffcb303	test: add comprehensive CAD UI tests for all implemented features ... Added 50+ UI tests covering: - Toolbar buttons (tools, export, zoom, rotation, grid, visibility) - Tool selection via click and keyboard - Drawing creation (rect, circle, wall, column, beam) - Undo/redo roundtrip - Selection and deletion - View manipulation (plane toggle, rotation, zoom, workplane rotation) - Snap/ortho/polar toggles - Grid and reference plane buttons - Export buttons (STL, SVG, PDF, OBJ, 3D, CLI) - PDF preview tab switching - Code editor visibility and content - Cost estimation screen - AI pane widgets - File operations - Splitter toggles - Properties panel - Status label text verification - Mobile editor tabs - All CAD tool buttons (arc, polyline, area, quad, polygon, triplane, extend, chamfer) - Render mode dropdown - View toggle button	2026-08-16 13:17:30 +03:00
andodeki	3a23722b79	fix(pdf-makepad): make headless UI tests pass and enable them by default ... Two defects surfaced once the makepad_test harness could drive the widget headlessly: - set_content left interaction.page_index at 0 when the content belonged to another page, so form fields and annotations on page 1 never responded to clicks. Sync the interaction viewport with the content's page index, and pin it with a regression test proving hit testing is keyed by page index. - the widget's area field was not marked #[area], so the Widget derive made set_key_focus focus draw_bg.area() while event.hits tested self.area. KeyDown/TextInput for a focused field never reached the widget; typing into a field now works. The UI suite now runs headlessly through makepad_test with no Studio hub: remove the #[ignore] gates and update the module docs, and correct LABEL_HEIGHT to the measured 28px label height. Full suite: 37 unit + 8 integration + 6 UI tests green.	2026-08-16 13:17:30 +03:00
andodeki	9d647cec8c	build(deps): bump makepad fork rev to 5efe6e24c (makepad-test enabled) ... All 35 Cargo.toml pins move from d82756a to 5efe6e24c on the gitdab fork (portallist base + makepad_test Android adb / standalone terminal wiring). Lockfile regenerated; pdf crates compile against the new rev.	2026-08-16 08:38:18 +03:00
andodeki	54ac36c0f7	refactor(map): use makepad-widgets map feature instead of custom copy ... Updated makepad fork to d82756a which includes latest map improvements: - Baked fills/faces support - Enhanced 3D building rendering - Improved road geometry and elevation - Better theme matching and styling Removed tile_makepad.rs (12k+ lines) and reverted to using makepad-widgets map functionality directly. This avoids maintaining a separate copy and ensures we get all upstream improvements automatically. Changes: - Updated all Cargo.toml files to use makepad fork d82756a - Removed crates/apps/map/src/tile_makepad.rs - Removed tile_makepad module from lib.rs - Reverted tile_disk.rs to use mbtiles_tile_to_overpass_response	2026-08-04 11:22:05 +00:00
andodeki	a994213e8b	feat(pdf): tagged structure tree, and the BMC bug that turned red green ... Phase 8 #7 of REVIEWS/DART_PDF_VS_MAKEPAD_PDF_GAP_ANALYSIS.md ("PDF/UA structure tree"). Design and merge criteria in REVIEWS/adr/0011-pdf-structure-tree.md. Investigating the accessibility gap surfaced four defects in the marked-content operators the structure tree depends on. The first is not an accessibility problem at all. 1. BMC never parsed, and corrupted the colour of everything after it. The dispatcher matched b'B'+b'M' only when the third byte was a delimiter; BMC's third byte is 'C', so the arm never fired. Because the operator was never recognised it never CLEARED ITS OPERAND, and the leftover /Tag shifted the operands of whatever came next: 1 0 0 rg -> RgbFill(1.0, 0.0, 0.0) red /Span BMC 1 0 0 rg -> RgbFill(0.0, 1.0, 0.0) green Tagged documents are precisely the ones containing BMC, so the documents that tried hardest to be accessible rendered wrong colours. This is the fifth instance of the operator-shadowing family already fixed for cm, rg, gs, b/b* and end-of-stream text operators. ADR 0009's every_multi_char_operator_parses_as_itself test exists to stop exactly this - and would have caught it, except BMC was one of two operators excluded from its table as "genuinely unimplemented". Excluding a known-broken operator from the test whose job is finding broken operators is how it survived. The exclusion list is gone. 2. BDC discarded its property list, which carries /MCID - the only link between a run of page content and the structure element describing it. Without it a tree can be parsed but never attached to anything. 3. The op produced by BDC was named MarkContentBmc, and BMC produced nothing. The names were the wrong way round, which is how the missing arm survived review: the enum looked like it had a BMC case. 4. Found while fixing 2: the content lexer had no dictionary support at all. It read `<` as a hex string without checking for a second `<`, so `<</MCID 0>>` parsed as the string "0C0D0". Content streams now parse direct objects properly, bounded at 16 levels; a single `<` is still a hex string and a test pins that. On top of that, new pdf-document/src/structure.rs: /StructTreeRoot, /StructElem trees, /RoleMap resolution, depth-first reading order, /Alt, /ActualText, /E, /Lang, and MCID-to-element lookup. Cycles in /K are cut at the first repeat and reported by object number rather than expanded to the depth bound. Accessibility findings are mechanical checks reported as findings, NOT a conformance verdict: there is no is_pdf_ua and no ComplianceReport, and a mutation-checked tripwire test fails if either appears. Real PDF/UA conformance needs human judgement - whether /Alt text is accurate is not mechanically decidable - so claiming it from six checks would be exactly the overclaim this codebase keeps removing. 7 corpus fixtures, 14 acceptance tests, 22 unit tests, and a parse_content_dict fuzz target for the new object parser. TEST_TARGET=pdf 536 -> 575, TEST_TARGET=pdf-ui 580 -> 619. rustfmt and clippy -D warnings clean.	2026-07-31 22:19:45 +00:00
andodeki	e45a717ce7	fix(pdf-ui): enable the makepad-widgets test feature so ui.rs compiles ... 456cfa5 rewrote tests/ui.rs to import makepad_test through the makepad-widgets re-export, but did not add the `test` feature that gates that re-export, so the pdf-ui target stopped compiling: error[E0432]: unresolved import `makepad_widgets::makepad_test` note: the item is gated behind the `test` feature Enabling the feature alone is not sufficient. The `#[makepad_test]` attribute expands to an absolute `::makepad_test::` path, which resolves only if the crate is also a direct dependency: error[E0433]: cannot find `makepad_test` in the crate root So both are needed, and the manifest now says why - the direct dev-dependency looks redundant next to the re-export and would otherwise be an obvious thing for someone to delete. crates/apps/map keeps the same pair for the same reason. TEST_TARGET=pdf-ui 580 passing (was: failed to compile).	2026-07-31 20:02:29 +00:00
Arena Agent	5e714577fb	ci: require full 40-character SHAs for git dependency revs ... Upstream adopted the makepad fork fix (8fdff3f) but pinned it as `rev = "a79f0dc"` -- a 7-character abbreviation. The pinning gate passed, because it only checked that `rev = ` was present at all. Its own error message has said "Add rev = \"<full-40-char-sha>\"" since it was written, without ever enforcing it. An abbreviated rev resolves only while no other object in the repository shares its prefix. That is a property of the current object count, not a guarantee -- it is why git's own auto-abbreviation length grows with a repo. A short pin therefore degrades on its own over time, and someone who can push to the fork can attempt to manufacture a colliding prefix. For a dependency that executes at build time, that is a supply-chain weakness rather than a style preference. Checked before assuming: a79f0dc currently resolves uniquely in the fork (exactly one matching object), so nothing is broken today. This closes it while it is still cheap. - All 34 manifests expanded to the full SHA a79f0dce4d477e2232344facca0798d3f25043ec. Cargo.lock is unchanged by the expansion, confirming it is the same commit and purely notational. - The gate now also rejects any rev that is not exactly 40 hex chars. Negative-tested: restoring the 7-char form makes it fire. 685 lib tests pass; all nine gates pass.	2026-07-31 19:53:49 +00:00
andodeki	456cfa5a68	fix: use re-exported makepad-test from makepad-widgets ... Remove direct dependencies on makepad-test and use the re-exported version from makepad-widgets instead. This avoids path dependency issues and follows the correct pattern for using Makepad crates. Changes: - Add 'test' feature to makepad-widgets dependencies - Remove direct makepad-test dependencies - Update imports to use makepad_widgets::makepad_test Affected crates: - crates/apps/map - crates/apps/pdf/pdf-makepad - crates/apps/spreadsheet/spreadsheet-ui	2026-07-31 19:49:54 +00:00
andodeki	8fdff3ff55	Update makepad fork to a79f0dc (remove duplicate dependencies) ... Commit a79f0dc fixes the duplicate dependency declarations that were causing TOML parsing errors. This is the correct commit to use after the parallel fixes in 5eda8056 and 11375214. All 34 Cargo.toml files updated to reference the correct commit.	2026-07-31 19:43:08 +00:00
Arena Agent	80425bbfb8	fix: repair the makepad fork and unblock the build ... The repository has been uncompilable since the d6d1f99c fork bump. Root cause was in gitdab.com/andodeki/makepad, not here, so the fix went there first: commit 5eda8056 on portallist_flow_adaptive_view. TWO defects, both introduced by the "Update fork to upstream dev 5d4483f" merge, both pure losses rather than intentional changes: 1. widgets/Cargo.toml: the makepad-gltf / makepad-csg / makepad-test dependency lines were relocated from [dependencies] to below [features]. Cargo then parses each as a feature whose value should be an array, giving "invalid type: map, expected a sequence", and the gltf/csg/test/maps features cease to exist. 2. widgets/src/lib.rs: the feature-gated re-export block for those same crates (plus makepad_fast_inflate and makepad_mbtile_reader) was deleted outright. Fixing only the manifest surfaced this as "no `makepad_csg` in the root". Both restored verbatim from 2c5cd97, the last rev that resolved. Neither is a judgement call: the moved lines are byte-identical and the deleted block is copied back unchanged. This repo is then repinned from d6d1f99c to the fixed rev, full 40-char SHA per the pinning convention CI enforces. Verified end to end after removing the local git redirect used during development, so this resolves against the real remote: cargo metadata resolves nigig-build --lib 685 passed cad_integration 154 passed spreadsheet-engine 225 passed doc-engine 53 passed nigig-map (maps feature) compiles Cargo.lock unchanged, --locked passes Also resolved committed conflict markers in two workflow files, which had made nigig-build.yml invalid YAML -- the CI config could not be parsed at all: - nigig-build.yml: kept --include='*.rs' on the by-value-getter gate. Without it the gate scans ARCHITECTURE.md and fails on its own documentation, which is the bug fixed in 4f32b1c. - pdf.yml: kept upstream's side. Enumerating targets via `cargo fuzz list` and failing when the list is empty is strictly better than a hardcoded target list that silently passes vacuously if a target is renamed. That makes four files in three commits now carrying committed conflict markers from this merge. Worth checking how they are reaching main -- `git diff --check` catches exactly this and is already a step in the nigig-build workflow, but it only runs on paths under that workflow's filter.	2026-07-31 19:32:08 +00:00
andodeki	4eebae14f2	Update makepad fork to 11375214 (Cargo.toml fix) ... - Fixed TOML parsing error where fork-specific dependencies were in wrong section - Dependencies now correctly placed in [dependencies] before [features] - Maps feature should now be properly recognized	2026-07-31 19:24:22 +00:00
andodeki	d8d29c226d	feat(pdf): transparency, and four operator-parsing bugs it exposed ... Phase 8 #5 of REVIEWS/DART_PDF_VS_MAKEPAD_PDF_GAP_ANALYSIS.md ("Advanced transparency"). Design and merge criteria in REVIEWS/adr/0009-pdf-transparency.md. The headline defect was not that transparency was missing. `gs` was MIS-PARSED as CloseStroke: /GS0 gs 1 0 0 rg 100 100 200 200 re f -> [CloseStroke, RgbFill, Rectangle, FillWinding] so every page setting a graphics state gained a stroked path the document never asked for, and lost its alpha, blend mode and soft mask silently. Downstream everything was dead: StrokeExtGState/FillExtGState were never constructed, set_fill_opacity was never called and emitted no command when it was, and PdfPage::ext_gstate was read by no code at all. New pdf-graphics/src/transparency.rs: full /ExtGState (ca, CA, BM, SMask, LW, LC, LJ, ML, D, AIS, TK), all sixteen blend modes including the four non-separable ones, soft masks with /S, /G, /BC and a /TR evaluated through ADR 0006's PdfFunction, and /Group parsing. Wired end to end: parser -> PdfOp::SetExtGState -> device -> RenderCommand -> Makepad renderer. Compositing is NOT claimed. Backdrop blending needs render-to-texture, which an engine-neutral crate has no framebuffer for. Constant alpha is applied because it needs no backdrop; blend modes and soft masks are reported through TransparencyError::Unsupported rather than dropped, because a silently ignored /Multiply looks exactly like a correct /Normal. The ADR required a test enumerating every multi-character operator, on the grounds that fixing the third instance of a shadowing bug (after cm and rg) without preventing the fourth is not a fix. It immediately found three more live bugs, none of them transparency-related: - `b` and `b*` dropped their close-path, mapping to FillStroke* instead of CloseFillStroke*, so every closed-and-stroked path drew with a gap. - Text operators within three bytes of the end of a content stream were mis-parsed: the b'T' arm guarded `*i + 3 < len` while reading only two bytes, so a stream ending in `/F1 12 Tf` parsed as FillWinding. And the transparency-group fixture found a fourth: - PdfPage::xobjects was empty for every page of every document. extract_xobjects called doc.resolve(), which follows the reference, then asked the resolved object for as_ref() - always None - and only accepted a bare dict when every XObject is a stream. No `Do` operator could be resolved through the page model. Same defect as the one that once destroyed annotation object references; it now has its own regression test. T* and BMC are genuinely unimplemented and are deliberately excluded from the guard's table rather than papered over. 7 corpus fixtures, 12 acceptance tests, 32 unit tests asserting the §11.3.5 formulas (not our own output), and a parse_ext_gstate fuzz target. TEST_TARGET=pdf 451 -> 497, TEST_TARGET=pdf-ui 495 -> 541. rustfmt and clippy -D warnings clean.	2026-07-31 18:58:31 +00:00
andodeki	8c9ccb92cc	Update makepad fork to latest dev branch (d6d1f99c) ... - Sync with upstream commit 5d4483f (latest map improvements + platform updates) - Include location API, audio echo cancellation, bridge-dz overlay - Add new libraries: geodata, map_nav, i_float, i_shape, i_tree, converse, llama vision - Preserve all fork-specific re-exports (gltf, csg, test) - All 102+ map improvements now available: 2D/3D toggle, shadows, labels, overlays, pattern fills	2026-07-31 18:47:37 +00:00
andodeki	bea1fd884e	chore: update makepad fork to include upstream map improvements ... Updated all makepad dependencies from rev 2c5cd97 to 817d881 which includes: - Terrain hillshade landcover draping (drape.rs) - Route overlays, markers, and position puck (overlay.rs) - Map icon management system (icons.rs + 50 SVG icons) - 3D road elevation and seamless joins - Building shadow geometry and terrain shadows - Night themes and emissive roads - Water, grass, and shrub rendering - Optimized road geometry with 2D/3D mode transitions - i_overlay library for polygon boolean operations This brings nigig-map in sync with the latest makepad dev branch improvements.	2026-07-31 18:39:39 +00:00
andodeki	7d21532ebf	feat(pdf): real colour spaces, ICC profiles and PDF functions ... Phase 8 #4 of REVIEWS/DART_PDF_VS_MAKEPAD_PDF_GAP_ANALYSIS.md ("Advanced colour"). Design and merge criteria in REVIEWS/adr/0006-pdf-advanced-color.md. The interpreter tracked only the *name* of the active colour space and then passed sc/scn operands to the device as if they were already RGBA. Every non-device space therefore rendered a confident wrong colour with no error: /Spot cs 1.0 scn full tint of a spot ink -> pure red /Idx cs 3 scn palette entry 3 -> near-black /Lab cs 50 0 0 scn mid gray -> white (clamped) /DevN cs (5 inks) five colorants -> inks 5+ discarded /ICCBased profile-defined colour -> profile discarded DeviceCMYK also used the additive 1-c-k conversion, which crushes any colour printed over black. Three new modules in pdf-graphics: - function.rs PDF functions, all four types. Type 4 runs on a bounded interpreter: depth 32, 32768 tokens, stack 100, 100000 steps, and an unknown operator is an error rather than a no-op that would leave a plausible wrong colour. - icc.rs ICC matrix/TRC and gray kTRC profiles, applied exactly. LUT-class profiles are reported as such and the caller falls back to /Alternate; they are never pretended to be matrix profiles. - colorspace.rs All eleven families, converting through XYZ with Bradford adaptation and a real sRGB transfer function. Wiring: - PdfDevice gains set_stroke_components/set_fill_components, so SC/SCN reach the device as components of the active space instead of being read positionally as RGBA. - cs/CS now resets to the space's initial colour (table 74), which is why golden/colors.txt gains a line. - PdfPage::color_spaces carries /Resources /ColorSpace fully dereferenced with streams decoded; a half-resolved space would make every ICC profile, palette and type 0/4 transform silently fall back. - A space that cannot be resolved keeps the previous colour and records a typed ColorError. No colour is invented, and no error is swallowed. Tests: 12 corpus fixtures under tests/corpus/color/, 14 acceptance tests in pdf-document/tests/color.rs asserting numeric RGB (the broken code produced a colour for every one of these; only the value was wrong), plus unit tests per function type and per curve type. Two fuzz targets added: eval_function and parse_colorspace. TEST_TARGET=pdf 387 -> 447 passing, TEST_TARGET=pdf-ui 431 -> 491. rustfmt and clippy -D warnings clean.	2026-07-28 20:48:55 +00:00
andodeki	60db0f21db	build: update Nigig to Makepad dev reexport fork	2026-07-28 17:14:18 +00:00
Arena Agent	b5471e32e3	fix(cad): make the crate buildable, testable and safe to ship ... Phases 0-2 of CAD_ASSESSMENT_AND_PLAN.md. The crate did not compile and no test had ever run; it now builds clean with a green suite. Build and CI (Phase 0) - Pin all 33 git dependency manifests to an explicit rev. A branch dependency re-resolves on every build and is a code-execution path into CI if force-pushed. - Commit Cargo.lock (540 packages). Producing it required fixing three resolution failures the workspace had always had: a non-existent makepad-widgets feature, two rusqlite versions both linking sqlite3, and four missed CellId call sites in spreadsheet-ui. - Add .forgejo/workflows/nigig-build.yml. - Replace five stale CAD docs that contradicted the code with one ARCHITECTURE.md; add PHASE0/1/2_STATUS.md and TEST_BASELINE.md. Correctness (Phase 1) - Rotation units: transform_point bound sin_cos() backwards, transposed X and Z, and applied axes in reverse order, so every exported STL was wrong even at zero rotation. It now shares the renderer's matrix helpers. - GLB quaternions had norm 0.125 (half-angle applied to cos/sin, degrees read as radians) - invalid per the glTF spec. - PDF wall/door/window yaw fed degrees to cos/sin. - Fix a TOCTOU unwrap in touch picking; viewport.rs now has no unwrap(). - CommandContext gains update_node/insert_node_at/node_index: resize and modify were delete+create, silently moving nodes to the end of the scene. - Wire MAX_UNDO_LEVELS (defined, exported, never read) and switch the undo stack to VecDeque; this also made the existing drag-merge logic reachable. - CadNode::size() returned a fake 1x1x1 for CSG and extruded solids, making them unpickable outside a 1x1x1 box at their origin. - Reject non-finite script input; makepad_csg clamps NaN rather than propagating it, so bad input produced silently wrong geometry. Test baseline: 0 -> 722 passing, 0 failing - 17 pre-existing failures fixed: 10 real defects (dependency-cycle detection, over-allocation of unassigned tasks, quote/backslash corruption on save, default rooms lost for all but the first region, RGA text ordering) and 7 tests that were themselves wrong, each checked against its production caller first. Security (Phase 2) - env!("CARGO_MANIFEST_DIR") was used as a runtime path in three places, including as the AI agent's working directory. All runtime data now goes under app_data_dir(). - Remove the hardcoded LAN LLM endpoint. It is now opt-in via NIGIG_CAD_LOCAL_OPENAI_URL/_MODEL and refuses plaintext HTTP to anything but loopback. - Bound and content-sniff AI image attachments (8 MB cap, magic bytes); the MIME type came from the filename extension. - Escape SVG/HTML output, and add SRI to the exported viewer's script tag. The pinned model-viewer@3.5.1 does not exist, so every exported viewer was silently broken; now 4.0.0 with a verified hash. - Stop embedding $USER in exported PDFs and logging document content in release builds. - CI now rejects reintroducing the runtime-path and hardcoded-endpoint classes; both gates were verified to fail on a reintroduced defect. Add system_prompt.md and embed it with include_str!. The file was missing from the repository, so the agent silently used a one-line fallback.	2026-07-28 16:49:30 +00:00
andodeki	d3ccc2e00f	test(pdf): close the three gaps carried from Phases 4 to 7 ... Three items were carried forward as known gaps rather than quietly dropped. This addresses all three; two are closed outright and one is bounded by an environment limit that is now documented rather than implied. 1. Fuzzing had never actually run (Phase 6 step 6.3). The five cargo-fuzz targets were only compile-checked, so "zero panics on arbitrary input" was an aspiration. They have now been run under nightly libFuzzer: parse_object 1,970,750 runs parse_xref 2,471,345 runs decode_stream 1,120,019 runs parse_content_stream 2,655,663 runs parse_document 2,381,367 runs About 10.6 million executions in total, no crashes and no new findings. That is a real result rather than a green checkmark: the three crashes the corpus found in Phase 6 were the ones worth finding, and the fuzzer confirms the fixes hold under adversarial input. 2. Combo dropdown overlay (Phase 4 step 4.3). A combo box that cannot be opened is a text field with extra steps, so the open list is real state, not a rendering detail. Clicking a combo box opens its options; the dropdown takes a click before any field underneath it, matching the draw order; choosing a row sets the value through DocumentFormEditor; clicking elsewhere dismisses it without changing the value. render_open_combo() returns placement data so the drawing code stays trivial and the geometry is testable without a renderer. 3. Makepad event delivery. Upstream added a makepad_test framework, so this is now testable in principle. Adds a test host binary and six UI tests that drive the widget through the Studio protocol: a real click on the fixture link must surface OpenUri on the host, typing must reach the field, and a click on empty space must emit nothing so the positive assertions are not vacuous. They are #[ignore] by default because the Studio hub cannot start an app in this sandbox: the harness launches with --stdin-loop, which Makepad refuses without a Studio websocket, and the build exits 101 before startup. Upstream own spreadsheet-ui and map UI suites fail identically here with the same error, so this is the environment rather than this code. The tests are checked in and compiled by cargo test so they cannot rot, CI runs them where a hub exists, and the module documents how to run them by hand. Getting there also fixed a real defect in the test host: it copied ui.main_view.render() from the spreadsheet app startup hook, but a plain View has no render method, so the app errored at startup. Validation: TEST_TARGET=pdf ./tools/test-rust-clean.sh (270 tests) TEST_TARGET=pdf-ui ./tools/test-rust-clean.sh (321 tests, 6 ignored) cargo +nightly fuzz run <target> -- -max_total_time=60 (5 targets) Both rustfmt and clippy -D warnings clean.	2026-07-27 18:09:57 +00:00
andodeki	1c7dc9e9c0	feat(pdf): complete Phase 7 performance work ... Phase 7 of REVIEWS/DART_PDF_VS_MAKEPAD_PDF_GAP_ANALYSIS.md, taken only now because the review is explicit that it comes after correctness is proven. The caching and threading live in pdf-graphics rather than the Makepad crate because none of it needs a GPU. That is what lets the staleness, eviction and cancellation rules be tested without a window; the widget keeps only the parts that genuinely need a Cx. Step 7.1, off-thread parsing (new pdf-graphics/src/worker.rs): - RenderWorker interprets content streams on a background thread and returns results tagged with the Generation they were requested for. - PendingPages tracks in-flight pages so the widget can draw a placeholder and never queues the same page twice. - Drop joins the thread rather than detaching it: a detached thread writing into a dropped channel is the kind of shutdown race that surfaces as a flaky test months later. - A content stream that fails to parse yields an empty page, so one broken page cannot take down the document. Step 7.2, texture and memory management (new pdf-graphics/src/cache.rs): - PageCache is an LRU keyed by page index with a byte budget, not an entry count: one image-heavy page can outweigh fifty text pages, so counting entries would evict the wrong things. - retain_around() releases pages that scrolled out of view, keeping a margin so a small scroll does not immediately re-render. - Decoding produces DecodedImage bytes off-thread; GPU upload stays on the UI thread. - A page larger than the whole budget is still stored, since refusing it would mean re-rendering it every frame. Step 7.3, render command cache: - CachedPage holds the interpreted Vec<RenderCommand>, so replaying a page skips re-parsing its content stream. - invalidate_appearance() marks a form edit dirty without discarding the commands, because a form edit changes what is drawn over the page, not the page content stream. Widget wiring: PdfPageWidget carries a generation, refuses PageContent from a superseded document, and draws a placeholder while a page is still rendering. Exit criterion (new pdf-document/tests/phase7_exit_criterion.rs, 9 tests) against a new 60-page corpus fixture. Measured here: first page 3ms against the 200ms budget, and a warm cache read 389x faster than re-parsing (1us vs 389us). The budget is deliberately loose because a shared CI runner is unpredictable and a flaky performance test gets muted, and a muted test is worse than none; it still catches the order-of-magnitude regression the review is guarding against. Memory is asserted bounded across 30 document switches, and every page of an abandoned document is refused. Validation: TEST_TARGET=pdf ./tools/test-rust-clean.sh (270 tests) TEST_TARGET=pdf-ui ./tools/test-rust-clean.sh (307 tests) Both rustfmt and clippy -D warnings clean.	2026-07-27 17:30:50 +00:00
andodeki	eacc86077e	feat(pdf): complete Phase 5 font engine and text metrics ... Phase 5 of REVIEWS/DART_PDF_VS_MAKEPAD_PDF_GAP_ANALYSIS.md. Step 5.1, real metrics (new pdf-graphics/src/sfnt.rs): - Reads head, hhea, OS/2 and hmtx from embedded TrueType/OpenType programs, which the review asks for by name. sTypoAscender/Descender are preferred over hhea when non-zero, since subset fonts often zero them; sCapHeight and sxHeight are only read from OS/2 version 2 and later, because reading them from a v1 table returns whatever bytes follow it. - Every read is bounds-checked. A table pointing outside the file, a truncated directory or a zero unitsPerEm yields None rather than a panic or a divide by zero. These are untrusted embedded programs. - resolve_font() now reads FontFile/FontFile2/FontFile3 and falls back to the descriptors declared Ascent/Descent only when no program is embedded. - renderer.rs looks up a per-font ascent instead of leaving ascent_em permanently None, which had left the fallback ratio always in effect. Step 5.2, accumulated advances (new pdf-graphics/src/advance.rs): - measure_advance() implements PDF 32000-1 9.4.4 properly: (w0/1000 * Tfs + Tc + Tw) * Th/100, with Tw restricted to single-byte code 32. Applying Tw to a two-byte code whose low byte is 32 is a classic composite-font bug and is now covered by a test. - glyph_advances() gives per-glyph widths so a caret or a partial selection rectangle no longer assumes even spacing. - GlyphAdvanceCache is keyed by font name and size as the review specifies, and carries a generation so it rebuilds when page data changes rather than every frame. Redefining a font drops its stale measurements. Step 5.3, composite fonts: - The old build_cid_widths truncated every CID to u8, so any glyph above 255 silently took the default width. It is replaced by CidWidths keyed by the real CID, with the CMap resolved from a predefined name or an embedded stream. - ResolvedFont::decode_text returns None for a composite font with no ToUnicode map instead of guessing Latin-1 and producing plausible nonsense. Tests: new tests/phase5_exit_criterion.rs asserts the exit criterion. Selection across a proportional and a monospaced run verifies the second run starts at the first ones true end; per-glyph advances sum to the run advance and H measures wider than l, which an even-spacing estimate would not. Copy returns correct Unicode through ToUnicode including a non-ASCII scalar, and through WinAnsi for simple fonts. Search finds both hits across two lines with rectangles inside their own runs and the right vertical order. Cache reuse is asserted through hit and miss counts. Validation: TEST_TARGET=pdf ./tools/test-rust-clean.sh (203 tests) TEST_TARGET=pdf-ui ./tools/test-rust-clean.sh (238 tests) Both rustfmt and clippy -D warnings clean.	2026-07-27 16:51:18 +00:00
andodeki	8bc94253ff	feat(pdf): complete Phase 4 with an interactive page widget ... Phase 4 of REVIEWS/DART_PDF_VS_MAKEPAD_PDF_GAP_ANALYSIS.md. The previous commit added the interaction logic but left it an orphan: nothing routed Makepad events into it, which is the exact defect the review names when it says PdfPageView declares is_interactive() -> false and an empty handle_event. New pdf-makepad/src/page_view.rs, PdfPageWidget: - is_interactive() returns true and handle_event routes real events. - Step 4.1 ordering: form field events, then annotation hit testing, then text selection. The order is enforced inside InteractionState::click so it cannot drift between the widget and the tests. - Step 4.2: link underlines and form widget borders are drawn, and the cursor changes over links and text fields. - Step 4.3: field values draw inside their widget rects, a focused field is highlighted and shows its uncommitted buffer. - Step 4.4: navigation is emitted as PdfPageAction to the host. The widget never opens a URL (rule 5). - Key focus loss commits the pending edit, so an edit is never silently lost, while Escape still abandons it. - Only keys the editor handles are consumed; everything else falls through to the host instead of being swallowed. The widget keeps no decision logic of its own: it syncs the viewport from its on-screen rect and delegates. That keeps the part that needs a live Cx as small as possible, because it is the part that cannot be unit tested. Also adds Selection to interaction.rs so drag-to-select and copy read through the Phase 5 PageText API rather than re-deriving positions. Tests: new tests/phase4_exit_criterion.rs drives the exit criterion against the real two-page AcroForm fixture, not synthetic dictionaries. Click a link gives OpenUri; click a field, type, commit, and the value changes, the appearance regenerates with the new text and the draw list shows it. It also asserts an abandoned edit changes nothing, the checkbox uses the /On state declared in the file, and form fields route before annotations. Validation: TEST_TARGET=pdf-ui ./tools/test-rust-clean.sh 202 tests pass; rustfmt and clippy -D warnings clean.	2026-07-27 16:36:34 +00:00
andodeki	66c7590d66	feat(pdf): start Phases 4 and 5, and make pdf-makepad compile ... Phases 4 and 5 of REVIEWS/DART_PDF_VS_MAKEPAD_PDF_GAP_ANALYSIS.md. pdf-makepad had never compiled. It was missing eight PdfDevice methods, had a non-exhaustive RenderCommand match, called a function through the wrong path and held a borrow conflict. Everything previously claimed about the Makepad rendering path was therefore unverified. It now builds and is tested under a new pdf-ui target; the makepad build needs system GUI libraries, so that target checks for them with pkg-config and names the missing packages rather than failing in the linker. Phase 4 (new pdf-makepad/src/interaction.rs): - Viewport maps between PDF space (y up) and screen space (y down) in one place, so hit testing and rendering cannot disagree. Inverted /Rect corners are normalised. - Click routing follows the review order: form fields first, then annotation hit testing. A field overlapping a link takes the click. - Clicking a link emits PdfAction::OpenUri to the host. The viewer never opens a URL itself (rule 5). - Text editing is buffered: typing changes a working copy and only Enter, Tab or blur commits it, so Escape abandons an edit with the document untouched. Caret arithmetic is in characters, not bytes, so a non-ASCII value cannot panic. - Checkboxes toggle on click using the state the widget declares. - Hover reporting for cursor feedback; read-only fields are not targets. - render_fields() returns placement data so a focused field shows its uncommitted buffer while drawing stays trivial. Phase 5: - New pdf-graphics/src/cid.rs: composite font support. Codespace ranges give variable-width code decoding (the previous CMap was u8 to char, so every two-byte CID font decoded as garbage), plus cidchar/cidrange, ToUnicode bfchar/bfrange including array destinations and multi-character values such as ligatures, /W and /DW CID widths, and Identity-H/V. An unknown predefined CMap returns None instead of silently substituting Identity; unmapped codes decode to U+FFFD instead of vanishing. Width ranges are bounded so a malformed /W cannot exhaust memory. - New pdf-graphics/src/text.rs: the PageText extraction API. Segments carry origin, advance and font size; find() returns matches with rectangles; selection spans runs and works in either drag direction. Runs sharing a baseline stay on one line even with mixed font sizes. - renderer.rs: the two unexplained `fs * 0.75` constants are replaced by a named DEFAULT_EM_TO_CAP_RATIO used only as a fallback, with the real ascent preferred when the descriptor supplies one. Ts (text rise) was stored but never applied, so superscripts drew on the baseline. Also fixes clippy across pdf-makepad, which had never been linted. Validation: TEST_TARGET=pdf ./tools/test-rust-clean.sh (167 tests) TEST_TARGET=pdf-ui ./tools/test-rust-clean.sh (191 tests) Both rustfmt and clippy -D warnings clean.	2026-07-27 16:21:37 +00:00
andodeki	af4ef6f170	fix(pdf): restore a compiling, warning-free PDF baseline ... Phase 0 of REVIEWS/DART_PDF_VS_MAKEPAD_PDF_GAP_ANALYSIS.md requires a clean baseline before any feature work. The four pdf crates did not compile at all, so every test claim about them was unverified. Compile fixes: - decode_lzw/decode_run_length returned Vec<u8> where callers expected PdfResult, so decode_stream_with_params did not type-check. - interpret_ops called a current_state_mut() method that PdfDevice does not have; colour-space tracking now goes through explicit device hooks. - image.rs used miniz_oxide without depending on it; PNG inflate now reuses the COS crate through a new pdf_cos::filter::inflate_zlib. Correctness fixes found while making the code build: - LZW and RunLength silently truncated malformed input and indexed unchecked; both now return typed errors (rule 6: no silent degradation). - Tw/Tc/Tz were parsed and thrown away, and the " operator dropped its word and character spacing, so every advance after them drifted. - TJ attached each kern to the preceding string instead of the following one and discarded a trailing kern entirely. - GlyphWidths::width() fell back to default_width for out-of-range codes; PDF 32000-1 9.6.2.1 requires /MissingWidth. - Text advances silently substituted a guessed font_size * 0.6 when no width table was present; ShowTextWithMetrics now carries advance_is_measured so callers can distinguish a measurement from an unknown. Tests: two tests had never compiled and were wrong once they ran (WinAnsi 0x99 is U+2122 not U+2019; q/cm/l/Q records four commands not three). The document test asserted only that the writer emits a %PDF header; replaced with real page-tree, out-of-range and malformed-input coverage. Adds a pdf target to tools/test-rust-clean.sh that tests the three UI-independent crates bottom-up under rustfmt and clippy -D warnings. Validation: TEST_TARGET=pdf ./tools/test-rust-clean.sh 72 tests pass; rustfmt and clippy -D warnings clean.	2026-07-27 15:33:15 +00:00
andodeki	62dada264e	build: consume Makepad sibling APIs through widgets	2026-07-27 04:22:42 +00:00
andodeki	e73def6d1b	build: align Makepad dependencies with Robrix fork	2026-07-27 03:32:08 +00:00
andodeki	a2ea0ffc7c	updated map	2026-07-26 18:00:48 +03:00
andodeki	cc05abdc71	Initial commit	2026-07-26 19:38:26 +03:00