ব্রাউজার-ভিত্তিক পিডিএফ সম্পাদনা কীভাবে কাজ করে (এবং কেন গোপনীয়তা গুরুত্বপূর্ণ)

প্রতিবার যখন আপনি কোনো ক্লাউড-ভিত্তিক পিডিএফ টুলে একটি ডকুমেন্ট আপলোড করেন, তখন সেই ডকুমেন্টটি এমন সার্ভারে থাকে যার উপর আপনার কোনো নিয়ন্ত্রণ নেই, এমন সফটওয়্যার দ্বারা প্রক্রিয়াজাত হয় যা আপনি পরীক্ষা করতে পারেন না, এবং এমন একটি কোম্পানি দ্বারা সংরক্ষিত হয় যাদের নিজস্ব ডেটা সংরক্ষণ ও নিরাপত্তা ব্যবস্থা রয়েছে। অল্প সময়ের জন্য, অন্য কারো পরিকাঠামো আপনার চুক্তিপত্র, ট্যাক্স রিটার্ন, মেডিকেল রেকর্ড বা গোপনীয় ব্যবসায়িক নথি ধারণ করে।

লুরা পিডিএফ ভিন্নভাবে কাজ করে। সবকিছু আপনার ব্রাউজার ট্যাবে, আপনার হার্ডওয়্যারে এবং আপনার অপারেটিং সিস্টেমের মেমরি ম্যানেজমেন্টের মাধ্যমে সম্পন্ন হয়। এই নিবন্ধে সেই প্রযুক্তিগত স্থাপত্য ব্যাখ্যা করা হয়েছে যা এটিকে সম্ভব করে তোলে এবং এর সাথে জড়িত প্রকৌশলগত সুবিধা-অসুবিধাগুলোও তুলে ধরা হয়েছে।

ডকুমেন্ট প্রসেসিং প্ল্যাটফর্ম হিসেবে ব্রাউজার

আধুনিক ব্রাউজারগুলো এখন আর শুধু এইচটিএমএল রেন্ডারার নয়। এগুলো এখন পূর্ণাঙ্গ অ্যাপ্লিকেশন এক্সিকিউশন এনভায়রনমেন্ট, যার মধ্যে রয়েছে:

• জাভাস্ক্রিপ্ট ইঞ্জিন (ক্রোমে ভি৮, ফায়ারফক্সে স্পাইডারমাঙ্কি): প্রায় নেটিভ গতিতে কোড এক্সিকিউট করে
• ওয়েবঅ্যাসেম্বলি (WASM): একটি স্যান্ডবক্সড পরিবেশে কম্পাইল করা C/C++ কোডকে প্রায় নেটিভ গতিতে এক্সিকিউট করে।
• ক্যানভাস এপিআই: পিক্সেল-স্তরে ছবি সম্পাদনার সুবিধা দেয়
• ফাইল সিস্টেম অ্যাক্সেস এপিআই: আপলোড না করেই স্থানীয় ফাইল পড়ার সুবিধা দেয়
• ওয়েব ওয়ার্কার্স: UI ফ্রিজ না করেই ব্যাকগ্রাউন্ড থ্রেডে গণনা চালায়।
• অ্যারেবাফার / ব্লব: মেমরিতে কাঁচা বাইনারি ডেটা (যেমন পিডিএফ বাইট) পরিচালনা করে।

এই সক্ষমতাগুলো সম্মিলিতভাবে একটি পূর্ণাঙ্গ ডকুমেন্ট প্রসেসিং পাইপলাইন তৈরি করে, যার জন্য পাঁচ বছর আগে একটি ব্যাকএন্ড সার্ভারের প্রয়োজন হতো।

তিনটি মূল লাইব্রেরি

লুরাপিডিএফ তিনটি মৌলিক ওপেন-সোর্স লাইব্রেরির ওপর ভিত্তি করে নির্মিত:

পিডিএফ-লাইব্রেরি

pdf-lib হলো যেকোনো জাভাস্ক্রিপ্ট পরিবেশে পিডিএফ ডকুমেন্ট তৈরি ও পরিবর্তন করার জন্য একটি টাইপস্ক্রিপ্ট লাইব্রেরি। এটি পিডিএফ স্পেসিফিকেশনের (ISO 32000) একটি উল্লেখযোগ্য অংশ বাস্তবায়ন করে, যার মধ্যে অন্তর্ভুক্ত রয়েছে:

পৃষ্ঠা তৈরি, পরিবর্তন এবং মুছে ফেলা

• ফন্ট এমবেডিং (স্ট্যান্ডার্ড ১৪টি ফন্ট এবং কাস্টম TTF/OTF ফন্ট উভয়ই)
• ছবি সংযুক্তিকরণ (JPEG, PNG)
• পাঠ্য টীকা স্থাপন ফর্ম ফিল্ড তৈরি এবং পরিচালনা ডকুমেন্টের মেটাডেটা (শিরোনাম, লেখক, তৈরির তারিখ, ইত্যাদি)
• পিডিএফ এনক্রিপশন (AES-128 এবং AES-256) ক্রস-রেফারেন্স টেবিল ব্যবস্থাপনা

LuraPDF যখন একাধিক পিডিএফ ফাইল মার্জ করে, তখন এটি প্রতিটি ডকুমেন্টের পেজ ট্রি পড়তে, শেয়ার্ড রিসোর্সগুলোকে নর্মালাইজ করতে এবং একটি নতুন পিডিএফ তৈরি করতে pdf-lib ব্যবহার করে। কম্প্রেস করার সময়, এটি ইমেজ অবজেক্টগুলোকে নিম্নতর কোয়ালিটি ফ্যাক্টর দিয়ে পুনরায় এনকোড করে। এনক্রিপ্ট করার সময়, এটি Web Crypto API ব্যবহার করে ডকুমেন্টটিতে AES-256 প্রয়োগ করে।

pdf-lib সম্পূর্ণরূপে ArrayBuffer অবজেক্টের উপর কাজ করে — যা ব্রাউজার মেমরিতে থাকা কাঁচা বাইনারি ডেটা। কোনো নেটওয়ার্ক কল করা হয় না।

pdfjs-dist

PDF.js হলো মোজিলা-র পিডিএফ রেন্ডারিং ইঞ্জিন, যা npm-এ pdfjs-dist নামে বিতরণ করা হয়। এই ইঞ্জিনটিই ফায়ারফক্সের বিল্ট-ইন পিডিএফ ভিউয়ারকে শক্তি জোগায় এবং এটি লক্ষ লক্ষ বাস্তব পিডিএফ ফাইলের উপর পরীক্ষিত।

LuraPDF নিম্নলিখিত কারণে pdfjs-dist ব্যবহার করে:

• পৃষ্ঠা রেন্ডারিং: প্রদর্শনের জন্য পিডিএফ পৃষ্ঠাগুলিকে ক্যানভাস ইমেজ ডেটাতে রূপান্তর করা
• টেক্সট নিষ্কাশন: পিডিএফ পৃষ্ঠা থেকে টেক্সট কন্টেন্ট স্ট্রিম পড়া।
• পৃষ্ঠার মেটাডেটা: পৃষ্ঠার মাত্রা, ঘূর্ণন মান এবং বিষয়বস্তুর ধরণ জানা

যখন আপনি LuraPDF ইন্টারফেসে আপনার PDF-এর রেন্ডার হওয়া পৃষ্ঠাটির ভিজ্যুয়াল প্রিভিউ দেখেন, তখন pdfjs-dist প্রতিটি পৃষ্ঠাকে একটি HTML Canvas এলিমেন্টের উপর রেন্ডার করে।

Tesseract.js

Tesseract.js হলো Tesseract OCR-এর WebAssembly-কম্পাইল করা সংস্করণ। Tesseract একটি ওপেন-সোর্স OCR ইঞ্জিন, যা মূলত HP Labs (১৯৮৫) দ্বারা তৈরি এবং বর্তমানে Google দ্বারা রক্ষণাবেক্ষণ করা হয়। এটি অক্ষর শনাক্তকরণের জন্য একটি LSTM (লং শর্ট-টার্ম মেমরি) নিউরাল নেটওয়ার্ক মডেল ব্যবহার করে।

ব্রাউজারে WebAssembly-এর মাধ্যমে Tesseract চালানোর অর্থ হলো:

২২ এমবি WASM বাইনারিটি একবার লোড হয় এবং ব্রাউজার দ্বারা ক্যাশ করা হয়। OCR প্রসেসিং GPU-তে নয়, WebAssembly-এর মাধ্যমে CPU-তে চলে। প্রসেসিং ক্লাউড ওসিআর (যা জিপিইউ ক্লাস্টার ব্যবহার করে) এর চেয়ে ধীরগতির হলেও একই মানের আউটপুট দেয়। আপনার ডকুমেন্টের বিষয়বস্তু কখনো আপনার ডিভাইস থেকে বাইরে যায় না।

২০ পৃষ্ঠার একটি স্ক্যানের জন্য: ব্রাউজারের ওসিআর-এ প্রায় ৩০–১২০ সেকেন্ড সময় লাগে। একটি ক্লাউড সার্ভিসে ২–৫ সেকেন্ড সময় লাগতে পারে। এর মূল বিবেচ্য বিষয় হলো গোপনীয়তা বনাম গতি।

স্থাপত্য: ফাইল থেকে আউটপুট পর্যন্ত

ধরা যাক, আপনি LuraPDF-এ একটি PDF কম্প্রেস করলে যা ঘটে তা এখানে দেওয়া হলো:

১. ফাইল নির্বাচন: আপনি একটি পিডিএফ ফাইল ড্রপজোনে ড্র্যাগ করেন। ব্রাউজারের ফাইল এপিআই ফাইলটিকে একটি অ্যারেবাফারে (ArrayBuffer) পড়ে নেয় — যা ব্রাউজার মেমরিতে থাকা র ডেটা বাইট। কোনো আপলোড হয় না।

২. যাচাইকরণ: একটি দ্রুত যাচাই যে %PDF ম্যাজিক বাইটগুলো ArrayBuffer-এর শুরুতে উপস্থিত আছে।

৩. লোডিং: pdf-lib-এর PDFDocument.load() ক্রস-রেফারেন্স টেবিলটি পার্স করে, অবজেক্ট ট্রি পড়ে এবং ডকুমেন্টটির একটি ইন-মেমরি রিপ্রেজেন্টেশন তৈরি করে।

৪. ইমেজ গণনা: লাইব্রেরিটি ইমেজ এক্সঅবজেক্ট (এমবেডেড ইমেজ) খুঁজে বের করার জন্য পেজের কন্টেন্ট স্ট্রিমগুলো পরীক্ষা করে। প্রতিটি ইমেজের প্রস্থ, উচ্চতা, কম্প্রেশন টাইপ এবং বাইট ডেটা বের করা হয়।

৫. পুনঃ-এনকোডিং: প্রতিটি ছবির জন্য, মূল পিক্সেল ডেটা একটি HTML ক্যানভাস এলিমেন্টে অঙ্কন করা হয়, তারপর canvas.toBlob('image/jpeg', quality) ব্যবহার করে একটি নিম্নতর JPEG কোয়ালিটি ফ্যাক্টরে পুনরায় এক্সপোর্ট করা হয়। মূল ইমেজ অবজেক্টটি ছোট আকারের এনকোডেড সংস্করণ দ্বারা প্রতিস্থাপিত হয়।

৬. ডকুমেন্ট সিরিয়ালাইজেশন: pdf-lib-এর save() মেথডটি পরিবর্তিত ডকুমেন্টটিকে পুনরায় বাইটে সিরিয়ালাইজ করে। অবজেক্ট স্ট্রিমগুলো DEFLATE-কম্প্রেসড হয়।

৭. ডাউনলোড: বাইটগুলোকে একটি Blob অবজেক্টে মোড়ানো হয়, একটি অস্থায়ী অবজেক্ট URL তৈরি করা হয় ( URL.createObjectURL(blob) ), এবং প্রোগ্রাম্যাটিক <a> ক্লিকের মাধ্যমে ব্রাউজারের ডাউনলোড প্রক্রিয়া চালু হয়।

যেকোনো বাহ্যিক সার্ভারে প্রেরিত মোট ডেটা: শূন্য বাইট।

ওয়েব ওয়ার্কার্স: UI-কে রেসপন্সিভ রাখা

