v0.5.0-dev.20260917.2 — you choose how far a redaction reaches

You choose how far a redaction reaches beyond what you marked. Settings ▸ Redaction offers three answers and remembers the one you pick: act only on what you marked; also scrub the copies you cannot see — the document information fields, the XMP packet, stray dictionary strings — which is the default; or act on every occurrence anywhere, including text drawn on pages you never marked.

A match the setting declines to act on is still counted and still named. Narrowing the reach changes what pdfcer edits, never what it tells you, and the report appears off the page where it cannot be mistaken for part of the drawing.

Fixed: the redaction panel's search box was off the bottom of the window. The search field, the find-and-mark button and the match-mode choice were all drawn below the edge of the screen, which left Mark whole page — the widest redaction there is — as the only way to mark anything on the panel whose whole purpose is choosing something narrower.

Fixed: the automated cover on redaction had quietly stopped running. Both driven checks over the one operation that cannot be undone had been passing over themselves since the apply window became a separate window. They drive it again, end to end, and prove the removal on the saved bytes.

Housekeeping: the settings reach the engine at one join point, so a fourth setting added upstream breaks this build rather than defaulting silently; three gates and 4,457 unit tests are green.

v0.5.0-dev.20260917.1 — form fields match Acrobat

The form fields on a page now look and behave the way Acrobat's do, and in Edit mode they can be seen and resized.

A drop-down remembers what was clicked. It did not, in any mode. The options list gave up on the frame the pointer went down rather than the frame it came up, so by the time a click finished there was no list and no row under it. A click is a press and a release, and everything a click needs now survives the gap between them.

The open list is Acrobat's shape. It used to be as wide as its longest label — 57 points of list hanging under a 370-point field — and dressed as an application menu: rounded, shadowed, generously padded. It is now the field's own width, square-cornered, unshadowed, flush against the field, with compact rows and the chosen one on a solid plate.

A list box is no longer drawn as a drop-down. They are two different controls and the file says which is which; the flag never reached the page. A list box now shows its options inside its own rectangle, over what was painted there, and grows a scroll bar the moment the rows do not fit.

A drop-down whose author allowed typing accepts typing. Click the text for a caret with the current value selected, click the button — or press Alt+Down, or F4 — for the same list, and Enter or leaving the field commits. Typing the name of a listed option counts as picking it. Built and unit-tested; not yet driven against the running program, and FEATURES.md says so.

In Edit mode the fields can be seen. The one mode in which a field has to be found was the one mode that drew nothing. Every widget with a rectangle is now outlined there — check boxes, radio buttons, push buttons and signature fields too, not only the ones that can be filled in.

Dragging a handle shows the new size while the button is still down, and all eight handles resize, not only the four corners. The resize arithmetic assumed the handle being dragged was a corner; the four edge handles sit at the middle of an edge, so the opposite corner collapsed and the field came out with no width or no height across the dragged direction.

Nothing above marks the page. A resize preview, a hover row, a focus ring and an Edit-mode outline are all cursor: a picture of the page saved and reopened is identical to a picture of it while it is being edited.

Engine pin fb987cd. Portable zip below — unzip it and run pdfcer-gui.exe; it contains the build folder, so unzipping cannot scatter files.

pdfcer-gui v0.5.0-dev.20260916.3 — form drop-downs answered on the page

Form drop-downs and lists can be answered on the page, and the choices behind them can be edited.

Until now those two kinds of field were the only fillable ones that had to be answered from the side panel — read the question off the sheet, then find the same field again in a list.

What is new

A drop-down or a list is answered where it is drawn. Click the field on the page and its options open beside it. The arrow keys move the highlight and write nothing, Enter or a click answers it, Escape leaves the stored answer alone, and Tab carries on through the form instead of throwing you back into the ribbon. Nothing at all is drawn over a field that is not focused, so a picture of the page is a picture of the document as it will save. The list opens above or below the field and is held to that side, because a list that slid back over the box it belongs to would then take the clicks meant for it.

The choices themselves can be edited after the field is placed. In a choice field's Properties: add, remove, move up, move down, rename what the reader sees without changing what the form sends, sort the list, and choose which entry a Reset returns the field to — including Nothing, which clears it, because a reset to empty is a different instruction from having nothing picked. A repeated sent value is refused by name before anything is written: a fill resolves to the first match, so a second copy of it could never be selected by anyone.

More fields are drawn on the page than were. A widget whose own dictionary does not say which sheet it belongs to used to be missing from the page and fillable only from the panel. The sheet is now found by looking, so those fields appear where they actually are.

