Milestones and future versions

[Ryokoxx]

Steve - taking you up on the new thread.

First up, congratulations on 1.8. A new engine, the .NET 10 move and the PdfSharpCore migration in one release, then 1.8.1 out the next day and straight into 1.8.2. It looked relentless from out here. It's been my daily PDF app the whole way through and it's holding up.

Before the rest of it: this is your project and the calls are yours. What follows is a few questions and a couple of suggestions, not a plan I'm putting to you. If any of it is something you've already thought about and ruled out, "no" is a complete answer and I won't bring it up again. No rush either, you've got 1.8.2 bugs in front of you.

Milestones

You already write a theme for every release twice, once in the milestone description and once in the first line of the release notes. It just never gets a name. If they were named up front, something like 1.8.2 Polish, 1.9.0 Inspection and Print, 2.0.0 Cross-Platform, it'd tell the rest of us what each release is for. I reckon it'd also make it easier for you to say "not this one, that's 2.0". The patch milestones are the ones with nothing on them at all.

Related, and the one I'd most like an answer to: does 1.9 survive? It has eight issues on it and a real description, preflight and page boxes and colour management and separation preview. But you also said you might skip 1.9.x and go straight to 2.0. If it gets skipped, does that work move onto 2.0, or go back in the pile? Asking because it's print-production work and that's the end of the app I use hardest.

2.0

The ADRs have been the most useful thing you've put out for following where this is going. Better than a roadmap would have been. Two things they don't cover yet.

How are you thinking about the native dependencies? You said on #270 that PDFium and Tesseract are x64 native and PDFium has no ARM64 binary. Linux and macOS hit the same wall. ADR-001 deliberately keeps the engine clear of all of it and leaves rendering with PDFium, so from out here that looks like the thing that decides how far 2.0 can actually go, and it's the part you haven't written up.

Does the WPF shell stay as the Windows front end, or does that get replaced too? Straight self-interest on this one. You said you take theme and layout fixes readily, and I'd rather not spend a month on XAML you're about to throw away.

Making it easier for people to help

One suggestion, and it's built on something you've already done. TRANSLATING.md is short. It's the file format, the language tags, and not much else. Translation is now the one part of this project with a real community around it, fifteen languages, and it's also the only part with a written way in.

There's no equivalent for code, and the odd thing is you've already written most of it. What you told me on #239 about the 260px options column, the MinWidth of 720, the gutter being deliberate, that you take theme and layout fixes readily and you're slow on anything that adds a dependency, that you'd rather have a PR quickly than have a release held open. That's a contributing guide. It's sitting in a comment where nobody will find it, and it'd be about the same length as TRANSLATING.md.

None of that's me telling you how to run it. It's what you already did with the translation doc, pointed at code instead.

One offer, no strings

You've called 2.0 the real Acrobat killer. I've been keeping a running list of things other PDF tools do that KillerPDF doesn't, from using them side by side in a paper-heavy business. Mostly print. It's not a proposal, it's just notes. If it's useful when you start scoping 2.0, say the word and I'll write it up properly.

On my end, the rest of the year is packed, so I'm not looking to own anything. I'll keep chipping away at what comes through and testing where it helps.

Matt

[SteveTheKiller]

Matt, thank you for taking the time to write this up. I wanted to give it a proper answer instead of firing something back while I was buried in 1.8.2.

1.9 survives. I am not skipping the print-production work or throwing those issues back into the pile. Preflight, page boxes, color management and separation preview still belong there. I have also committed 1.9 to moving content extraction into KillerPDF.Engine so PdfPig can come out before the cross-platform work begins. The milestone needs its description updated to reflect both halves.

I like the idea of naming the purpose of the major and minor milestones. That is already how I think about releases, even when I have not put a short name on them. Patch releases are less predictable because they are usually shaped by real-world reports after a larger release, but they should at least say what they are for instead of sitting there blank.

You have identified the unresolved part of 2.0 correctly. The engine is deliberately cross-platform, but the current rendering and OCR stack is not. PDFium, Tesseract and the desktop shell need a separate architecture decision. I have not chosen a replacement renderer or UI framework yet, and I do not want to pretend that changing the target framework somehow solved that. I should write that decision down in an ADR once I have enough evidence to make it rather than just listing possible frameworks and native builds.

WPF stays for 1.9. Targeted XAML, theme and layout fixes are still useful and will not be thrown away before that release. For 2.0, a cross-platform interface necessarily means something beyond WPF. I have not decided whether the WPF application remains the Windows front end alongside it or whether one new shell replaces it everywhere. So I would not ask you to spend a month rebuilding a large WPF surface right now, but the focused fixes you have been sending are absolutely still worth doing.

