Почему мы отказались от настольного приложения

Когда файлы не должны покидать приватную сеть, следующая просьба часто звучит как установщик для Windows или macOS. Мы отказались от этой формы осознанно. Настольный графический интерфейс стал бы второй кодовой базой для UI. Расхождение в возможностях между «приложением» и /api/v1/ почти неизбежно, как только эти деревья расходятся.

Ограничение — это граница, а не оформление

«Байты остаются здесь» обеспечивает pdfx-server, который запускаете вы, а не WinForms или Electron как таковые. Compose плюс pdfx (локальный или --cloud против вашего базового URL) сохраняет один каталог операций за браузером, 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 должен обратиться к вашему собственному или хостинговому базовому URL API с тем же multipart-контрактом, что и curl.

Чего стоило бы ответвление под настольную версию

Потребительские наборы оптимизированы под редактирование на холсте, визуальное сравнение и магазины установщиков. Поддержка такой поверхности означает дублирование каждой новой операции (флагов слияния, режимов OCR, значений санитизации по умолчанию) в графическом интерфейсе, который не является контрактом 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-задачами. Онлайн-редакторы, визуальное сравнение и потребительские интерфейсы подписи намеренно вне области. Если нужно приватное развёртывание, поднимите Compose и направьте клиентов на ваш базовый URL API. Если нужен пиксельный редактор, возьмите набор, созданный для этого; не ждите .exe от PDF123.

Хостинговый PDF123 остаётся быстрым анонимным путём. Self-host — тот же набор инструментов за вашим брандмауэром. Ни один из путей не является третьим, расходящимся настольным изданием. О контрасте с браузерными конвертерами см. Зачем самостоятельно хостить PDF-набор. О том, что вы покупаете и чем управляете, см. Что на самом деле даёт самостоятельный хостинг. О том, как четыре ненастольных клиента остаются согласованными, см. Одна операция, четыре клиента.