हमने डेस्कटॉप ऐप क्यों छोड़ दिया

जब फ़ाइलें निजी नेटवर्क से बाहर नहीं जानी चाहिए, तो अगला अनुरोध अक्सर Windows या macOS इंस्टॉलर होता है। हमने वह स्वरूप जानबूझकर ठुकराया। डेस्कटॉप GUI दूसरा इंटरफ़ेस कोड-आधार होता। “ऐप” और /api/v1/ के बीच सुविधा-पिछड़त लगभग अटल है, एक बार वे वृक्ष अलग हो जाएँ तो।

बाध्यता सीमा है, सजावट नहीं

“बाइट्स यहीं रहें” उस pdfx-server से पूरा होता है जिसे आप चलाते हैं, WinForms या Electron से नहीं। Compose और pdfx (स्थानीय, या आपके बेस URL के ख़िलाफ़ --cloud) ब्राउज़र, REST, MCP और CLI के पीछे एक ही प्रचालन कैटलॉग रखते हैं।

यह स्टैक कैसे खड़ा करें, यह Self-host पर दर्ज है: Compose के लिए task docker:build / task docker:up (API :8080 पर, पोर्टल :3000 पर), या स्थानीय काम के लिए पोर्टल के साथ नेटिव task pdfx:dev। स्थिर द्वार चाहिए तो SECURITY_CUSTOMGLOBALAPIKEY सेट करें। यह लेख सिर्फ़ इस बारे में है कि वह स्टैक डेस्कटॉप उत्पाद के रूप में लिपटा क्यों नहीं है।

--cloud के बिना स्थानीय pdfx pdf-core उसी मशीन पर चलाता है जिस पर फ़ाइलें हैं। यह उन ऑफ़लाइन बैच कामों को पहले ही कवर करता है जिन्हें GUI कभी चाहिए ही नहीं था। क्लाउड मोड तब है जब वही CLI आपके स्वयं-होस्टेड या होस्टेड API बेस पर curl जैसे ही मल्टीपार्ट अनुबंध से पहुँचे।

डेस्कटॉप फ़ोर्क की क़ीमत

उपभोक्ता सूट कैनवास संपादन, दृश्य तुलना और स्टोर इंस्टॉलरों के लिए अनुकूलित होते हैं। उस सतह को बनाए रखने का मतलब है हर नया प्रचालन (मर्ज फ़्लैग, OCR मोड, सैनिटाइज़ डिफ़ॉल्ट) ऐसे GUI में दोहराना जो वह OpenAPI अनुबंध नहीं है जिसे एजेंट पहले से कॉल करते हैं।

प्लगइन और स्टोर चैनल समर्थन को कई गुना करते हैं, बिना MCP या Idempotency-Key व्यवहार सुधारे। हर स्टोर समीक्षा चक्र और OS अनुमति संकेत वह समय है जो /v1/openapi.json तक नहीं पहुँचता। जैसे ही डेस्कटॉप वृक्ष कोई मर्ज विकल्प भेजता है जो API में नहीं है (या उलटा), स्वचालन और डेमो चुपचाप असहमत हो जाते हैं।

OCR इसका ठोस उदाहरण है कि दोहराव क्यों चोट पहुँचाता है। मौजूदा सर्वर पथ Markdown (text/markdown) लौटाता है, Auto बनाम Force मोड के साथ (Force के लिए ocrType=force-ocr)। जो डेस्कटॉप इंटरफ़ेस अब भी “छिपी परत वाली खोजने-योग्य PDF” का वादा करता, वह किसी और पाइपलाइन के बारे में झूठ बोल रहा होता। एक ही प्रचालन-परिभाषा रखने से वह विभाजन टलता है।

एक कैटलॉग, चार क्लाइंट, शून्य दूसरा इंटरफ़ेस

उत्पाद के पास पहले से एक ही प्रचालनों के चार हैंडल हैं: पोर्टल फ़ॉर्म, /api/v1/… पर curl, /mcp पर MCP, और स्थानीय या क्लाउड pdfx। Merge ठोस उदाहरण है: पेजों को इमेज में बदले बिना अपलोड क्रम में PDF जोड़ें, चाहे आपने प्रोसेस पर क्लिक किया हो या fileInput भाग पोस्ट किए हों।

डेस्कटॉप संस्करण पाँचवाँ हैंडल होता, अपनी अलग रिलीज़ ट्रेन के साथ। हमारी चिंता का विफलता-तरीक़ा “ट्रे आइकन गायब है” नहीं है। वह “डेमो पेज अब भी चलता है, जबकि उसी प्रचालन पर निर्भर स्क्रिप्ट चुपचाप पीछे जाती है” है।

जो हम दावा नहीं करते

डेस्कटॉप छोड़ने से ब्राउज़र में Acrobat-श्रेणी का इंटरैक्टिव संपादन नहीं आ जाता। फ़ॉर्म टूल और HTTP काम ही उत्पाद रहते हैं। ऑनलाइन Edit कैनवास, दृश्य तुलना और उपभोक्ता “Sign” इंटरफ़ेस जानबूझकर दायरे से बाहर हैं। निजी डिप्लॉयमेंट चाहिए तो compose up करें और क्लाइंट को अपने API बेस पर लगाएँ। पिक्सेल एडिटर चाहिए तो उसी के लिए बना सूट इस्तेमाल करें; PDF123 .exe का इंतज़ार न करें।

होस्टेड PDF123 तेज़ अनाम पथ बना रहता है। स्वयं-होस्ट वही टूलकिट आपके फ़ायरवॉल के पीछे है। दोनों में से कोई तीसरा, अलग डेस्कटॉप संस्करण नहीं है। सिर्फ़-ब्राउज़र कन्वर्टरों से तुलना के लिए PDF टूलकिट स्वयं क्यों होस्ट करें देखें। क्या मिलता है और क्या चलाना पड़ता है, यह स्वयं-होस्टिंग असल में क्या देती है में है। चार ग़ैर-डेस्कटॉप क्लाइंट एक साथ कैसे रहते हैं, यह वही प्रचालन, चार क्लाइंट में है।