পিডিএফ প্রসেসিং একটি সিপিইউ-নির্ভর প্রক্রিয়া। এটিকে মূল জাভাস্ক্রিপ্ট থ্রেডে চালালে ব্রাউজার ট্যাবটি ফ্রিজ হয়ে যেত — ফাইলটি প্রসেস হওয়ার সময় আপনি স্ক্রল করতে, ক্লিক করতে বা অগ্রগতির আপডেট দেখতে পারতেন না।

LuraPDF সমস্ত ভারী গণনা (OCR, বড় PDF পার্সিং, ইমেজ রি-এনকোডিং) ওয়েব ওয়ার্কার-এ চালায় — এগুলি হলো আলাদা জাভাস্ক্রিপ্ট থ্রেড যা ব্যাকগ্রাউন্ডে চলে। প্রধান থ্রেড UI পরিচালনা করে, প্রোগ্রেস বার দেখায় এবং মেসেজ পাসিং (postMessage / onmessage) এর মাধ্যমে ওয়ার্কারের সাথে যোগাযোগ করে।

OCR চালু থাকা অবস্থায়, প্রতিটি পৃষ্ঠা প্রসেস হওয়ার পর একটি প্রোগ্রেস ইভেন্ট ফায়ার হয়। ওয়ার্কার মেইন থ্রেডে { page: 5, total: 20, confidence: 94 } পাঠায়, যা প্রোগ্রেস বারটি আপডেট করে। এই পুরো সময় জুড়ে আপনার UI ইন্টারেক্টিভ থাকে।

স্মৃতি ব্যবস্থাপনা

ব্রাউজারের মেমরি সীমিত। একটি ২০০ মেগাবাইটের পিডিএফ মেমরিতে লোড, প্রসেস এবং সেভ করতে ৪০০-৬০০ মেগাবাইট র‍্যামের প্রয়োজন হতে পারে (মূল বাইট + মধ্যবর্তী ক্যানভাস ডেটা + আউটপুট বাইট)। সীমিত র‍্যামযুক্ত সিস্টেমে এটি মেমরির উপর চাপ সৃষ্টি করতে পারে।

ব্যবহৃত কৌশলসমূহ:

• স্ট্রিমিং পেজ প্রসেসিং: একাধিক পৃষ্ঠার অপারেশনের ক্ষেত্রে, পৃষ্ঠাগুলি প্রসেস করা হয় এবং ব্যবহারের পরে মধ্যবর্তী ক্যানভাস উপাদানগুলি বাতিল করা হয়।
• URL.revokeObjectURL(): গার্বেজ কালেকশন (GC) এর সুযোগ দেওয়ার জন্য ডাউনলোডের পর অস্থায়ী ব্লব ইউআরএলগুলো বাতিল করা হয়। ওয়ার্কার টার্মিনেশন: ওয়েব ওয়ার্কাররা তাদের ব্যবহৃত মেমরি পুনরুদ্ধার করার জন্য কাজ শেষ করার পর টার্মিনেট হয়ে যায়।

খুব বড় ফাইলের (>১০০ এমবি) ক্ষেত্রে, ৮ জিবি বা তার বেশি র‍্যামযুক্ত সিস্টেমে আধুনিক ব্রাউজারগুলো কোনো সমস্যা ছাড়াই তা সামলাতে পারে। পুরোনো বা সীমিত মেমোরির সিস্টেমগুলো ১০০ এমবি বা তার বেশি আকারের সোর্স ফাইল নিয়ে হিমশিম খেতে পারে।

গোপনীয়তা স্থাপত্য

নিরাপত্তা মডেলটি ব্রাউজারের সেম-অরিজিন পলিসি এবং আইসোলেশন আর্কিটেকচারের মাধ্যমে বলবৎ করা হয়:

• কোনো HTTP অনুরোধ নয়: ডকুমেন্ট প্রক্রিয়াকরণের সময় কোনো বাহ্যিক API কল, টেলিমেট্রি বা অ্যানালিটিক্স কল করা যাবে না।
• স্যান্ডবক্সড এক্সিকিউশন: ওয়েব ওয়ার্কাররা এক্সটার্নাল অরিজিনে নেটওয়ার্ক কল করতে পারে না।
• কোনো স্থায়ী স্টোরেজ নেই: প্রক্রিয়াকৃত ফাইলগুলো ব্রাউজার স্টোরেজে (লোকালস্টোরেজ, ইনডেক্সডডিবি, বা ফাইল সিস্টেম অ্যাক্সেস) লেখা হয় না।
• ট্যাব-স্কোপড মেমরি: যখন আপনি ট্যাবটি বন্ধ করেন, তখন এর সাথে যুক্ত সমস্ত ArrayBuffers এবং Blob অবজেক্ট গার্বেজ কালেক্টেড হয়ে যায়।