You are also right about the contributing guide. The expectations already exist, but they are scattered through issue comments where nobody can reasonably find them. A short CONTRIBUTING.md in the same spirit as TRANSLATING.md would be useful.

And yes, please keep the feature-gap notes. A list built from daily print-production work is much more valuable to me than a generic checklist copied from Acrobat. You do not need to turn it into a proposal or take ownership of anything. When you have time, write it up as observations and use cases. That will be useful when I scope both 1.9 and 2.0.

Thank you again, both for the thought behind this and for all the testing and code you have already contributed.

[SteveTheKiller]

Oh, pretty soon, once I feel 1.8.x is "stable" we'll open up the 1.9 development branch kinda like before and then start loading it up with features right away.

[SteveTheKiller]

You were right about the contributing guide. I pulled the build instructions, engine boundary, testing expectations, dependency policy, UI guidance, translation path, and pull request expectations into one file:

https://github.com/SteveTheKiller/KillerPDF/blob/main/CONTRIBUTING.md

GitHub now surfaces it automatically when somebody opens an issue or pull request. Thank you for pointing out that I had already written most of this in scattered comments without giving contributors one place to find it.

[Ryokoxx]

Steve, thanks for the CONTRIBUTING.md, 1.9 surviving is the answer I was after.
I'll write the gap notes.
Only the ones where I can name the job and what it cost, so you'll get a shorter list than the one I've been keeping.
Its own thread, realistically after the third week of September.

On #320 - I haven't shipped anything on Linux or macOS, so I'll stay out of the framework call.
I do have an M1 MacBook and some Linux machines.
When you're at prototypes, I can run them on real hardware and tell you what happened.

Matt

[SteveTheKiller]

I assign myself issues as a habit but feel free to take a look at all the 1.9 projects and let me know if you want to tackle it.
I'll open the dev channel in a week or so and then we'll just get started adding every feature in the world.

We'll keep the two branches alive side by side for a while to give ourselves lots of testing time before 1.9.
We'll do the same thing with the 2.0 branch, but probably even longer for that one based on the amount of work involved.

I wanted to wait a little bit for more bugs to fix before releasing the next 1.8.3 but it appears to have slowed down.
We may have reached stability!

[SteveTheKiller]

I think I'm almost ready to release 1.8.3 tonight, bug reports have slowed down.
Can you build all the latest code and let me know what you think?

Then we will get started on the dev channel but there are a few things I need to do before I make it public, specifically the PdfPig replacement.

[Ryokoxx]

Built deb4de4 and ran the lot.

Engine and app tests both green, 1,443 and 289, nothing tripped warnings-as-errors.
All 26 corpus smoke modes pass and the publish is clean.

Then I pointed the corpus validator at 2,506 real PDFs off our archive.
Mostly manufacturer manuals and parts books, plus our own scanned order paperwork.
2,418 pass, 88 fail, same 88 in plain and structural.

All 88 give "has a damaged structure and couldn't be added" in the app.
I put the same 88 through MuPDF and every one opens and renders page one.
Biggest two groups are trailer /Size undercounting the highest object number (21) and duplicate dictionary keys (18).
Most of those are our own signed order forms, which is how I noticed.

It's not a 1.8.3 regression.
1.8.2 throws the identical dialog on the identical file, so none of this should hold tonight's release.

Worth asking though: should strict validation gate opening at all?
The reader could repair and warn on open, and keep the strict path for saving and authoring.
Your call entirely. I haven't checked whether PDFium would render them if the validator let them through.

I can build minimal repro files for any of the categories. The originals are customer paperwork so I can't post those.

Haven't done the desktop checklist yet, themes, 98SE, scaling, panes, window sizes.
A fair chunk of the 34 commits are theme and layout work so that's the gap.
Can do it tomorrow if that's useful before you tag.

Matt

[SteveTheKiller]

Thanks Matt, I ended up releasing 1.8.3 before seeing your reply. Good to know those failures aren't a regression.

Our corpus run showed progress: 1.8.3 successfully opened and saved 40,563 PDFs, which is 1,485 more than 1.8.2.
Every PDF that saved successfully in 1.8.2 also saved successfully in 1.8.3.

We may never hit 100%, but I'm mostly competing with the previous version. As long as each release handles more files and gets better without losing what already works, I think we're doing okay. Thanks for taking the time to test it against your own archive.

That archive will be helpful as we move into 1.9 and expand the features and the engine capabilities.

I'm beginning the 1.9 dev branch locally for now and working on removing the PdfPig dependency before I make it public.
The reason is because it's a massive engine change and I feel like all the new features should be added after that, not during.

[SteveTheKiller]

I missed your question about gating. I don't think strict validation should automatically prevent opening a file if it can be read safely. Opening with a warning makes sense, while keeping stricter checks for saving and authoring.

