Perché abbiamo evitato l'app desktop
PDF123 non pubblicherà una seconda interfaccia desktop. L'uso offline e privato resta su Docker Compose più pdfx, così il catalogo non può divergere dalle API.
Quando i file non devono lasciare una rete privata, la richiesta successiva è spesso un installer per Windows o macOS. Abbiamo rifiutato questa forma di proposito. Una GUI desktop sarebbe una seconda base di codice per l'interfaccia. La divergenza di funzionalità tra «l'app» e /api/v1/ è quasi inevitabile nel momento in cui quei rami si separano.
Il vincolo è il confine, non l'aspetto
«I byte restano qui» è soddisfatto da un pdfx-server che esegui tu, non specificamente da WinForms o Electron. Compose più pdfx (in locale o --cloud contro il tuo URL di base) mantiene un unico catalogo di operazioni dietro browser, REST, MCP e CLI.
Come mettere in piedi quello stack è documentato su Self-host: task docker:build / task docker:up per Compose (API su :8080, portale su :3000), oppure task pdfx:dev in modalità nativa accanto al portale per il lavoro locale. Imposta SECURITY_CUSTOMGLOBALAPIKEY quando vuoi un controllo fisso. Questo articolo spiega solo perché quello stack non viene impacchettato come prodotto desktop.
pdfx in locale senza --cloud esegue pdf-core sulla macchina che contiene i file. Questo copre già le attività batch offline che non hanno mai avuto bisogno di una GUI. La modalità cloud serve quando la stessa CLI deve raggiungere la tua base API self-hosted o ospitata con lo stesso contratto multipart di curl.
Quanto costerebbe un fork desktop
Le suite per consumatori sono ottimizzate per l'editing su canvas, il confronto visivo e gli installer degli store. Mantenere quella parte significa duplicare ogni nuova operazione (flag di merge, modalità OCR, impostazioni predefinite di sanitizzazione) in una GUI che non è il contratto OpenAPI che gli agenti già chiamano.
Plugin e canali degli store moltiplicano il supporto senza migliorare il comportamento di MCP o Idempotency-Key. Ogni ciclo di revisione dello store e ogni richiesta di permesso del sistema operativo è tempo che non finisce in /v1/openapi.json. Dal momento in cui il ramo desktop pubblica un'opzione di merge che l'API non ha (o viceversa), automazioni e demo non concordano più, in silenzio.
L'OCR è un esempio concreto del perché la duplicazione fa male. Il percorso attuale del server restituisce Markdown (text/markdown) con le modalità Auto e Force (ocrType=force-ocr per Force). Una GUI desktop che promettesse ancora un «PDF ricercabile con strato nascosto» mentirebbe, descrivendo una pipeline diversa. Mantenere un'unica definizione dell'operazione evita questa spaccatura.
Un catalogo, quattro client, nessuna seconda interfaccia
Il prodotto ha già quattro modi di chiamare le stesse operazioni: il modulo del portale, curl verso /api/v1/…, MCP su /mcp e pdfx in locale o cloud. Unisci è l'esempio concreto: combina PDF nell'ordine di caricamento senza rasterizzare le pagine in immagini, sia che tu abbia cliccato Process sia che abbia inviato parti fileInput.
Un'edizione desktop sarebbe un quinto modo, con un ciclo di rilascio separato. Il guasto che ci preoccupa non è «manca un'icona nella barra». È «la pagina demo funziona ancora, mentre lo script che dipendeva dalla stessa operazione peggiora in silenzio».
Cosa non stiamo sostenendo
Evitare il desktop non crea nel browser un editing interattivo di classe Acrobat. Il prodotto resta fatto di strumenti basati su modulo e operazioni HTTP. Le canvas di modifica online, il confronto visivo e le interfacce di firma per consumatori restano deliberatamente fuori ambito. Se ti serve un deployment privato, avvia Compose e punta i client al tuo URL di base. Se ti serve un editor di pixel, usa una suite nata per quello; non aspettare un .exe di PDF123.
PDF123 ospitato resta il percorso anonimo e rapido. Il self-host è lo stesso toolkit dietro il tuo firewall. Nessuno dei due percorsi è una terza edizione desktop divergente. Per il confronto con i convertitori solo browser, vedi Perché self-hostare un toolkit PDF. Per cosa acquisti e cosa gestisci, vedi Cosa ti dà davvero il self-hosting. Per come i quattro client non desktop restano allineati, vedi La stessa operazione, quattro client.