اقتصاديات حجم ملف PDF

SpecSpec: ISO 32000-2, §7.5.7ISO 32000-2 §7.5.7

لمحة سريعة

يمكن لملفي ⁨PDF⁩ أن يبدوا متطابقين بكسلاً ببكسل على الشاشة ويختلفا عشرة أضعاف على القرص. الفرق نادراً ما يكون المحتوى الذي تراه؛ بل كيف جُمِّع الملف في الأسفل. هذه الصفحة جولة في اقتصاديات الحجم: أين تذهب بايتات ملف ⁨PDF⁩ فعلاً، والروافع الأربع التي يُنفِق عليها المؤلف ميزانية البايتات.

إنها رفيقة لماذا تكون الملفات كبيرة لـالأدفاق والمرشِّحات، التي تغطّي كيف يفكّ مرشِّح الترميز. أما هذه فتبقى على الميزانية.

لماذا يهم هذا

حجم الملف نادراً ما يكون مقياس غرور. إنه عرض نطاق في كل تنزيل، وتخزين في كل أرشيف، وزمن استجابة في كل معاينة. فاتورة بحجم 12 MB كان ينبغي أن تكون 400 KB ليست مشكلة تجميلية حين تولّد منها مليوناً في الشهر — إنها فاتورة بثلاثين ضعفاً.

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

الخلاصة المختصرة

فكّر في ملف ⁨PDF⁩ ميزانيةً تنفقها على أربعة بنود.

• النفقات العامة لكل كائن. يحمل كل كائن غير مباشر غلاف N G obj / endobj، ويُتتبَّع بمدخل مراجع تقاطعية واحد. المستند المثقل بالصفحات به آلاف الكائنات الصغيرة، وتتراكم الأغلفة. تُسقِط أدفاق الكائنات ذلك الغلاف لمجموعة كائنات كاملة؛ ولا يزال كل كائن مُحزَّم يحتفظ بمدخل مراجعه التقاطعية الخاص، لكنه مدخل type-2 مدمج.
• بايتات الصورة. لأي مستند به صور فوتوغرافية أو مسوحات، تهيمن الصور، والرافعة الأكبر المفردة هي اختيار المرشِّح — مرشِّح ترميز عديم الفقد مقابل مرشِّح ترميز صورة فاقد هو الفرق بين الميغابايتات والكيلوبايتات.
• بايتات الخط. الخط المُضمَّن الكامل مئات الكيلوبايتات من محارف لا تستخدمها أبداً. تُبقي التجزئة فقط المحارف التي يرسمها المستند فعلاً.
• الفهرس. قسم المراجع التقاطعية الذي يتيح للقارئ العثور على كل كائن يمكن أن يكون هو نفسه دفقاً مضغوطاً بدلاً من نص صريح.

اضبط الأربعة جميعاً فيكون الملف صغيراً. أغفِل واحدة فتهيمن على كل ما أحسنته غير ذلك.

كيف يتعامل ⁨NextPDF⁩ مع هذا

كاتب ⁨NextPDF⁩ مُسلسِل بثٍّ أحادي التمرير: يُلحِق بايتات كل كائن وهي تُنتَج ويسجّل مدخل مراجع تقاطعية كلاسيكياً قيد الاستخدام لكلٍّ منها. ذلك السلوك الافتراضي سريع، وقابل للتنبؤ، ويُنتِج ملفاً مستقر البايتات — لكنه ليس أصغر تخطيط ممكن، و⁨NextPDF⁩ صادق بشأن ذلك.

الرافعة 1 — أدفاق الكائنات (⁨ObjStm⁩)

ملف ⁨PDF⁩ رسم بياني من كائنات غير مباشرة. معظمها قواميس صغيرة: عُقد صفحات، وقواميس تعليقات، وعناصر شجرة بنية، ومدخلات مخطَّط تفصيلي. يدفع كلٌّ منها ضريبة ثابتة — كلمتا obj / endobj، وأرقام الكائن والجيل، ومدخل مراجع تقاطعية يحدد موضعه. على مستند به آلاف الكائنات الصغيرة، تلك الضريبة شريحة ذات شأن من الملف.

يجمع دفق الكائنات كثيراً من تلك الكائنات الصغيرة غير الدفقية في دفق واحد ويضغطها معاً (SpecSpec: ISO 32000-2, §7.5.7ISO 32000-2 §7.5.7). يُسقَط غلاف obj / endobj للمجموعة كلها؛ وتُخزَّن القيم بداخله ظهراً لظهر دون كلمات لكل كائن، ثم تُضغَط بالانكماش كتلةً واحدة — وهو ما يضغط أفضل أيضاً، لأن الضاغط المُزيل للتكرار يرى الآن كل تلك القواميس المتشابهة دفعةً واحدة. مدخل المراجع التقاطعية لا يختفي — لا يزال كل كائن مُحزَّم يحتاج إلى واحد — لكنه يتقلّص إلى مدخل ثنائي type-2 مدمج في دفق المراجع التقاطعية (المزيد عن ذلك في الرافعة 2).

