আমার PDF কেন প্রায় ছোটই হলো না?
কম্প্রেসারে PDF চালালাম, 4.1 MB থেকে হলো 4.0 MB। টুলটা কি নষ্ট?
PDF আসলে একটা ফাইল কেবিনেট
যে ধারণাটা হতাশার জন্ম দেয় তা হলো PDF-কে ডকুমেন্টের একটা ছবি ভেবে নেওয়া। এটা তা নয়। ISO 32000-এ সংজ্ঞায়িত PDF হলো নম্বর দেওয়া অবজেক্টের একটা কন্টেইনার: পেজ ট্রি, ড্রয়িং অপারেটরে ভরা কনটেন্ট স্ট্রিম, এমবেড করা ফন্ট প্রোগ্রাম, ইমেজ XObject, ফর্ম ফিল্ড, অ্যানোটেশন, আউটলাইন, আর একটা ক্রস-রেফারেন্স টেবিল যা বলে দেয় কোন অবজেক্ট কোথায় শুরু হয়েছে।
এই অবজেক্টগুলোর বেশিরভাগ আগে থেকেই কম্প্রেস করা। কনটেন্ট স্ট্রিম সাধারণত Flate-এনকোড করা, যা ZIP ফাইলের সেই একই অ্যালগরিদম। এমবেড করা ছবি সাধারণত DCT স্ট্রিম হিসেবে জমা থাকে, অর্থাৎ অপরিবর্তিত অবস্থায় চালান করে দেওয়া JPEG ডেটা। তাই সাধারণ কাজের কোনো কম্প্রেসার যখন একটা PDF-এর দিকে তাকায়, সে আসলে এমন একটা বাক্সের দিকে তাকায় যার প্রতিটি জিনিস আগেই একবার করে কম্প্রেস হয়ে গেছে।
কিছু কম্প্রেস করার আগে দেখে নিন বাইটগুলো কোথায়
সবচেয়ে কাজের পরীক্ষাটা হলো আপনার ডকুমেন্টটা কোন ধরনের তা জেনে নেওয়া, কারণ এটাই ফলাফল প্রায় পুরোপুরি আগেভাগে বলে দেয়।
| ডকুমেন্টের ধরন | বাইটগুলো কোথায় | স্ট্রাকচারাল সেভ কী করতে পারে |
|---|---|---|
| ওয়ার্ড প্রসেসরে বানানো লেখার রিপোর্ট | এমবেড করা ফন্ট প্রোগ্রাম আর ছোট কনটেন্ট স্ট্রিম | খুব সামান্য; কনটেন্ট আগে থেকেই ঠাসা |
| স্ক্যান করা পাতা | প্রতি পাতায় একটা বড় ইমেজ | ইমেজে হাত না দিলে প্রায় কিছুই নয় |
| প্রেজেন্টেশন থেকে করা এক্সপোর্ট | এমবেড করা ছবি আর গ্রেডিয়েন্ট | কিছুটা, যদি একই ইমেজ একাধিক স্লাইডে থাকে |
| ইঞ্জিনিয়ারিং ড্রয়িং | লম্বা ভেক্টর কনটেন্ট স্ট্রিম | কিছুটা, স্ট্রিম আবার এনকোড করে আর অব্যবহৃত অবজেক্ট সরিয়ে |
| সংযুক্তিসহ ফর্ম | এমবেড করা ফাইল, JavaScript, অ্যানোটেশন ডিকশনারি | অনেকটাই, বাড়তি জিনিসগুলো সরানো গেলে |
স্ট্রাকচারাল সেভ আসলে কী সরায়
স্ট্রাকচারাল সেভ ডকুমেন্টটা নতুন করে লেখে, কোনো পাতা দেখতে কেমন তা না বদলেই। এটা এমন অবজেক্ট বাদ দিতে পারে যেগুলোকে আর কিছুই রেফার করে না — ডকুমেন্ট এডিট করে ইনক্রিমেন্টাল সেভ করার প্রতিবার এমন অবজেক্ট জমতে থাকে। এটা ক্রস-রেফারেন্স টেবিল কম্প্রেস করতে পারে আর ছোট অবজেক্টগুলোকে অবজেক্ট স্ট্রিমে গুছিয়ে রাখতে পারে। এটা ডকুমেন্টের মেটাডেটা, থাম্বনেইল আর কিছু সফটওয়্যারের ফেলে যাওয়া এডিটিং ইতিহাসও বাদ দিতে পারে।
যে ডকুমেন্ট বহুবার এডিট করে আবার সেভ করা হয়েছে, তার ক্ষেত্রে এটা বড় লাভ হতে পারে। কিন্তু ওয়ার্ড প্রসেসর থেকে একবারেই পরিষ্কারভাবে এক্সপোর্ট করা ডকুমেন্টে কুড়িয়ে নেওয়ার মতো কিছুই থাকে না: ফাইলটা আগে থেকেই নিজের সবচেয়ে ছোট রূপের কাছাকাছি, আর চার মেগাবাইট থেকে একশো কিলোবাইট কমা ঠিক সেই ফলাফল যা আশা করা উচিত।
লেখার ডকুমেন্ট কেন বাগ মানে না
লেখার PDF-এ ফাইলের বড় একটা অংশ সাধারণত এমবেড করা ফন্ট। ফন্ট প্রোগ্রাম একটা ছোট বাইনারি, যাতে গ্লিফের আউটলাইন আর হিন্টিং নির্দেশ থাকে, আর সেটা ওখানে আছে কারণ যে মেশিনে ওই টাইপফেস ইনস্টল করা নেই সেখানেও ডকুমেন্টটাকে হুবহু একইভাবে রেন্ডার হতে হবে। আরও সাবসেট না করে বা একেবারে সরিয়ে না দিয়ে এটাকে কম্প্রেস করে ফেলা যায় না, আর সরিয়ে দিলে পাতাটা দেখতে বদলে যায়।
লেখাটা নিজে খুবই ছোট। একশো পাতার গদ্য কম্প্রেশনের আগেও কয়েকশো কিলোবাইট অক্ষর মাত্র। আপনার লেখার PDF যদি বড় হয়, তাহলে শব্দগুলোর দিকে না তাকিয়ে ফন্টের দিকে আর লেখার পেছনে লুকিয়ে থাকা ইমেজের দিকে তাকান — হেডারে বারবার আসা একটা লোগো, ব্যাকগ্রাউন্ডের ওয়াটারমার্ক।
স্ক্যান কেন হুড়মুড়িয়ে ছোট হয়
স্ক্যান করা পাতা মানে এক টুকরো কাগজের একটা বড় ছবি, প্রায়ই তোলা হয় প্রতি ইঞ্চিতে 300 ডট বা তারও বেশিতে। 300 DPI-তে একটা A4 পাতা মোটামুটি 2480 × 3508 পিক্সেল — প্রায় 9 মিলিয়ন পিক্সেল, এমন একটা পাতার জন্য যার তথ্যের পরিমাণ কয়েক কিলোবাইট লেখা। এ কারণেই র্যাস্টারাইজড কম্প্রেশনে স্ক্যান এত নাটকীয়ভাবে সাড়া দেয়: রেন্ডার রেজোলিউশন কমিয়ে আর পাতার ইমেজগুলো আবার এনকোড করে ফাইলের ঠিক সেই অংশে আঘাত করা হয় যেটা সত্যিই বড়।
আর এ কারণেই মোডটা ধ্বংসাত্মক। একটা পাতা ছবি হয়ে গেলে সার্চযোগ্য টেক্সট লেয়ার, লিংক, ফর্ম ফিল্ড, অ্যানোটেশন, ট্যাগ করা অ্যাক্সেসিবিলিটি কাঠামো আর যেকোনো ডিজিটাল স্বাক্ষর — সব হারিয়ে যায়। স্ট্রাকচারাল সেভ হতাশ করলে চুপচাপ বিকল্প হিসেবে ব্যবহার না করে FileSlimmer র্যাস্টারাইজেশনকে আলাদা, স্পষ্ট নাম দেওয়া একটা মোড হিসেবেই রাখে, সঙ্গে ওই সতর্কবার্তা জুড়ে দিয়ে।
কেন কেউ আপনাকে একটা সংখ্যার নিশ্চয়তা দিতে পারে না
PDF-এর টার্গেট সাইজ আসলে রেন্ডার রেজোলিউশন আর ইমেজ কোয়ালিটির উপর চালানো একটা খোঁজ, আর সেই খোঁজের একটা তলানি আছে: কোনো একটা রেজোলিউশনের নিচে নামলে স্ক্যানের লেখা আর পড়া যায় না। ওই তলানির উপরে থেকে কোনো নির্দিষ্ট ডকুমেন্ট নির্দিষ্ট একটা বাজেটে পৌঁছাবে কি না, তা নির্ভর করে পাতার সংখ্যা, কালির ঘনত্ব, ফটোগ্রাফিক কনটেন্টের পরিমাণ আর স্ক্যানারের নয়েজের উপর। একই সংখ্যক পাতার দুটো ডকুমেন্ট শেষমেশ খুব আলাদা সাইজে গিয়ে দাঁড়াতে পারে।
সৎ আচরণ হলো তলানিতে গিয়ে থেমে যাওয়া আর খোঁজটা কোথায় থামল তা জানানো; FileSlimmer-এর PDF টার্গেট প্রিসেট ঠিক তা-ই করে। যে টুল সব সময়ই আপনার টাইপ করা সংখ্যাটা ছুঁয়ে ফেলে, সে হয় সংখ্যাটা নিয়ে মিথ্যা বলছে, নয়তো সেখানে পৌঁছাতে ডকুমেন্টটাকে ধ্বংস করছে।
টুলকে দোষ দেওয়ার আগে
- PDF-টা স্ক্যান কি না দেখে নিন। এক লাইন লেখা সিলেক্ট করার চেষ্টা করুন: কার্সার যদি কিছুই সিলেক্ট না করে, তাহলে প্রতিটি পাতাই একটা ইমেজ।
- সাইজের সঙ্গে পাতার সংখ্যা মিলিয়ে দেখুন। তিন পাতার 40 MB ফাইল মানে ইমেজে ভারী; 900 পাতার 40 MB ফাইল পুরোপুরি স্বাভাবিক হতে পারে।
- ডকুমেন্টটা এনক্রিপ্ট করা কি না দেখুন। পাসওয়ার্ড দিয়ে সুরক্ষিত PDF আনলক না হওয়া পর্যন্ত আদৌ পুনর্গঠন করা যায় না।
- এতে ডিজিটাল স্বাক্ষর আছে কি না দেখুন। স্বাক্ষর করা ডকুমেন্ট নতুন করে লিখলে স্বাক্ষরটা অকার্যকর হয়ে যায়, আর বড় ফাইলের চেয়ে সেটা সাধারণত খারাপ পরিণতি।
- আপনার আসলে কী দরকার তা দেখুন। যে ছয় পাতা পাঠাতেই হবে সেগুলো আলাদা করে নেওয়া প্রায়ই পুরো নব্বই পাতা কম্প্রেস করার চেয়ে ভালো।
এই কাজের টুল
সূত্র
- ISO 32000-2 — Document management, Portable Document Format
- Adobe — PDF 32000-1:2008, the freely published PDF 1.7 specification
- PDF Association — ISO 32000 and the PDF standards family