I haven't looked closely enough at those failures to say what we can safely accept yet.
Minimal repros for the /Size and duplicate-key cases would help.

[Ryokoxx]

Got the checklist done this afternoon rather than tomorrow. Nothing blocking.

Dark, Light and Black are all clean.
Sepulchre and Decay are fine too, texture sits under the chrome properly.
98SE is correct, silver chrome and the classic bevels.
Split panes hold two documents independently and the AcroForm appearances render in pane B.
Narrow at 740x640 collapses the toolbar into the overflow the way it should, and large at 2400x1500 refits fine.
Scaling at 85, 100 and 140 percent grows the toolbar, sidebar and thumbnails crisply.
Wheel, PgDn, PgUp, Ctrl+Home and Ctrl+End all navigate.

Two things I noticed, neither of them a blocker.

In continuous mode the footer page readout goes stale after PgDn.
The view moves, the sidebar box updates to 3 / 50 and the thumbnail follows, but the footer keeps saying Page 1 of 50.
It isn't new though. 1.8.2 does exactly the same across six controlled runs, so it's been sitting there a while.

The other one is that the footer doesn't take the app scale.
I can see from the comment in AppScale.cs that's deliberate, so the logo you scroll to drive it stays put.
Only reason I raise it is the view and zoom controls just moved down there, so at 2.5x everything else grows and those don't.
Might be nothing.

Happy to open either as an issue if you want them tracked, otherwise leave them here.

Matt

[SteveTheKiller]

Yeah, go ahead and make an issue for that. I don't want to forget it and I got a lot on my plate right now.
That's great though, I'm really liking the footer view controls now.
I'm going to add a metric/imperial toggle on the size when clicked (i forgot to add it lol).

Any other issues you find, feel free to open issues for them so we don't lose anything.

[Ryokoxx]

Congrats on getting 1.8.3 out, and that corpus number is a good result.

Repros for the two cases below.
Each is about 600 bytes and carries exactly one fault, plus a clean control built the same way so the fault is the only variable.

File	Engine validator	App	MuPDF
control-clean.pdf	PASS	opens normally	renders
size-undercount.pdf	Trailer /Size must be greater than every in-use object number	damaged structure	renders
duplicate-key.pdf	The PDF dictionary contains the duplicate key /MediaBox	damaged structure	renders

One detail that might help when you decide what to accept.
MuPDF resolves the duplicate key last-one-wins.
It takes the second /MediaBox and renders the page A4, not Letter.

Script rather than attachments, so you can regenerate all three and move the faults around:

def assemble(objects, size_override=None):
    out = bytearray(b"%PDF-1.7\n%\xe2\xe3\xcf\xd3\n")
    offsets = {}
    for num, body in objects:
        offsets[num] = len(out)
        out += b"%d 0 obj\n" % num + body + b"\nendobj\n"
    xref_at = len(out)
    count = max(offsets) + 1
    out += b"xref\n0 %d\n0000000000 65535 f \n" % count
    for n in range(1, count):
        out += b"%010d 00000 n \n" % offsets[n]
    out += b"trailer\n<< /Size %d /Root 1 0 R >>\n" % (size_override or count)
    out += b"startxref\n%d\n%%%%EOF\n" % xref_at
    return bytes(out)

CONTENT = b"BT /F1 18 Tf 72 700 Td (Minimal repro) Tj ET"

def objs(page):
    return [(1, b"<< /Type /Catalog /Pages 2 0 R >>"),
            (2, b"<< /Type /Pages /Kids [3 0 R] /Count 1 >>"),
            (3, page),
            (4, b"<< /Length %d >>\nstream\n" % len(CONTENT) + CONTENT + b"\nendstream"),
            (5, b"<< /Type /Font /Subtype /Type1 /BaseFont /Helvetica >>")]

GOOD = (b"<< /Type /Page /Parent 2 0 R /MediaBox [0 0 612 792] "
        b"/Resources << /Font << /F1 5 0 R >> >> /Contents 4 0 R >>")
DUP  = GOOD.replace(b"/MediaBox [0 0 612 792] ",
                    b"/MediaBox [0 0 612 792] /MediaBox [0 0 595 842] ")

open("control-clean.pdf","wb").write(assemble(objs(GOOD)))
open("size-undercount.pdf","wb").write(assemble(objs(GOOD), size_override=5))
open("duplicate-key.pdf","wb").write(assemble(objs(DUP)))

Highest in-use object is 5, so /Size has to be at least 6.
Passing 5 leaves object 5 outside /Size while the xref still lists it.

I'll open the two from the checklist as issues shortly so they don't get lost.
Happy to send repros for the other categories if you get to them.

Matt