مواد پر جائیں
FileSlimmer
ٹولز
رہنما

میری PDF مشکل سے کیوں سکڑی؟

آخری نظرثانی

میں نے اپنی PDF ایک کمپریسر سے گزاری اور وہ 4.1 MB سے 4.0 MB ہو گئی۔ کیا ٹول خراب ہے؟

6 منٹ کا مطالعہ · 17 اگست، 2026 کو نظرثانی شدہ

PDF ایک فائلنگ کیبنٹ ہے

جو تصور مایوسی کا سبب بنتا ہے وہ یہ ہے کہ PDF کو دستاویز کی تصویر سمجھ لیا جائے۔ یہ تصویر نہیں ہے۔ PDF، جیسا کہ ISO 32000 میں بیان کیا گیا ہے، نمبر لگے آبجیکٹس کا ڈبہ ہے: پیج ٹری، ڈرائنگ آپریٹرز سے بھری کنٹینٹ اسٹریمز، شامل شدہ فونٹ پروگرام، امیج XObjects، فارم فیلڈز، اینوٹیشنز، آؤٹ لائنز، اور ایک کراس ریفرنس ٹیبل جو بتاتی ہے کہ ہر آبجیکٹ کہاں سے شروع ہوتا ہے۔

ان میں سے اکثر آبجیکٹ پہلے ہی کمپریس شدہ ہوتے ہیں۔ کنٹینٹ اسٹریمز عموماً Flate سے اینکوڈ ہوتی ہیں، یعنی وہی الگورتھم جو ZIP فائل استعمال کرتی ہے۔ شامل شدہ تصاویر عموماً DCT اسٹریمز کے طور پر رکھی جاتی ہیں، جو بغیر کسی تبدیلی کے گزاری گئی JPEG ڈیٹا ہوتی ہے۔ چنانچہ جب کوئی عام مقصد کا کمپریسر PDF کو دیکھتا ہے، تو وہ ایسی چیزوں کا ڈبہ دیکھ رہا ہوتا ہے جن میں سے ہر ایک پہلے ہی ایک بار کمپریس ہو چکی ہے۔

کچھ بھی کمپریس کرنے سے پہلے دیکھیں کہ بائٹس کہاں ہیں

سب سے کارآمد تشخیص یہ جاننا ہے کہ آپ کے پاس کس قسم کی دستاویز ہے، کیونکہ اسی سے نتیجہ تقریباً پورا پیشگی طے ہو جاتا ہے۔

دستاویز کی قسم کے لحاظ سے PDF کا حجم کس چیز سے طے ہوتا ہے
دستاویز کی قسمبائٹس کہاں ہیںساختی سیو کیا کر سکتا ہے
ورڈ پروسیسر سے بنی متنی رپورٹشامل شدہ فونٹ پروگرام اور چھوٹی کنٹینٹ اسٹریمزبہت کم؛ مواد پہلے ہی گنجان ہے
اسکین کیے ہوئے صفحاتفی صفحہ ایک بڑی تصویرتصاویر کو چھیڑے بغیر تقریباً کچھ نہیں
پریزنٹیشن کا ایکسپورٹشامل شدہ تصاویر اور گریڈینٹسکچھ حد تک، اگر تصاویر کئی سلائیڈوں میں دہرائی گئی ہوں
انجینئرنگ ڈرائنگلمبی ویکٹر کنٹینٹ اسٹریمزکچھ حد تک، اسٹریمز دوبارہ اینکوڈ کر کے اور غیر استعمال شدہ آبجیکٹ ہٹا کر
منسلکات والا فارمشامل شدہ فائلیں، JavaScript، اینوٹیشن ڈکشنریاںبہت کچھ، اگر یہ اضافی چیزیں ہٹائی جا سکیں

ساختی سیو اصل میں کیا ہٹاتا ہے

ساختی سیو دستاویز کو اس طرح دوبارہ لکھتا ہے کہ کسی صفحے کی ظاہری شکل نہیں بدلتی۔ یہ ایسے آبجیکٹ ہٹا سکتا ہے جن کا اب کوئی حوالہ باقی نہیں، اور جو ہر بار دستاویز میں ترمیم کر کے اضافی طور پر سیو کرنے سے جمع ہوتے رہتے ہیں۔ یہ کراس ریفرنس ٹیبل کو کمپریس کر سکتا ہے اور چھوٹے آبجیکٹس کو آبجیکٹ اسٹریمز میں سمو سکتا ہے۔ یہ دستاویز کا میٹا ڈیٹا، تھمب نیل اور وہ ترمیمی تاریخ ہٹا سکتا ہے جو کچھ پروڈیوسر پیچھے چھوڑ جاتے ہیں۔

جس دستاویز میں بار بار ترمیم اور دوبارہ سیو ہوا ہو، اس میں یہ بڑی کامیابی ہو سکتی ہے۔ جو دستاویز ورڈ پروسیسر سے ایک ہی بار، صاف ستھری ایکسپورٹ ہوئی ہو، اس میں سمیٹنے کو کچھ ہوتا ہی نہیں: فائل پہلے ہی اپنی چھوٹی ترین شکل کے قریب ہوتی ہے، اور چار میگا بائٹ میں سے سو کلوبائٹ کم ہونا بالکل وہی نتیجہ ہے جس کی توقع کرنی چاہیے۔

متنی دستاویز مزاحمت کیوں کرتی ہے

