PDF को इमेज में बदले बिना मर्ज करना
सही PDF मर्ज पेज स्ट्रीम जोड़ता है: फ़ॉन्ट, वेक्टर और बुकमार्क बने रहते हैं। हर पेज को इमेज में बदलना अलग और अधिक नुक़सानदेह काम है।
“इन पाँच PDF को मर्ज करो” का मतलब दो अलग पाइपलाइन हो सकता है। एक मौजूदा पेज ऑब्जेक्ट को एक फ़ाइल में जोड़ती है। दूसरी हर पेज को बिटमैप पर छापकर उन इमेज को नई PDF में पैक करती है। दोनों एक ही संलग्नक बनाती हैं। सिर्फ़ पहली चुनने-योग्य टेक्स्ट और तेज़ वेक्टर बनाए रखती है।
संरचनात्मक मर्ज क्या करता है
PDF123 पर Merge दो या अधिक PDF को हर फ़ाइल के पेज ऑब्जेक्ट जोड़कर मिलाता है। सर्वर पथ qpdf को खाली बेस और इनपुट पर --pages के साथ चलाता है: पेज स्ट्रीम पेज की तरह चलती हैं, स्क्रीनशॉट की तरह नहीं। एम्बेडेड फ़ॉन्ट, वेक्टर और मौजूदा बुकमार्क उन पेजों के साथ चलते हैं। उस पथ में कुछ भी किसी पेज को इमेज में नहीं बदलता, इसलिए जन्मजात डिजिटल कॉन्ट्रैक्ट जुड़ने के बाद भी खोजा और कॉपी किया जा सकता है।
अपलोड क्रम ही डिफ़ॉल्ट आउटपुट क्रम है। HTTP फ़ॉर्म एक अनुरोध में बार-बार fileInput भाग लेता है; बैच आकार अपलोड सीमाओं से बँधा है, दो-फ़ाइल की कठोर सीमा से नहीं। वैकल्पिक sortType=byFileName जोड़ने से पहले इनपुट को फ़ाइलनाम से क्रमबद्ध करता है। हर स्रोत के बुकमार्क बच सकते हैं; अगर इनपुट में कभी ठोस रूपरेखा वृक्ष नहीं था, तो मर्ज उसे नहीं गढ़ता।
एक फ़ाइल का अपलोड उसी PDF का निष्क्रिय पास-थ्रू है। दो या अधिक फ़ाइलें एक merged.pdf बनती हैं जिसके पेज चुने क्रम में इनपुट का संयोजन हैं। वही प्रचालन-आईडी OpenAPI, MCP और pdfx merge खोलते हैं, इसलिए स्क्रिप्ट और ब्राउज़र क्लिक “merge” पर चुपचाप असहमत नहीं होते।
लोग अनजाने में रास्टराइज़ कब कर बैठते हैं
कुछ “जोड़ने वाले” कार्यप्रवाह पहले इमेज में निर्यात करते हैं (फ़ैक्स गेटवे, स्कैन ऐप, स्क्रीन रिज़ॉल्यूशन पर print-to-PDF) या जोड़ने से पहले एनोटेशन बिटमैप में समतल कर देते हैं। फ़ाइल आकार उछलता है, OCR फिर ज़रूरी हो सकता है, और ज़ूम पर पिक्सेल के किनारे दिखते हैं।
जब स्रोत पहले से डिजिटल PDF हों तो स्ट्रीम मर्ज पसंद करें। OCR तभी पसंद करें जब इनपुट ऐसे स्कैन हों जिनमें उपयोगी टेक्स्ट न हो, और याद रखें कि यहाँ OCR Markdown (text/markdown) लौटाता है, छिपी टेक्स्ट परत वाली दोबारा-परत PDF नहीं। पहले रास्टराइज़ कर फिर OCR करना, जन्मजात डिजिटल फ़ाइलें मर्ज करने से अलग उत्पाद-पथ है।
अगर पेजों की इमेज चाहिए, तो वह रूपांतरण का काम है (PDF to images), मर्ज का नहीं। इन इरादों को मिलाने से ही “मर्ज की गई” फ़ाइलें बहु-मेगाबाइट दस्तावेज़ी फ़ोटो एलबम बन जाती हैं। संरचनात्मक मर्ज के बाद Compress अब भी स्ट्रीम छोटी कर सकता है (Compress); यह पहले से पके रास्टर समतलीकरण को नहीं उलटता।
मर्ज जो वादा नहीं करता
मर्ज पेज आकार सामान्य नहीं करता, फ़ाइलों के आर-पार फ़ॉन्ट एकरूप नहीं करता, या विषय-सूची शून्य से दोबारा नहीं बनाता। यह एन्क्रिप्टेड इनपुट को आपके लिए डिक्रिप्ट नहीं करता; स्रोत पासवर्ड-सुरक्षित हो तो पहले अनलॉक करें। यह उस पोर्टफ़ोलियो/पैकेज कंटेनर प्रारूप की जगह नहीं लेता जिसकी कुछ अदालती पोर्टल अपेक्षा करते हैं; यह एक साधारण बहु-पेज PDF बनाता है।
ये सीमाएँ वही हैं, चाहे आप ब्राउज़र, REST, MCP या pdfx इस्तेमाल करें। यह प्रचालन जानबूझकर संकीर्ण है ताकि स्वचालन के लिए आउटपुट अनुमानित रहे। क्रमबद्ध बहु-चरणीय काम चाहिए (मर्ज, फिर वॉटरमार्क, फिर संपीड़न), तो दूसरा “स्मार्ट मर्ज” फ़्लैग गढ़ने के बजाय क्रमबद्ध steps सूची के साथ POST /api/v1/pipeline इस्तेमाल करें।
इसे कैसे चलाएँ
ब्राउज़र में Merge PDFs, या बार-बार fileInput भागों के साथ POST /api/v1/general/merge-pdfs (Developers)। शेल से:
pdfx merge a.pdf b.pdf -o merged.pdf
या होस्टेड/स्वयं-होस्टेड बेस के ख़िलाफ़:
pdfx --cloud --api-base "$API_BASE" --api-key "$KEY" merge a.pdf b.pdf -o merged.pdf
सार्वजनिक साइट पर अनाम कैटलॉग कॉल के लिए की नहीं चाहिए; की स्थिर स्वचालन पहचान और नियंत्रित स्वयं-होस्टेड सर्वर के लिए मायने रखती हैं। curl और MCP से भी वही प्रचालन चाहिए तो वही प्रचालन, चार क्लाइंट देखें।