في ⁨NextPDF⁩ يُسلَّم هذا عبر ObjectStreamPacker، مُعالِج لاحق قائم بذاته يأخذ ملف ⁨PDF⁩ بدفق مراجع تقاطعية مكتملاً ويعيد كتابة الكائنات المؤهَّلة في /Type /ObjStm واحد. القواعد التي يتبعها تأتي مباشرةً من المعيار: الكائن المؤهَّل كائن غير دفقي من الجيل-صفر، بعد استثناء الكائنات الخاصة التي يجب أن تبقى قابلة للعنونة مباشرةً. تحظر §⁨7.5.7⁩ تخزين كائن دفق داخل دفق كائنات، فتحتفظ كائنات الدفق — المحتوى، والخطوط، والصور — بمدخلاتها الخاصة؛ ويرفض ObjectStreamPacker إضافةً كائن دفق المراجع التقاطعية الخاص بالمستند (إذ يُعاد كتابته) وقاموس /Encrypt، وكلاهما يجب أن يبقى قابلاً للعنونة مباشرةً. كل ما عداه من الجيل-صفر وغير دفقي يُحزَّم.

Object stream packing (ObjStm) — edition availability

Edition	Availability
Core	○دعم كامل في النواة مفتوحة المصدر عبر ObjectStreamPacker. وهو اشتراك اختياري: يُصدِر السلوك الافتراضي للكاتب أحادي التمرير مدخلات كلاسيكية قيد الاستخدام، فيبقى المُخرَج متطابق البايتات ما لم تفعّل التحزيم. المُحزِّم حتمي، بخط أساسه الذهبي القابل للتكرار الخاص.
Pro	○Not in this edition
Enterprise	○Not in this edition

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

الرافعة 2 — يمكن للفهرس أن يكون دفقاً أيضاً

بمجرد أن تستقر الكائنات داخل دفق كائنات، يتغير شكل الفهرس الذي يشير إليها. يعثر القارئ على كائن مُحزَّم عبر مدخل مراجع تقاطعية مضغوط — مدخل type-2 يسمّي دفق الكائنات والفهرس داخله (SpecSpec: ISO 32000-2, §7.5.8.3ISO 32000-2 §7.5.8.3). ولأن المراجع التقاطعية كلها هي نفسها دفق /Type /XRef، يُحزَم فهرس آلاف الكائنات ثنائياً ويُنكمَش بدلاً من كتابته صفوف نص صريح. تتقلّص الخريطة جنباً إلى جنب مع الإقليم.

يعيد ObjectStreamPacker بناء هذا بالضبط: فيصدر دفق الكائنات الواحد، ثم دفق مراجع تقاطعية مُعاد كتابته يحمل مدخل type-1 مدمجاً لكل كائن مُستبقى ومدخل type-2 لكل كائن مُحزَّم، حافظاً كل رقم كائن كي تبقى المراجع القائمة صالحة.

الرافعة 3 — اختيار مرشِّح الصورة

لأي مستند بصور حقيقية، تقزّم هذه الرافعة البقية. البايتات هي الصورة نفسها؛ ومرشِّح الترميز هو الميزانية. تستقر أسماء المرشِّحات في مجموعة المرشِّحات المعيارية (SpecSpec: ISO 32000-2, §7.4ISO 32000-2 §7.4)، والاختيار بينها قرار حجم:

• FlateDecode عديم الفقد. مثالي للرسم الخطي، ولقطات الشاشة، وأي شيء بلون مسطَّح — ومُهلِك لصورة فوتوغرافية، حيث يعني عديم الفقد كل بايت من الأصل.
• DCTDecode هو ⁨JPEG⁩: فاقد، وللصور الفوتوغرافية الخيار الصحيح بهامش واسع، غالباً تقليلاً بعشرة أضعاف مقابل انخفاض جودة لا يلاحظه أحد.
• JPXDecode هو ⁨JPEG 2000⁩: ضغط مويجي بمنحنى جودة/حجم مختلف، لكنه غير متسق الدعم ومحظور في بعض ملفات الأرشفة.

