Защо пропуснахме настолното приложение

Когато файловете не трябва да напускат частна мрежа, следващата молба често е за Windows или macOS инсталатор. Отказахме тази форма нарочно. Настолен графичен интерфейс би бил втора кодова база за интерфейс. Изоставането на функциите между „приложението“ и /api/v1/ е почти неизбежно, щом тези дървета се разделят.

Ограничението е границата, не украсата

„Байтовете остават тук“ се постига с pdfx-server, който пускате вие, а не непременно с WinForms или Electron. Compose плюс pdfx (локално или --cloud към вашия базов адрес) поддържа един каталог от операции зад браузъра, REST, MCP и CLI.

Как да вдигнете този стек е документирано в Self-host: task docker:build / task docker:up за Compose (API на :8080, портал на :3000) или локалната task pdfx:dev до портала за работа на машината. Задайте SECURITY_CUSTOMGLOBALAPIKEY, когато искате фиксирана защита. Тази публикация е само за това защо този стек не е обвит като настолен продукт.

Локалният pdfx без --cloud изпълнява pdf-core на машината, на която са файловете. Това вече покрива офлайн пакетни задачи, които никога не са имали нужда от графичен интерфейс. Облачният режим е за случаите, когато същият CLI трябва да удари вашия самостоятелно хостван или хостван базов адрес на API със същия multipart договор като curl.

Какво би струвал настолен вариант

Потребителските пакети оптимизират редактирането върху платно, визуалното сравняване и инсталаторите от магазини. Поддържането на тази повърхност означава дублиране на всяка нова операция (флагове за сливане, режими на OCR, настройки по подразбиране за sanitize) в графичен интерфейс, който не е договорът на OpenAPI, който агентите вече извикват.

Плъгините и каналите на магазините умножават поддръжката, без да подобряват MCP или поведението на Idempotency-Key. Всеки цикъл на преглед в магазин и всяко искане за разрешение от операционната система е време, което не стига до /v1/openapi.json. Щом настолното дърво пусне опция за сливане, която API няма (или обратното), автоматизациите и демонстрациите се разминават тихо.

OCR е конкретен пример защо дублирането вреди. Текущият сървърен път връща Markdown (text/markdown) с режими Auto и Force (ocrType=force-ocr за Force). Настолен интерфейс, който още обещава „търсим PDF със скрит слой“, би лъгал за различен процес. Една дефиниция на операцията избягва това разделение.

Един каталог, четири клиента, нула втори интерфейс

Продуктът вече има четири начина за достъп до същите операции: формулярът в портала, curl към /api/v1/…, MCP на /mcp и pdfx локално или в облак. Merge е конкретният пример: комбинира PDF в реда на качване, без да превръща страниците в изображения, независимо дали сте натиснали Process, или сте подали части fileInput.

Настолно издание би било пети начин за достъп с отделен цикъл на издаване. Режимът на отказ, който ни интересува, не е „липсва икона в системния трей“. Той е „демонстрационната страница още работи, докато скриптът, който разчиташе на същата операция, тихо се влошава“.

Какво не твърдим

Пропускането на настолното приложение не създава интерактивно редактиране от класа на Acrobat в браузъра. Инструментите с формуляри и HTTP задачите остават продуктът. Онлайн платната Edit, визуалното сравняване и потребителските интерфейси за подпис остават умишлено извън обхвата. Ако ви трябва частно внедряване, вдигнете Compose и насочете клиентите към вашия базов адрес на API. Ако ви трябва редактор на пиксели, използвайте пакет, създаден за това; не чакайте .exe от PDF123.

Хостваният PDF123 остава бързият анонимен път. Самостоятелното хостване е същият инструментариум зад вашата защитна стена. Нито един от двата пътя не е трето, разминаващо се настолно издание. За контраст с конверторите само в браузър вижте Защо да хоствате сами PDF инструментариум. За това какво купувате и какво поддържате вижте Какво всъщност ви дава самостоятелното хостване. За това как четирите клиента без настолно приложение остават подравнени вижте Една и съща операция, четири клиента.