Varför vi avstod från skrivbordsappen

När filer inte får lämna ett privat nätverk är nästa önskemål ofta en installationsfil för Windows eller macOS. Vi avstod medvetet från den formen. Ett grafiskt skrivbordsprogram skulle bli en andra kodbas för gränssnittet, och när de träden väl skiljer sig är det nästan oundvikligt att funktionerna glider isär mellan ”appen” och /api/v1/.

Begränsningen är gränsen, inte skalet

Att byten stannar här uppfylls av en pdfx-server som du kör, inte specifikt av WinForms eller Electron. Compose plus pdfx (lokalt eller --cloud mot din basadress) håller en och samma operationskatalog bakom webbläsaren, REST, MCP och kommandoradsverktyget.

Hur du får upp den stacken beskrivs på Kör själv: task docker:build och task docker:up för Compose (API på :8080, portalen på :3000), eller task pdfx:dev direkt på maskinen vid sidan av portalen. Sätt SECURITY_CUSTOMGLOBALAPIKEY när du vill ha en fast spärr. Det här inlägget handlar bara om varför stacken inte förpackas som en skrivbordsprodukt.

Lokalt pdfx utan --cloud kör pdf-core på maskinen som har filerna. Det täcker redan batchjobb offline som aldrig behövde ett grafiskt gränssnitt. Molnläget är till för när samma verktyg ska träffa din egen eller den hostade API-basen med samma multipart-kontrakt som curl.

Vad en skrivbordsvariant skulle kosta

Konsumentsviter är optimerade för dukredigering, visuell jämförelse och butiksinstallationer. Att underhålla den ytan innebär att duplicera varje ny operation (flaggor för sammanslagning, OCR-lägen, standardvärden för sanering) i ett gränssnitt som inte är det OpenAPI-kontrakt agenterna redan anropar.

Plugin och butikskanaler mångfaldigar supporten utan att förbättra MCP eller beteendet för Idempotency-Key. Varje granskningsrunda i en butik och varje behörighetsfråga från operativsystemet är tid som inte hamnar i /v1/openapi.json. Så snart skrivbordsgrenen erbjuder ett alternativ som API:et saknar, eller tvärtom, är automatiseringar och demos tyst oense.

OCR är ett konkret exempel på varför dupliceringen skadar. Serverns nuvarande väg returnerar Markdown (text/markdown) med lägena Auto och Force (ocrType=force-ocr för Force). Ett gränssnitt som fortfarande lovade ”sökbar PDF med dolt lager” skulle ljuga om en annan kedja. Att hålla en enda definition av operationen undviker den splittringen.

En katalog, fyra klienter, ingen andra gränssnittsyta

Produkten har redan fyra sätt att nå samma operationer: portalens formulär, curl mot /api/v1/…, MCP på /mcp och pdfx lokalt eller i molnet. Slå ihop PDF är det konkreta exemplet: kombinera PDF:er i uppladdningsordning utan att rastrera sidorna till bilder, oavsett om du klickade på knappen eller skickade fileInput-delar.

En skrivbordsutgåva skulle bli ett femte sätt med en egen releasecykel. Felet vi bryr oss om är inte att en ikon i aktivitetsfältet saknas, utan att demosidan fortfarande fungerar medan skriptet som byggde på samma operation tyst slutar göra det.

Vad vi inte påstår

Att hoppa över skrivbordet trollar inte fram interaktiv redigering i Acrobat-klass i webbläsaren. Formulärverktyg och HTTP-jobb är fortfarande produkten. Redigeringsdukar på webben, visuell jämförelse och konsumentvänliga signeringsgränssnitt ligger medvetet utanför. Behöver du en privat installation startar du Compose och pekar klienterna mot din API-bas. Behöver du en pixelredigerare använder du en svit byggd för det; vänta inte på en .exe från PDF123.

Den hostade tjänsten PDF123 är fortfarande den snabba anonyma vägen. Egen drift är samma verktygslåda bakom din brandvägg. Ingen av vägarna är en tredje, avvikande skrivbordsutgåva. En jämförelse med konverterare som bara finns i webbläsaren finns i Varför köra ett PDF-verktyg själv. Vad du vinner och vad du driver finns i Vad du faktiskt vinner på att köra själv. Hur de fyra klienterna utan skrivbord hålls i linje finns i Samma operation, fyra klienter.