A list holding an answer that is not one of its own options no longer earns a baffling refusal. Some files carry a stored answer the option list does not contain — left behind when the choices were edited, or written by another program. Ticking the first box used to be rejected with a complaint naming a value you never touched. The stray answer is now dropped from the selection and the panel says so in words.

Verification

Two of the above are checked by driving the program, not only by tests: one answers a drop-down on the page and reads the value back through the engine, the other proves the reorder arrows are greyed only at the two ends of the list. Both were falsified before being trusted. 61 gates pass with none skipped; the workspace test suite is green. The ~95-minute full driven sweep was not run for this build.

The download

pdfcergui-20260916-1945-fb987cd-d2e8434.zip — unzip it anywhere and run pdfcer-gui.exe. It writes its settings beside itself, so it leaves no trace on the machine and two copies never share state. The same build is in your OneDrive folder pdfcer-gui2; pdfcer-gui1 still holds the previous one.

pdfcer-gui v0.5.0-dev.20260916.2 — print positioning

Printing a drawing that will not fit the paper

The page can be dragged to a new position on the sheet. When a drawing
prints at a scale that loses content, pdfcer places it flush to the corner of
the printable area, and that used to be the only place it could go. Now it can
be dragged in the preview to choose which part of the drawing reaches paper,
with four shortcuts on a new Position tab of the print window: Centre,
which crops evenly on all four edges; Centre horizontally; Centre vertically;
and Reset position, which puts the page back where pdfcer chose. Reset all
pages is a control of its own, carrying a count of how many sheets of the job
are displaced, because a forty-sheet set cleared one sheet at a time is a chore.

Each sheet's position is remembered separately, and survives a change of scale,
paper, orientation, rotation or a press of fit-to-page. The two numbers can be
typed in millimetres or stepped with the arrow keys — a millimetre at a time,
ten with Shift held — and they say what frame they are measured in, because a
displacement with no origin means nothing: from where pdfcer places the page,
positive right and down. Under them is how far the page runs past the printable
area edge by edge, in millimetres. That line is a readout and never a
warning: on a 1:1 CAD drawing the overhang is usually blank paper, and the ink
verdict beside the preview is the surface that gets to claim content is lost.

The preview is a column of its own and stays visible whichever tab is open, so
the picture never hides behind the controls that change it.

The crop hatching marks all four edges. It drew two bands, so a drawing
hanging off the top and the left was hatched on one of them. There are four
now, each clipped to the page so no two overlap.

The print window's tabs are single words — Pages, Copies, Comments,
Position — with the fuller question on hover. A fourth tab would not fit beside
the old names on one row, and a strip that wraps onto a second row costs the
dialog vertical space it does not have.

Under it

The Position controls were first built at the foot of the scale tab. Measured
there, they took the dialog's body 149 pt past its scroll viewport — which is
the vertical scrollbar that was reported as "two scroll bars in the pop up
window that won't go away" — so they moved to a tab of their own, and a driven
regression check now asserts on both axes that the body fits its viewport.

Form fields get their colour, and Tab stops escaping into the ribbon

Four things you asked for, all four in this build.

Form fields have colours now — the box and the ink. Background and
border were already in; the text's own colour is new, and it brought the
font and the size with it. They sit in one group because the file stores
all three as a single string, so changing the colour can't quietly change
the typeface. Size reads Auto when the reader is picking a size to fit
the box. A signature has no text of its own, so it gets no group rather
than a greyed-out one. An ink with no single screen colour — a four-ink
separation — says so instead of showing you an approximation that would
overwrite it the moment you pressed Set.

Pages are drawn before you scroll to them. A band either side of the
page you're reading is rendered while the renderer is idle, so a scanned
sheet is already there when it arrives. Whatever is on screen still goes
first, always.

Placing a form field shows you the field. An outline follows the
pointer at the size the field will be, hung from the corner the click will
hang it from, so what you see and what you get are the same statement.

Tab stays in the document. It walks the form's fields in the order the
form declares, across pages, scrolling the least it can and leaving your
zoom alone. Space ticks a focused check box instead of panning the paper.
On a page with no form, clicking the page and pressing Tab walks the
objects drawn on it.

Housekeeping. Engine re-pinned; 57 gates and 3,520 tests green;
smoke-launched off screen before packaging. None of the four has been
driven through the real binary yet — that's the next batch.

Word table-of-contents links jump without zooming, and stay where you were looking

Table-of-contents links in Word PDFs stop zooming. Click an entry in a
contents page and it jumps to the spot on the page — at the magnification you
had set, not one the file chose for you. Nothing about the view changes except
the position.