هذا بالضبط حيث يهمّ كيف يفكّ مرشِّح الترميز، وتلك مهمة مقالة الأدفاق والمرشِّحات. نقطة الاقتصاديات أضيق: الصورة الفوتوغرافية المخزَّنة عديمة الفقد هي أشيع سبب مفرد لملف ⁨PDF⁩ ضخم بلا داعٍ، ولا قدر من تحزيم أدفاق الكائنات سينقذ ملفاً وزنه الحقيقي مسحٌ واحد لم يُحوَّل إلى ⁨JPEG⁩.

الرافعة 4 — تجزئة الخط

الخط المُضمَّن برنامج. يمكن للكامل أن يبلغ عدة مئات من الكيلوبايتات، لأنه يحمل كل محرف رسمه مصمّم المحرف يوماً — آلاف الأحرف عبر نصوص لن تستخدمها أبداً في هذا المستند. تُضمِّن التجزئة فقط المحارف التي يرسمها المستند فعلاً، محوِّلةً ذلك البرنامج إلى كسر صغير من نفسه. خطاب من صفحة واحدة لا يحتاج كامل خط قادر على ⁨CJK⁩؛ يحتاج العشرات القليلة من المحارف التي يضعها. آليات كيفية اختيار المحارف وإعادة فهرستها موضوع خاص بها — راجع الخطوط: الجزء الصعب.

1. Image bytesFor media-heavy files, the largest line item. The filter choice — lossless Flate vs a lossy image codec like DCT (or JPX in a lossy mode) — is the dominant size lever.
2. Font bytesA full embedded font is mostly glyphs you never draw. Subsetting keeps only the used glyphs, often shrinking the program by an order of magnitude.
3. Per-object overheadThousands of small dictionaries each pay an obj/endobj envelope plus a cross-reference entry. Object streams (ObjStm) drop the envelope for the whole group; each object keeps a compact type-2 cross-reference entry.
4. The indexA compressed cross-reference stream with type-2 entries binary-packs and deflates the map of every object, replacing plaintext index rows.

أين تذهب البايتات: الروافع الأربع التي يُنفِق عليها المؤلف ميزانية حجم ملف PDF، بالترتيب الذي تهيمن به عادةً على ملف حقيقي.

مثال عملي

لا توجد واجهة برمجية مُختلَقة لعرضها هنا، لأن أهم قرارات الحجم تُتَّخذ قبل أن تبلغ البايتات الكاتب — والرافعة البنيوية الوحيدة التي يكشفها ⁨NextPDF⁩ اشتراك اختياري واحد. مفاهيمياً، تُقرأ الميزانية هكذا:

• غذِّ الصور الفوتوغرافية بصيغة ⁨JPEG⁩ كي تستقر تحت DCTDecode، لا مُعاد ترميزها عديمة الفقد. المكسب الأكبر اختيار يخص بيانات المصدر، لا عَلَم كاتب.
• دع الكاتب يجزّئ الخطوط المُضمَّنة كي تُشحَن المحارف المرسومة فقط.
• لمستند به كثير من الكائنات الصغيرة، اشترك اختيارياً في تحزيم أدفاق الكائنات، الذي يوجّه الملف المكتمل عبر ObjectStreamPacker لتجميع الكائنات الصغيرة غير الدفقية وإعادة كتابة دفق المراجع التقاطعية.

المسار الافتراضي — مدخلات كلاسيكية قيد الاستخدام، بلا ObjStm — هو خط الأساس الصحيح: حتمي، مستقر البايتات، وسهل التحقق. التحزيم هو الترقية المدروسة حين يكون عدد الكائنات، لا وزن الصورة، هو ما ينفخ الملف.

مفهوم خاطئ شائع

الفخ هو اللجوء إلى زرّ “اضغط الـ⁨PDF⁩” وتوقّع أن يصلح كل شيء. الضغط ليس رافعة واحدة؛ بل أربعاً، ولا يحلّ بعضها محل بعض. تحزيم أدفاق الكائنات لا يستطيع تقليص صورة فوتوغرافية — تلك مهمة مرشِّح الصورة. والـ⁨JPEG⁩ المثالي لا يعوّض خطاً نسيت تجزئته. ولا شيء من ذلك يفيد إن كان الانتفاخ الحقيقي مسحاً بحجم 10 MB مخزَّناً عديم الفقد لأن لا أحد اختار DCTDecode له.

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

الحدود والقيود

الروافع الأربع هي الاقتصاديات البنيوية لحجم الملف. وليست ضماناً عاماً “اجعله أصغر”، ولا يتظاهر ⁨NextPDF⁩ بأنه مُعيد تحسين لملفات ⁨PDF⁩ واردة اعتباطية.

