ما يحدث فعلاً عند ضغط ملف PDF

قد يبدو ملفا PDF متطابقين على الشاشة بينما يفصل بينهما فارق مقداره ثلاثة أُسّ من الحجم: 50 KB مقابل 50 MB. وهذا الفارق لا يكاد يأتي من عوامل النص؛ ففي عقد من عشرين صفحة لا تتجاوز هذه العوامل عادة بضعة عشرات من الكيلوبايت، بينما يأتي الباقي كله من عيّنات الصور، وخط مُضمَّن بالكامل، ومدى إحكام رصف التدفقات والكائنات.

ولهذا نتيجة تستحق التصريح بها مبكراً: «ضغط PDF» ليس فعلاً واحداً بل أربعة أفعال. كل واحد منها يصغّر شيئاً مختلفاً وله ثمن مختلف، والخلط بينها ينتج تجربة متناقضة: ملف ضُغط ولم يصغر، أو صغر لكن صفحاته فقدت حدّتها.

من أين يأتي الحجم

تبدأ معظم حالات «لماذا هذا الملف بهذا الحجم؟» بمسح ضوئي أو صورة عالية الدقة ما زالت مضمَّنة بحجم التقاطها. والحساب يستحق أن يُجرى مرة واحدة: صفحة بمقاس Letter عند 8.5 × 11 بوصة و300 DPI تبلغ نحو 2550 × 3300 بكسل، وبثلاثة بايتات لكل بكسل فإن ذلك يعادل نحو 25 MB غير مضغوطة. وعشرون صفحة كهذه تصل غالباً إلى 60 إلى 80 MB قبل أن يمسّها أي ضغط.

المصدر الثاني هو الخطوط. يستطيع ملف PDF أن يضمّن برنامج خط كامل حتى تعرضه أي آلة بالشكل نفسه، وتُقدَّر كلفة ذلك بحجم جداول المحارف لا بمقدار النص المقروء فعلاً. ولهذا كان تجزئة الخطوط رافعة حجم منفصلة.

المصدر الثالث هو الرصف نفسه. يمكن تخزين المحتوى نفسه بإعدادات ضغط مسرفة، أو تترك كائناته متناثرة في الملف، كل واحد يحمل نفقاته الدفترية الخاصة. لا شيء من ذلك يغيّر بكسلًا أو محرفًا واحدًا، وهو بالضبط ما تستطيع إعادة ضغط التدفقات الوصول إليه.

«الضغط» أربعة أشياء مختلفة

هناك أربع روافع على الحجم، تعمل في طبقات مختلفة، وثمنها لا يكاد يتقاطع. واختيار الرافعة الخطأ هو السبب الأكثر شيوعاً لظهور عملية الضغط وكأنها لم تفعل شيئاً.

الصفوف الأربعة الأولى تُسمى جميعها «ضغطاً» على سبيل التسامح، لكن الصف الأول وحده هو الذي يترك المحتوى كما هو. وهو أيضاً الصف الذي يسهل إساءة تقدير عائده: ملف مسح يأتي حجمه في معظمه من عيّنات صور خام لم يبقَ فيه إلا القليل من التكرار لتزيله إعادة الضغط، أما الروافع التي قد تقلّصه كثيراً فهي تصغير الدقة وإعادة الترميز بفقدان، وثمنهما فقدان تلك الدقة والجودة إلى الأبد.

أيًّا من الأربعة ينفّذه PDF123 Compress

ضغط ملف PDF (POST /api/v1/misc/compress-pdf) ينفّذ الصف الأول وحده. وهو يشغّل qpdf مع ضغط التدفقات غير المضغوطة (--compress-streams=y)، وتمريرة ثانية على التدفقات المضغوطة أصلاً بـ Flate (--recompress-flate)، ورصف الكائنات في تدفقات الكائنات (--object-streams=generate).

وهو لا يقلّل دقة الصور، ولا يعيد ترميز الخرائط النقطية إلى جودة JPEG أدنى، ولا يجزّئ الخطوط. لذا يُفترض أن تبقى الصفحات كما هي، ويأتي الوفر من إعادة ضغط Flate ورصف تدفقات الكائنات.

وشرط الفشل يستحق الوضوح نفسه. عندما يكون معظم حجم الملف بيانات صور مضغوطة أصلاً بجودة JPEG، لا يبقى لـ Flate ما تعصره، لأن بايتات تلك الصور تقع خارج ما تمسّه المفاتيح الثلاثة أعلاه. ولهذا قد يعود ملف مسح أصغر ببضع نقاط مئوية فقط، بينما يكسب ملف PDF غني بالنص وبالحجم ذاته مكسباً ملحوظاً.

والمسار العكسي هو فك ضغط PDF، الذي يوسّع التدفقات للفحص (--qdf مع تعطيل تدفقات الكائنات)، وهو أيضاً لا يغيّر مظهر الصفحات.

متى يكون المسار الآخر هو الصحيح

ويقع فخّ في الصف الأخير: تخطيط PDF خطياً ليس تنفيذاً مستقلاً هنا، بل هو اسم بديل لـ Compress. كلاهما يشير إلى العملية نفسها، فالمعرّف القياسي هو misc/compress-pdf وlinearize-pdf مجرد بديل، والبوابة ترسل دائماً linearize=true وoptimizeLevel=1 لهذه الأداة، والخادم لا يقرأ أيًّا من الحقلين، ولا يُمرَّر --linearize إلى qpdf قط. أما العملية التي تخطّط الملف خطياً فعلاً فهي حماية عند التشفير.

فإذا كنت تريد المظهر نفسه في ملف أصغر، فـضغط هو الجواب الكامل. وإذا كنت تريد تقليصاً فقدانياً للصور أو تجزئة للخطوط، فهذا المسار هو الرافعة الخطأ. يعود الملف إليك مباشرة، بلا حاجة إلى حساب. ولمعرفة أين تعيش الكائنات والتدفقات وجدول الإحالات المرجعية فعلاً، تابع مع ما يوجد داخل ملف PDF.