এই আর্কিটেকচারটি যাচাইযোগ্য: একটি ফাইল প্রসেস করার সময় ব্রাউজারের DevTools-এর নেটওয়ার্ক ট্যাবটি খুলুন। প্রসেসিং অপারেশন চলাকালীন আপনি শূন্য রিকোয়েস্ট দেখতে পাবেন।

ওপেন সোর্স লাইব্রেরি: পরিদর্শনযোগ্য, ব্ল্যাক বক্স নয়

তিনটি মূল লাইব্রেরিই — pdf-lib, pdfjs-dist, এবং Tesseract.js — ওপেন সোর্স এবং গিটহাবে এদের পাবলিক রিপোজিটরি রয়েছে। যে কেউ এগুলোর ইমপ্লিমেন্টেশন পরীক্ষা করে দেখতে পারেন। LuraPDF-এ যে পিডিএফ প্রসেসিং কোডটি চলে, তা কোনো মালিকানাধীন ব্ল্যাক বক্স নয়; এটি একটি পাবলিক কোড, যার প্রকৃত ব্যবহারকারী, বিভিন্ন সমস্যা এবং অবদান রয়েছে।

বিশ্বাসের জন্য এটি গুরুত্বপূর্ণ। যখন কোনো ক্লাউড পরিষেবা বলে "আমরা আপনার ফাইলগুলো প্রসেস ও ডিলিট করি," তখন আপনি তাদের কথা বিশ্বাস করেন। যখন LuraPDF কোনো নেটওয়ার্ক কল ছাড়াই একটি ব্রাউজার স্যান্ডবক্সে ওপেন-সোর্স লাইব্রেরি ব্যবহার করে, তখন আপনি নেটওয়ার্ক ট্যাবটি দেখে সেই দাবি যাচাই করতে পারেন।

ক্লাউড প্রসেসিংয়ের ক্ষেত্রে সুবিধা-অসুবিধা

ব্রাউজার-ভিত্তিক মডেলটির কিছু বাস্তব সীমাবদ্ধতা রয়েছে, যেগুলো নিয়ে সৎ থাকা প্রয়োজন:

গতি: ক্লাউড পরিষেবাগুলিতে জিপিইউ ক্লাস্টার এবং ডেডিকেটেড পরিকাঠামো রয়েছে। একটি বড় ডকুমেন্টে ব্রাউজারে ওসিআর করতে ক্লাউডের সমতুল্য পদ্ধতির চেয়ে ২–১০ গুণ বেশি সময় লাগে। কম্প্রেশন দ্রুত হয় কারণ এটি সরাসরি ক্যানভাস এপিআই ব্যবহার করে।

ফাইলের আকারের সীমাবদ্ধতা: ব্রাউজারের মেমরিই হলো সীমাবদ্ধতা। খুব বড় ফাইল (>৩০০ এমবি) কিছু সিস্টেমে মেমরির সীমাবদ্ধতায় পড়তে পারে। ক্লাউড পরিষেবাগুলিতে এমন কোনো সীমাবদ্ধতা নেই।

প্রসেসিং ক্ষমতা: WASM নেটিভ C++ এর গতির ৪০-৮০% গতিতে চলে। ক্লাউড পরিষেবাগুলো অপ্টিমাইজ করা নেটিভ কোড চালায়। বেশিরভাগ ডকুমেন্টের ক্ষেত্রে এই পার্থক্যটি বোঝা যায় না; তবে ১০০ বা তার বেশি পৃষ্ঠার OCR কাজের ক্ষেত্রে এটি লক্ষণীয়।

