Waarom we de desktop-app oversloegen

Wanneer bestanden een privénetwerk niet mogen verlaten, is het volgende verzoek vaak een installatieprogramma voor Windows of macOS. Die vorm hebben we expres afgewezen. Een desktop-GUI zou een tweede codebasis voor de UI zijn. Verschillen in functies tussen “de app” en /api/v1/ zijn bijna onvermijdelijk zodra die twee vertakkingen uiteenlopen.

De beperking is de grens, niet de schil

“De bytes blijven hier” wordt vervuld door een pdfx-server die u zelf draait, niet specifiek door WinForms of Electron. Compose plus pdfx (lokaal of --cloud tegen uw basis-URL) houdt één catalogus van bewerkingen achter browser, REST, MCP en CLI.

Hoe u die stack opzet, staat op Self-host: task docker:build / task docker:up voor Compose (API op :8080, portal op :3000), of native task pdfx:dev naast de portal voor lokaal werk. Stel SECURITY_CUSTOMGLOBALAPIKEY in wanneer u een vaste drempel wilt. Dit artikel gaat alleen over waarom die stack niet als desktopproduct wordt verpakt.

Lokale pdfx zonder --cloud draait pdf-core op de machine die de bestanden heeft. Dat dekt al offline batchtaken die nooit een GUI nodig hadden. De cloudmodus is bedoeld voor wanneer dezelfde CLI uw self-hosted of gehoste API-basis moet bereiken met hetzelfde multipart-contract als curl.

Wat een desktopvariant zou kosten

Consumentensuites zijn geoptimaliseerd voor canvasbewerking, visueel vergelijken en installatie via een winkel. Dat oppervlak onderhouden betekent elke nieuwe bewerking (opties voor merge, OCR-modi, standaardwaarden voor saneren) dupliceren in een GUI die niet het OpenAPI-contract is dat agents al aanroepen.

Plug-ins en winkelkanalen vermenigvuldigen de ondersteuning zonder het gedrag van MCP of Idempotency-Key te verbeteren. Elke beoordelingsronde in een winkel en elke toestemmingsvraag van het besturingssysteem kost tijd die niet in /v1/openapi.json terechtkomt. Zodra de desktoptak een merge-optie levert die de API mist (of omgekeerd), zijn automatiseringen en demo's het stil oneens.

OCR is een concreet voorbeeld van waarom duplicatie pijn doet. Het huidige serverpad levert Markdown (text/markdown) met de modi Auto en Force (ocrType=force-ocr voor Force). Een desktop-UI die nog steeds “een doorzoekbare PDF met een verborgen laag” beloofde, zou over een andere pijplijn liegen. Eén definitie van de bewerking voorkomt die splitsing.

Eén catalogus, vier clients, geen tweede UI

Het product heeft al vier manieren om dezelfde bewerkingen aan te roepen: het portalformulier, curl naar /api/v1/…, MCP op /mcp en pdfx lokaal of in de cloud. Merge is het concrete voorbeeld: PDF's samenvoegen in uploadvolgorde zonder pagina's tot afbeeldingen te rasteren, of u nu op Process hebt geklikt of fileInput-delen hebt verstuurd.

Een desktopeditie zou een vijfde manier zijn met een eigen releasecyclus. De faalwijze die ons aangaat is niet “een ontbrekend pictogram in het systeemvak”, maar “de demopagina werkt nog terwijl het script dat van dezelfde bewerking afhing stil achteruitgaat”.

Wat we niet beweren

Het overslaan van een desktopversie tovert geen interactieve bewerking van Acrobat-niveau in de browser tevoorschijn. Formuliertools en HTTP-taken blijven het product. Online canvassen voor bewerken, visueel vergelijken en Sign-UI's voor consumenten blijven expres buiten bereik. Hebt u een privé-uitrol nodig, start dan Compose en richt clients op uw API-basis. Hebt u een pixeleditor nodig, gebruik dan een suite die daarvoor is gebouwd; wacht niet op een .exe van PDF123.

Gehost PDF123 blijft het snelle anonieme pad. Self-host is dezelfde toolkit achter uw firewall. Geen van beide paden is een derde, afwijkende desktopeditie. Voor de vergelijking met browserconverters, zie Why self-host a PDF toolkit. Voor wat u koopt en wat u zelf beheert, zie What self-hosting actually buys you. Voor hoe de vier clients zonder desktop op één lijn blijven, zie Same operation, four clients.