It also stops jumping sideways for no reason. If the spot is already on
screen horizontally, the page stays where you were looking. It only moves
sideways when the target genuinely is off to one side.

SolidWorks drawing bookmarks are unchanged. Those name a rectangle, not a
point, so they still frame the area they always did — that behaviour was
deliberately left alone.

Also in this build. One line of text can be dragged on its own: pick a line
inside a block, drag it, and the lines under it stay put. Where a line cannot be
moved the refusal says which of the two reasons applies.

---

Unzip the folder anywhere and run pdfcer-gui.exe. BUILD-INFO.txt records the
build time, the engine revision and the commit.

Verification: the full unit suite and all 57 project gates are green against
this build. The driven end-to-end check for the link behaviour is written but
has not been run — it takes the mouse and keyboard, and the machine was in use.

pdfcer-gui — one line of text moves on its own

One line of text moves on its own

Pick a line inside a block of text, drag it, and only that line moves. Until
this build the whole block went with it, so nudging one line of a title block
dragged the three lines below it along too.

And you no longer have to guess how to get at a line. Right-click on one and
the menu offers that line by name, above the entry for the block it sits in.
Before this, the only route was arming the Points tool with a keyboard chord and
clicking — a gesture nothing in the program mentioned.

Where a line still cannot move, it now tells you which of two reasons applies.
Either the line carries no position of its own and inherits one from the line
above it, or moving it would drag the next line with it. They need different
things from you, so they get different sentences. The old behaviour was one
vague refusal covering both, which is the same as no answer.

What is in this build that has not been tested here

The engine inside this build fixes balloon reference notes whose text the
exporter split across several pieces — the exact case you asked about. It is
fixed in the engine and verified there on your own sheet, six notes. This
project has not yet driven it through the program, so this page will not call
it working until it has.

And one thing that does not follow from the drag: you still cannot delete one
line inside a title block. The engine grew the ability yesterday; the program
does not call it yet.

Housekeeping

Two estimates in the design survey were scored against what actually shipped and
both had under-estimated — recorded rather than quietly corrected. A new build
check catches a class of documentation damage that leaves every other check
green. 57 build gates, 228 driven checks, 4,318 tests, all passing.

Install

Unzip anywhere and run pdfcer-gui.exe. Nothing else to do.

v0.5.0-dev.20260914.5 — scale-by-two-points is proven, and four checks that were lying are fixed

There is nothing in this build you can see. No new button, no changed
behaviour, nothing different on your drawings. It is worth having because the
next build's evidence depends on it — but it is not a feature and this page
will not call it one.

What is actually worth a second of your attention

Setting a drawing's scale by picking two points now has proof that it works.
You pick two points on the sheet, tell it what that distance really is, and the
scale follows. Two automated checks for that have existed for days — committed,
registered, and sitting in the roster looking covered — and neither had ever
once run. Their second pick landed sixteen points past the right-hand edge of
the test page, so both quietly reported skipped every time instead of red.

Driven end to end for the first time today: 399.08 pt measured where 400 pt was
clicked, and the sheet's scale moved from 1:100 to 1:7.81, exactly as it should.

⚠ A skipped check is not a red one. Nothing ever went wrong on a screen and
no build ever failed. A capability you had asked for by name went three days
with two checks guarding it and neither of them running.

The full test sweep was run, and nothing regressed

The previous build changed how every click in the program decides what it hit,
and nothing short of driving the whole suite measures the blast radius of that.
It ran for ninety-five minutes against 226 checks: 190 passed, 5 failed,
31 skipped. The only failure that was not already known by name was a check
being run for the very first time, on an unrelated screen.

Four of those verdicts were then chased to the bottom, and every one of the
four was the check being wrong rather than the program — including one that
accused the text editor of doing nothing while the program's own log, three
lines above the accusation, said plainly what it had done instead.

About the reflow problem you reported

Nothing about it changed in this build. The fix for the part that was
misinforming you shipped in the previous release; your sheet still will not
re-wrap, because the font your exporter used needs engine work that is named in
the backlog rather than waved at. That is unchanged and is written the same way
in FEATURES.md.

---

FEATURES.md inside the zip has the long version, re-measured against this
exact binary.

Engine	pdfcer-core 0.53.0 at 2eb48ff, level with the tip
Driven checks	226 registered
Tests	4,307 passing, 0 failing, 56 ignored
Build gates	57 passing, 0 failing

Clicking text on your drawing now selects the text — so the font controls and the properties fields work

Clicking a piece of text on your SolidWorks drawing now selects the text. That single fault is why the whole font area was greyed out and the properties fields would not take a change — every one of those controls reads the text selection, so a click that picked the wrong thing switched all of them off at once.