متنی PDF میں فائل کا بڑا حصہ عموماً شامل شدہ فونٹس ہوتے ہیں۔ فونٹ پروگرام ایک مختصر بائنری ہوتا ہے جس میں گلف آؤٹ لائنز اور ہنٹنگ ہدایات ہوتی ہیں، اور وہ اس لیے موجود ہوتا ہے کہ دستاویز اُس مشین پر بھی بالکل ویسی ہی نظر آئے جس پر وہ ٹائپ فیس انسٹال نہیں۔ آپ اسے کمپریس کر کے ختم نہیں کر سکتے، جب تک اسے مزید سب سیٹ نہ کریں یا نکال نہ دیں، اور نکالنے سے صفحے کی شکل بدل جاتی ہے۔

متن خود بہت چھوٹا ہوتا ہے۔ سو صفحوں کی عبارت کمپریشن سے پہلے بھی چند سو کلوبائٹ کے حروف ہوتی ہے۔ اگر آپ کی متنی PDF بڑی ہے تو الفاظ کے بجائے فونٹس کو دیکھیں، اور اُن تصاویر کو جو متن کے پیچھے چھپی ہوئی ہیں — ہیڈر میں دہرایا ہوا لوگو، پس منظر کا واٹر مارک۔

اسکین دھڑام سے کیوں سکڑ جاتا ہے

اسکین کیا ہوا صفحہ کاغذ کے ایک ٹکڑے کی ایک بڑی تصویر ہوتا ہے، جو اکثر 300 ڈاٹس فی انچ یا اس سے بھی زیادہ پر لی جاتی ہے۔ 300 DPI پر A4 صفحہ تقریباً 2480 × 3508 پکسل کا ہوتا ہے — یعنی تقریباً 9 ملین پکسل، ایسے صفحے کے لیے جس کی معلومات چند کلوبائٹ متن جتنی ہے۔ یہی وجہ ہے کہ اسکین ریسٹرائزڈ کمپریشن پر اتنا ڈرامائی ردعمل دیتے ہیں: رینڈر ریزولوشن کم کرنا اور صفحوں کی تصاویر دوبارہ اینکوڈ کرنا فائل کے اُسی حصے پر وار کرتا ہے جو واقعی بڑا ہے۔

اور یہی وجہ ہے کہ یہ موڈ تباہ کن ہے۔ ایک بار صفحہ تصویر بن جائے تو قابلِ تلاش متن کی تہہ، لنکس، فارم فیلڈز، اینوٹیشنز، اسکرین ریڈرز کے لیے ٹیگ شدہ ساخت اور کوئی بھی ڈیجیٹل دستخط ختم ہو جاتے ہیں۔ FileSlimmer ریسٹرائزیشن کو ایک الگ، واضح لیبل والے موڈ کے طور پر رکھتا ہے جس کے ساتھ یہی وارننگ لگی ہوتی ہے — نہ کہ ساختی سیو کے مایوس کن نکلنے پر خاموشی سے استعمال ہونے والے متبادل کے طور پر۔

کوئی آپ سے کسی عدد کا وعدہ کیوں نہیں کر سکتا

PDF کے لیے ہدف حجم دراصل رینڈر ریزولوشن اور امیج کوالٹی پر ایک تلاش ہے، اور اس تلاش کی ایک فرش ہے: کسی ریزولوشن سے نیچے اسکین کا متن پڑھا ہی نہیں جاتا۔ اس فرش سے اوپر کوئی خاص دستاویز کسی خاص بجٹ تک پہنچتی ہے یا نہیں، اس کا انحصار صفحوں کی تعداد، سیاہی کے پھیلاؤ، تصویری مواد کی مقدار اور اسکینر کے شور پر ہے۔ ایک ہی تعداد کے صفحوں والی دو دستاویزیں بالکل مختلف حجم پر ختم ہو سکتی ہیں۔

ایمانداری کا رویہ یہ ہے کہ فرش پر رک جایا جائے اور بتا دیا جائے کہ تلاش کہاں رکی — FileSlimmer کے PDF ہدف پریسیٹس یہی کرتے ہیں۔ جو ٹول ہمیشہ وہی عدد پکڑ لے جو آپ نے لکھا تھا، وہ یا تو عدد کے بارے میں جھوٹ بول رہا ہے یا اس تک پہنچنے کے لیے دستاویز تباہ کر رہا ہے۔

ٹول کو الزام دینے سے پہلے

  • دیکھیں کہ PDF اسکین تو نہیں۔ متن کی ایک سطر منتخب کر کے دیکھیں: اگر کرسر کچھ بھی منتخب نہ کرے تو ہر صفحہ ایک تصویر ہے۔
  • صفحوں کی تعداد کو حجم کے سامنے رکھ کر دیکھیں۔ تین صفحوں کی 40 MB فائل تصویروں سے بھری ہے؛ 900 صفحوں کی 40 MB فائل بالکل معقول ہو سکتی ہے۔
  • دیکھیں کہ دستاویز انکرپٹڈ تو نہیں۔ پاس ورڈ سے محفوظ PDF کو اَن لاک کیے بغیر اس کی ساخت بالکل نہیں بدلی جا سکتی۔
  • دیکھیں کہ اس پر دستخط تو نہیں۔ دستخط شدہ دستاویز دوبارہ لکھنے سے دستخط بے کار ہو جاتا ہے، اور یہ عموماً بڑی فائل سے بھی برا نتیجہ ہے۔
  • دیکھیں کہ آپ کو دراصل کیا چاہیے۔ جو چھ صفحے بھیجنے ہیں انہیں الگ کر لینا اکثر پورے نوے صفحے کمپریس کرنے سے بہتر رہتا ہے۔

اس کام کے ٹولز

مآخذ

مزید گائیڈز

FileSlimmer کے تمام گائیڈز