ObjectStreamPacker تحسين ببذل الجهد لا يخاطر بالصحة أبداً. يرفض — مُعيداً المُدخَل دون تغيير — حين لا يكون الملف ملف ⁨PDF⁩ بدفق مراجع تقاطعية، أو حين يكون مشفَّراً، أو حين يحمل توقيعاً رقمياً (إعادة رصّ الكائنات ستزيح نطاقات البايتات التي يحميها توقيع)، أو حين يحوي بالفعل أدفاق كائنات، أو حين لا يوجد كائن مؤهَّل للتحزيم. يصدر دفق كائنات واحداً بالضبط للمستند كله؛ ولا ينقسم إلى مجموعة /Extends، وهي خارج النطاق ومطابقة لأحجام المستندات التي ينتجها ⁨NextPDF⁩.

رافعتا الصورة والخط قرارات تخص المُدخَل إلى حد كبير. كاتب ⁨NextPDF⁩ لا يحوّل ضمنياً صورة نقطية عديمة الفقد إلى دفق صورة فاقد — فإعادة ترميز صورة فوتوغرافية إلى DCTDecode أو JPXDecode قرار ترميز صورة صريح في مرحلة سابقة، لا شيء يفعله المُسلسِل من وراء ظهرك — ولا يستعيد محارف من خط طلب المُستدعي تضمينه كاملاً. أكبر مكاسب الحجم تُتَّخذ سابقةً لمُسلسِل البايتات؛ ومهمة المحرك ألا يهدر الميزانية التي تجلبها إليه.

مستندات ذات صلة

• الأدفاق والمرشِّحات — رفيق كيف يفكّ مرشِّح الترميز؛ تكمّله هذه الصفحة عمداً، لا تكرّره.
• ما هو ملف ⁨PDF⁩ فعلاً — نموذج الكائن غير المباشر الذي تقلّص رافعة دفق الكائنات نفقاته العامة لكل كائن.
• تشريح ملف ⁨PDF⁩ — بنية المراجع التقاطعية التي تصير دفقاً مضغوطاً.
• الخطوط: الجزء الصعب — كيف تختار التجزئة وتعيد فهرسة المحارف التي يرسمها مستند.

Human-factors note:Human-factors note

حين يكون ملف ⁨PDF⁩ كبيراً على نحو غير متوقع، شخّص بترتيب الميزانية، لا بترتيب الذعر. انظر إلى الصور أولاً — صورة فوتوغرافية واحدة عديمة الفقد تفسّر عادةً الملف كله. ثم الخطوط: هل أيٌّ منها مُضمَّن كاملاً بدلاً من مجزّأ؟ بعد ذلك فقط الجأ إلى تحزيم أدفاق الكائنات، الذي يستهدف عدد الكائنات، لا وزن الصورة أو الخط. إصلاح الرافعة الخاطئة هو كيف يبقى ملف بحجم 11 MB بعد ساعة من “التحسين”.

مسرد المصطلحات

• دفق الكائنات (ObjStm) — دفق واحد يحمل كثيراً من الكائنات غير المباشرة الصغيرة غير الدفقية، مضغوطةً معاً، فيُسقَط غلاف obj / endobj للمجموعة. لا يزال كل كائن مُحزَّم يحتفظ بمدخل مراجعه التقاطعية الخاص، مدخل type-2 مدمجاً. اشتراك اختياري في ⁨NextPDF⁩.
• الكائن غير المباشر — كائن مرقَّم في رسم ⁨PDF⁩ البياني، ملفوف في غلاف obj / endobj ومُتتبَّع بفهرس المراجع التقاطعية. الغلاف هو النفقات العامة لكل كائن.
• دفق المراجع التقاطعية — دفق /Type /XRef الذي يفهرس كل كائن، مُحزَّماً ثنائياً ومُنكمَشاً بدلاً من كتابته صفوف نص صريح.
• المدخل المضغوط (type-2) — مدخل مراجع تقاطعية يشير إلى كائن يستقر داخل دفق كائنات، مسمّياً الدفق والفهرس داخله.
• تجزئة الخط — تضمين فقط المحارف التي يرسمها مستند فعلاً، بدلاً من كامل المحرف، مقلّصاً برنامج الخط المُضمَّن.
• المرشِّح عديم الفقد مقابل الفاقد — مرشِّح ترميز عديم الفقد (FlateDecode) يعيد إنتاج كل بايت؛ ومرشِّح ترميز صورة فاقد (DCTDecode، أو JPXDecode في وضع فاقد) يطرح تفصيلاً غير محسوس مقابل نتيجة أصغر بكثير. (يمكن أيضاً تهيئة ⁨JPEG 2000⁩ / ⁨JPX⁩ عديم الفقد.) الاختيار هو الرافعة المهيمنة على ملف مثقل بالوسائط.