• Measured on your own file, page 1 of SW41177. Nine clicks, one per distinct font size on the sheet, each two units inside the label's own box. Eight of the nine used to select a line, not the label — nearly always the same line, the second-to-last thing painted on the page. Now nine of nine select the text.
• The text was never missing. It was in the list of things under the cursor every single time. It was being out-ranked: a line counts as hit within half its width plus a tolerance, and on a sheet 1,584 points wide a few screen pixels of tolerance is several points of paper — enough to reach a cell rule sitting a point away from the label inside it. The rule now is that slack only ever breaks a tie against nothing: something you hit exactly always wins over something you only reached by tolerance. Where you genuinely did click on the line, you still get the line.
• Bold, italic, the font name and the size are live on a drawing you have just opened, and so are the properties fields — including on a line of text the program itself just added.

Re-wrapping a paragraph now re-wraps the paragraph you clicked in. It was working out the right paragraph and then numbering it in the wrong list: the caret sees 144 paragraphs on that page, the re-wrap sees 70. Seventy-four of those numbers were simply out of range and were refused — and the ones that were not out of range were worse, because they were accepted and quietly re-wrapped a paragraph you never touched.

And when it does refuse, it now tells you what the obstacle is. The body text on that sheet is CenturyGothic, which stores more than one byte per character, and re-wrapping that kind of text is not built yet. Until now every refusal on that sheet said "something about how this page was drawn" — which reads like the feature is broken rather than like one class of font is out of scope.

Adding a line of text to a page no longer stops you re-wrapping a paragraph on it. That refusal came from the engine and it is gone at the source. It was also firing on freshly opened SolidWorks sheets that nobody had edited at all, because it was really testing how the exporter had split the page up, not whether you had changed anything.

Housekeeping. The engine moved to 3f416fb. One build gate was found reporting "all clear" over an empty pile of evidence — a folder tidy-up had moved everything it was looking at — and it has been fixed so it says how much evidence it actually read, and reports skipped rather than passed when it has none.

---

How it was checked. 226 automatic checks are registered, one more than the release you have. The nine-aim check over the font controls was driven against a copy of your own drawing and went 9 of 9, up from 1 of 9. The re-rank was disbelieved before it was believed: it was switched off and the four unit tests around it re-run, and exactly one went red — the other three are there to prove it did not break the ordinary case.

4,305 tests pass, 0 fail. 57 build gates are green, 0 skipped. The full ninety-five-minute driven sweep was not re-run for this build; the last complete sweep was 2026-09-13.

⚠ One part of your message is still open, and it is not this release's: splitting a title-block run that the exporter wrote as a single lump, so you can edit one field of it without editing all of them.

v0.5.0-dev.20260914.3 — Print: Cancel really cancels, and Keep and close really keeps

The Print window now has three ways out, and they mean three different things.

• Print sends the job and remembers your settings, as it has since the last-settings work landed.
• Keep and close remembers them without printing. This is the new button, and it is the only way to say set this up now, print later.
• Cancel puts every setting back to what it was when the window opened — which is what you asked for: "a cancel button that doesn't save the changes we made since opening the dialogue and they revert back to what they were when we opened the print dialogue".

The window's X and the Escape key do exactly what Cancel does, and that is deliberate rather than incidental. Those are the two gestures a person makes without deciding anything, so the meaning they carry has to be the safe one: shut the window in irritation and you do not inherit three hundred copies and the wrong tray.

The third part of your message — saving print settings inside the PDF — is not built, because you withdrew it in the same sentence ("if it would make it a special setting that only works with our program, then don't implement it"). It would be a private key no other reader honours. It is written down in the backlog so nobody re-proposes it in three weeks.

Nothing else you can see changed. The rest of this release is a document restamped, a design deleted because it has been built, and a note to the next session.

---

How it was checked. 225 automatic checks are registered, one more than the last release, and the new one is about this button. It is the two-launch kind: it opens Print, changes the paper policy, leaves by Cancel, and opens the window again in a second launch of the program to read what it opens on; then it does the whole thing over and leaves by Keep and close. Cancel must come back to the original, Keep must come back to the change, and — the assertion that does the real work — the two must differ, because a build in which both buttons do the same thing passes every screenshot and every unit test ever written about either of them.

It was disbelieved three times before it was believed: the program was rebuilt with Cancel wired as Keep, with Keep wired as Cancel, and with the two swapped, and it went red on all three, each time naming which mis-wiring it had found.

4,296 tests pass, 53 build gates are green, and the engine pin did not move. The full ninety-five-minute driven sweep was not re-run for this build; the last complete sweep was 2026-09-13.