دمج ملفات PDF من دون تسطيح كل شيء في صور
الدمج السليم يصل تدفقات الصفحات، فتبقى الخطوط والمتجهات والإشارات المرجعية سليمة. أما تحويل كل صفحة إلى صورة فعملية مختلفة وأكثر فقداناً.
«ادمج هذه الملفات الخمسة» قد تعني مسارين. أحدهما يصل كائنات الصفحات القائمة في ملف واحد، والآخر يطبع كل صفحة إلى خريطة نقطية ويرصف الصور في ملف PDF جديد. وكلاهما ينتج مرفقاً واحداً، لكن الأول وحده يحفظ النص القابل للتحديد والمتجهات الحادّة.
ما يفعله الدمج البنيوي
في PDF123 يجمع Merge ملفين أو أكثر بوصل كائنات صفحات كل ملف. ويشغّل مسار الخادم qpdf بقاعدة فارغة وخيار --pages على المدخلات، فتنتقل تدفقات الصفحات كصفحات لا كلقطات شاشة. وترحل الخطوط المضمّنة والمتجهات والإشارات المرجعية القائمة مع تلك الصفحات. ولا يحوّل شيء في ذلك المسار صفحة إلى صورة، فيبقى عقد رقمي أصلي قابلاً للبحث والنسخ بعد الدمج.
وترتيب الرفع هو ترتيب المخرجات افتراضياً. ويقبل نموذج HTTP أجزاء fileInput متكررة في طلب واحد، وحجم الدفعة محدود بحدود الرفع لا بسقف صارم من ملفين. ويعيد sortType=byFileName الاختياري ترتيب المدخلات بالاسم قبل الدمج. والإشارات المرجعية من كل مصدر قد تنجو؛ فالدمج لا يخترع شجرة تفصيلية متقنة إن لم تكن المدخلات تملكها.
ورفع ملف واحد تمرير لا يفعل شيئاً بذلك الملف. أما ملفان أو أكثر فيصيران ملفاً واحداً merged.pdf صفحاته سلسلة المدخلات بالترتيب المختار. والمعرّف نفسه هو ما تعرضه OpenAPI وMCP وpdfx merge فلا يختلف سكربت ونقرة متصفح سراً في معنى «الدمج».
متى يسطّح الناس الناتج من غير قصد
بعض سير عمل «الدمج» يصدّر إلى صور أولاً (بوابات الفاكس، وتطبيقات المسح، والطباعة إلى PDF بدقة الشاشة)، أو يسطّح التعليقات إلى خرائط نقطية قبل الوصل. فيقفز حجم الملف، وقد يلزم تشغيل OCR من جديد، ويُظهر التقريب حواف البكسلات.
فضّل الدمج على مستوى التدفقات حين تكون المصادر ملفات PDF رقمية أصلاً. ولا تفضّل OCR إلا حين تكون المدخلات مسحات بلا نص صالح للاستخدام، وتذكّر أن OCR هنا يعيد Markdown (text/markdown) لا ملف PDF بطبقة نصية مخفية معادة. والتحويل إلى صور ثم تشغيل OCR مسار منتج مختلف عن دمج ملفات رقمية أصلية.
وإن كنت تحتاج صوراً للصفحات، فتلك مهمة تحويل (PDF إلى صور) لا دمج. وخلط هذين القصدين هو ما يحوّل الملفات «المدمجة» إلى ألبومات صور بميغابايتات متعددة للمستندات. ولا يزال الضغط بعد دمج بنيوي قادراً على تصغير التدفقات (الضغط)، لكنه لا يتراجع عن تسطيح نقطي حبسته أنت.
ما لا يَعِد به الدمج
لا يوحّد الدمج مقاسات الصفحات، ولا يجمع الخطوط بين الملفات، ولا يعيد بناء فهرس محتويات من الصفر. ولا يفكّ تشفير المدخلات نيابةً عنك؛ فافتح القفل أولاً إن كان المصدر محمياً بكلمة مرور. ولا يقوم مقام صيغة حاوية الملفات المتعددة التي تتوقعها بعض بوابات المحاكم؛ إنه ينتج ملف PDF عادياً متعدد الصفحات.
وهذه الحدود واحدة سواء استخدمت المتصفح أو REST أو MCP أو pdfx. فالعملية ضيّقة عمداً كي يبقى الناتج متوقعاً في الأتمتة. وإن احتجت عملاً متعدد الخطوات مرتّباً، مثل الدمج ثم العلامة المائية ثم الضغط، فاستخدم POST /api/v1/pipeline مع قائمة steps مرتّبة بدل اختراع علم «دمج ذكي» ثانٍ.
كيف تشغّله
دمج ملفات PDF في المتصفح، أو POST /api/v1/general/merge-pdfs بأجزاء fileInput متكررة، راجع المطوّرين. ومن غلاف الطرفية:
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 أيضاً، راجع العملية نفسها، أربعة عملاء.