বৈশিষ্ট্যসমূহ: কিছু উন্নত পিডিএফ বৈশিষ্ট্যের (পিডিএফ/এক্স কমপ্লায়েন্স চেকিং, প্রফেশনাল কালার ম্যানেজমেন্ট, সিএমওয়াইকে ওয়ার্কফ্লো) জন্য বিশেষায়িত সার্ভার-সাইড টুলের প্রয়োজন হয়। ৯৫ শতাংশ ক্ষেত্রে ব্রাউজার-ভিত্তিক প্রসেসিং কাজ করে।

দৈনন্দিন ডকুমেন্ট প্রক্রিয়াকরণের জন্য—যেমন কম্প্রেস করা, মার্জ করা, সাইন করা, কনভার্ট করা, এবং রিডাক্ট করা—ব্রাউজার-ভিত্তিক মডেলটি যথেষ্ট দ্রুত, স্বভাবতই গোপনীয়, এবং এর জন্য কোনো অ্যাকাউন্ট বা সাবস্ক্রিপশনের প্রয়োজন হয় না।

প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী

LuraPDF কি কোনো টেলিমেট্রি বা ব্যবহারের ডেটা সংগ্রহ করে? লুরা পিডিএফ সামগ্রিক পেজ ভিউ পরিসংখ্যানের জন্য গুগল অ্যানালিটিক্স ব্যবহার করে। ডকুমেন্ট প্রক্রিয়াকরণ কার্যক্রম কোনো অ্যানালিটিক্স ইভেন্ট তৈরি করে না। আপনার ফাইলগুলোর বিষয়বস্তু কখনোই স্থানান্তরিত হয় না।

আমি কি নিশ্চিত করতে পারি যে কোনো আপলোড হচ্ছে না? হ্যাঁ। ডেভেলপার টুলস (F12) খুলুন, নেটওয়ার্ক ট্যাবে ক্লিক করুন, এবং "XHR" বা "Fetch" দিয়ে ফিল্টার করুন। একটি ফাইল প্রসেস করুন। প্রসেসিং চলাকালীন ডকুমেন্ট-সম্পর্কিত কোনো নেটওয়ার্ক রিকোয়েস্ট লক্ষ্য করবেন না।

অন্যান্য পরিষেবার তুলনায় OCR করতে এত বেশি সময় লাগে কেন? ব্রাউজার-ভিত্তিক Tesseract.js, WebAssembly-এর মাধ্যমে সিপিইউ-তে চলে। ক্লাউড ওসিআর পরিষেবাগুলো জিপিইউ ক্লাস্টারে চলে, যা অক্ষরগুলোকে বহুগুণ দ্রুতগতিতে প্রসেস করে। এর অসুবিধা হলো, আপনার ডকুমেন্টটি কখনোই আপনার ব্রাউজার থেকে বের হয় না।

প্রসেসিং চলাকালীন ট্যাবটি বন্ধ করে দিলে কী হবে? প্রসেসিং অবিলম্বে বন্ধ হয়ে যায়। ব্রাউজার ট্যাবের মেমরি থেকে অপ্রয়োজনীয় ডেটা সংগ্রহ করা হয়। ডিস্কে থাকা আপনার মূল ফাইলটি অপরিবর্তিত থাকে।

কোডটি কি ওপেন সোর্স? মূল প্রসেসিং লাইব্রেরিগুলো (pdf-lib, pdfjs-dist, Tesseract.js) ওপেন সোর্স। LuraPDF-এর ইন্টারফেস কোড বর্তমানে ওপেন সোর্স নয়, কিন্তু এর প্রসেসিং পাইপলাইনে শুধুমাত্র ওপেন-সোর্স উপাদান ব্যবহার করা হয়।

ব্রাউজার-ভিত্তিক ডকুমেন্ট প্রসেসিং-এর দিকে এই পরিবর্তন কোনো লোকদেখানো বিষয় নয়। এটি একটি প্রকৃত স্থাপত্যগত সিদ্ধান্ত, যার ফলে গোপনীয়তা ও বিশ্বাসযোগ্যতার ক্ষেত্রে পরিমাপযোগ্য সুবিধা পাওয়া যায় — তবে এর জন্য নিবিড় অপারেশনগুলোতে গতি কিছুটা কমে যায়। যেসব ডকুমেন্ট আপনি অন্য কারো সার্ভারে রাখতে চান না, সেগুলোর জন্য এই আপোসটিই সঠিক।