Чому ми відмовилися від настільного застосунку
PDF123 не випускатиме другого настільного інтерфейсу. Офлайн і приватне використання лишаються на Docker Compose та pdfx, щоб каталог не розходився з API.
Коли файли не повинні покидати приватну мережу, наступний запит часто — інсталятор для Windows чи macOS. Ми свідомо відмовилися від такої форми. Настільний графічний інтерфейс був би другою кодовою базою UI. Відставання функцій між «застосунком» і /api/v1/ майже неминуче, щойно ці дерева розходяться.
Обмеження — це межа, а не оболонка
«Байти лишаються тут» забезпечує pdfx-server, який запускаєте ви, а не WinForms чи Electron як такі. Compose плюс pdfx (локальний або --cloud проти вашої базової адреси) тримає один каталог операцій за браузером, REST, MCP і CLI.
Як підняти цей стек, описано на сторінці Власний хостинг: task docker:build / task docker:up для Compose (API на :8080, портал на :3000) або локальний task pdfx:dev поряд із порталом. Задайте SECURITY_CUSTOMGLOBALAPIKEY, коли хочете фіксований бар’єр. Ця стаття лише про те, чому цей стек не загорнуто в настільний продукт.
Локальний pdfx без --cloud запускає pdf-core на машині, де лежать файли. Це вже покриває офлайн-пакетні задачі, яким ніколи не був потрібен графічний інтерфейс. Хмарний режим — для випадків, коли той самий CLI має звертатися до вашої власної чи хмарної базової адреси 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 локально чи в хмарі. Об’єднання — конкретний приклад: поєднати PDF у порядку завантаження, не растеризуючи сторінки в зображення, незалежно від того, натиснули ви «Обробити» чи надіслали частини fileInput.
Настільне видання було б п’ятим способом із окремим циклом випуску. Режим відмови, який нас турбує, — не «бракує значка в лотку», а «демонстраційна сторінка ще працює, тоді як скрипт, що залежав від тієї самої операції, нишком регресує».
Чого ми не стверджуємо
Відмова від настільного застосунку не вигадує в браузері інтерактивного редагування рівня Acrobat. Продуктом лишаються інструменти на формах і HTTP-задачі. Онлайн-полотна редагування, візуальне порівняння й споживчі інтерфейси підпису свідомо поза межами. Якщо потрібне приватне розгортання, підніміть Compose і спрямуйте клієнти на вашу базову адресу API. Якщо потрібен піксельний редактор, користуйтеся набором, створеним для цього; не чекайте на .exe від PDF123.
Хмарний PDF123 лишається швидким анонімним шляхом. Власний хостинг — той самий набір інструментів за вашим брандмауером. Жоден зі шляхів не є третім, розбіжним настільним виданням. Про контраст із суто браузерними конвертерами див. Чому варто розмістити PDF-набір на власному хостингу. Про те, що ви купуєте й чим керуєте, див. Що насправді дає власний хостинг. Про те, як чотири ненастільні клієнти лишаються узгодженими, див. Та сама операція, чотири клієнти.