Vì sao chúng tôi bỏ qua ứng dụng desktop
PDF123 sẽ không phát hành thêm một giao diện desktop. Dùng offline và riêng tư vẫn nằm trên Docker Compose cùng pdfx, để danh mục không lệch khỏi bề mặt API.
Khi tệp không được rời mạng riêng, yêu cầu tiếp theo thường là bộ cài Windows hay macOS. Chúng tôi từ chối hình dạng đó có chủ ý. GUI desktop sẽ là codebase giao diện thứ hai. Khi hai cây mã tách nhau, lệch tính năng giữa “ứng dụng” và /api/v1/ gần như không tránh khỏi.
Ràng buộc nằm ở biên giới, không ở giao diện
“Byte ở lại đây” được thỏa mãn bởi pdfx-server do bạn chạy, không phải cụ thể WinForms hay Electron. Compose cùng pdfx (cục bộ hoặc --cloud nhắm base URL của bạn) giữ một danh mục thao tác duy nhất phía sau trình duyệt, REST, MCP và CLI.
Cách dựng stack đó ghi tại Self-host: task docker:build / task docker:up cho Compose (API :8080, portal :3000), hoặc task pdfx:dev native bên cạnh portal cho việc cục bộ. Đặt SECURITY_CUSTOMGLOBALAPIKEY khi muốn cổng cố định. Bài này chỉ bàn vì sao stack đó không được bọc thành sản phẩm desktop.
pdfx cục bộ không --cloud chạy pdf-core trên chính máy giữ tệp. Vậy đã đủ cho tác vụ batch offline vốn chưa từng cần GUI. Chế độ cloud dành khi cùng CLI đó phải đánh API base self-host hay hosted với cùng hợp đồng multipart như curl.
Một bản fork desktop sẽ tốn những gì
Bộ công cụ tiêu dùng tối ưu cho chỉnh sửa canvas, so sánh trực quan và bộ cài từ store. Duy trì bề mặt đó nghĩa là nhân đôi mọi thao tác mới (cờ merge, chế độ OCR, mặc định sanitize) trong GUI không phải hợp đồng OpenAPI mà agent đã gọi.
Plugin và kênh store nhân việc hỗ trợ lên mà không cải thiện MCP hay hành vi Idempotency-Key. Mỗi vòng review store và hộp thoại xin quyền của hệ điều hành là thời gian không chảy vào /v1/openapi.json. Khi cây desktop phát hành tùy chọn merge mà API còn thiếu (hoặc ngược lại), tự động hóa và demo lệch nhau trong im lặng.
OCR là ví dụ cụ thể cho thấy nhân đôi gây hại. Đường server hiện tại trả Markdown (text/markdown) với hai chế độ Auto và Force (ocrType=force-ocr cho Force). Giao diện desktop vẫn hứa “PDF tìm kiếm được với lớp chữ ẩn” sẽ nói dối về một pipeline khác. Giữ một định nghĩa thao tác duy nhất tránh được chia rẽ đó.
Một danh mục, bốn client, không có giao diện thứ hai
Sản phẩm đã có bốn cách chạm cùng những thao tác: form trên portal, curl tới /api/v1/…, MCP tại /mcp, và pdfx cục bộ hoặc cloud. Merge là ví dụ cụ thể: ghép các PDF theo thứ tự tải lên mà không raster hóa trang thành ảnh, dù bạn bấm Process hay POST các phần fileInput.
Một bản desktop sẽ là cách chạm thứ năm với lịch phát hành riêng. Chế độ hỏng chúng tôi quan tâm không phải “thiếu icon khay hệ thống”, mà là “trang demo vẫn chạy trong khi script phụ thuộc cùng thao tác đó lặng lẽ thoái lui”.
Những gì chúng tôi không khẳng định
Bỏ desktop không tạo ra chỉnh sửa tương tác kiểu Acrobat trên trình duyệt. Công cụ dạng form và tác vụ HTTP vẫn là sản phẩm. Canvas Edit online, so sánh trực quan và giao diện Sign cho người dùng phổ thông vẫn ngoài phạm vi có chủ ý. Nếu cần triển khai riêng, compose up rồi trỏ client vào API base của bạn. Nếu cần trình chỉnh sửa pixel, dùng bộ công cụ xây cho việc đó; đừng chờ tệp .exe của PDF123.
PDF123 hosted vẫn là đường ẩn danh nhanh. Self-host là chính bộ công cụ đó sau tường lửa. Không đường nào là bản desktop thứ ba, lệch hướng. Đối chiếu với converter chỉ chạy trên trình duyệt: Vì sao nên self-host bộ công cụ PDF. Bạn mua gì và vận hành gì: Self-host thực sự mang lại gì. Bốn client không-desktop căn chỉnh thế nào: Cùng thao tác, bốn client.