ব্রাউজার-ভিত্তিক PDF এডিটিং কীভাবে কাজ করে (এবং গোপনীয়তা কেন জরুরি)

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

LuraPDF ভিন্নভাবে কাজ করে। সবকিছু আপনার ব্রাউজার ট্যাবে, আপনার হার্ডওয়্যারে, আপনার অপারেটিং সিস্টেমের মেমরি ম্যানেজমেন্টের মাধ্যমে ঘটে। এই নিবন্ধটি সেই প্রযুক্তিগত আর্কিটেকচার ব্যাখ্যা করে যা এটিকে সম্ভব করে এবং এর সাথে জড়িত ইঞ্জিনিয়ারিং আপসগুলি।

নথি প্রক্রিয়াকরণ প্ল্যাটফর্ম হিসেবে ব্রাউজার

আধুনিক ব্রাউজারগুলি আর শুধু HTML রেন্ডারার নয়। এগুলি পূর্ণাঙ্গ অ্যাপ্লিকেশন এক্সিকিউশন পরিবেশ যেখানে রয়েছে:

• JavaScript ইঞ্জিন (Chrome-এ V8, Firefox-এ SpiderMonkey): প্রায় নেটিভ গতিতে কোড চালায়
• WebAssembly (WASM): একটি স্যান্ডবক্সড পরিবেশের মধ্যে প্রায় নেটিভ গতিতে কম্পাইল করা C/C++ কোড চালায়
• Canvas API: পিক্সেল-স্তরে ইমেজ ম্যানিপুলেশন সক্ষম করে
• File System Access API: আপলোড ছাড়াই লোকাল ফাইল পড়তে দেয়
• Web Workers: UI ফ্রিজ না করে ব্যাকগ্রাউন্ড থ্রেডে গণনা চালায়
• ArrayBuffer / Blob: মেমরিতে কাঁচা বাইনারি ডেটা (যেমন PDF বাইট) পরিচালনা করে

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

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

LuraPDF তিনটি মৌলিক ওপেন-সোর্স লাইব্রেরির উপর নির্মিত:

pdf-lib

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

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

LuraPDF যখন PDF মার্জ করে, তখন এটি প্রতিটি নথির পেজ ট্রি পড়তে, শেয়ার করা রিসোর্স নরমালাইজ করতে এবং একটি নতুন PDF অ্যাসেম্বল করতে pdf-lib ব্যবহার করে। যখন এটি কম্প্রেস করে, তখন ইমেজ অবজেক্টগুলি কম মানের ফ্যাক্টর দিয়ে পুনরায় এনকোড করে। যখন এটি একটি ফাইলে পাসওয়ার্ড দেয়, তখন আপনার পাসওয়ার্ড থেকে একটি কী তৈরি করে এবং PDF Standard Security Handler ব্যবহার করে একটি এনক্রিপ্টেড নথি লেখে, যা প্রতিটি রিডার বোঝে।

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

pdfjs-dist

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

LuraPDF pdfjs-dist ব্যবহার করে:

• পেজ রেন্ডারিং: প্রদর্শনের জন্য PDF পৃষ্ঠাগুলিকে Canvas ImageData-তে রূপান্তর করা
• টেক্সট এক্সট্রাকশন: PDF পৃষ্ঠাগুলি থেকে টেক্সট কন্টেন্ট স্ট্রিম পড়া
• পেজ মেটাডেটা: পৃষ্ঠার মাত্রা, রোটেশন ভ্যালু এবং কন্টেন্ট টাইপ পাওয়া

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

Tesseract.js

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

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

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

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

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

ধরুন আপনি LuraPDF-এ একটি PDF কম্প্রেস করছেন — তখন কী হয়:

1. ফাইল নির্বাচন: আপনি ড্রপজোনে একটি PDF টেনে আনেন। ব্রাউজারের File API ফাইলটিকে একটি ArrayBuffer-এ পড়ে — ব্রাউজার মেমরিতে কাঁচা বাইট। কোনো আপলোড হয় না।

2. যাচাইকরণ: ArrayBuffer-এর শুরুতে ম্যাজিক বাইট %PDF আছে কিনা একটি দ্রুত পরীক্ষা।

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

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

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

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

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

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

Web Workers: UI রেসপন্সিভ রাখা

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

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

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

মেমরি ম্যানেজমেন্ট

ব্রাউজার মেমরি সীমিত। মেমরিতে লোড করা একটি ২০০ MB PDF, প্রক্রিয়া করা এবং সংরক্ষণ করতে ৪০০–৬০০ MB RAM প্রয়োজন হতে পারে (মূল বাইট + মধ্যবর্তী Canvas ডেটা + আউটপুট বাইট)। সীমিত RAM সিস্টেমে এটি মেমরি চাপ সৃষ্টি করতে পারে।

ব্যবহৃত কৌশলগুলি:

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

খুব বড় ফাইলের (>১০০ MB) জন্য, আধুনিক ব্রাউজারগুলি ৮+ GB RAM-এর সিস্টেমে কোনো সমস্যা ছাড়াই এটি পরিচালনা করে। পুরনো বা মেমরি-সীমাবদ্ধ সিস্টেমগুলি ১০০+ MB সোর্স ফাইলে সমস্যায় পড়তে পারে।

গোপনীয়তা আর্কিটেকচার

নিরাপত্তা মডেলটি ব্রাউজারের same-origin নীতি এবং আইসোলেশন আর্কিটেকচার দ্বারা প্রয়োগ করা হয়:

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

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

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

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

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

ক্লাউড প্রক্রিয়াকরণ বনাম আপস

ব্রাউজার-ভিত্তিক মডেলে সৎভাবে স্বীকার করার মতো বাস্তব আপস রয়েছে:

গতি: ক্লাউড সার্ভিসে GPU ক্লাস্টার এবং নিবেদিত অবকাঠামো রয়েছে। একটি বড় নথিতে ব্রাউজার OCR ক্লাউড সমতুল্যের চেয়ে ২–১০ গুণ বেশি সময় নেয়। কম্প্রেশন দ্রুত কারণ এটি সরাসরি Canvas API ব্যবহার করে।

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

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

ফিচার: কিছু উন্নত PDF ফিচার (PDF/X কমপ্লায়েন্স চেকিং, পেশাদার কালার ম্যানেজমেন্ট, CMYK ওয়ার্কফ্লো) বিশেষায়িত সার্ভার-সাইড টুল প্রয়োজন। ব্রাউজার-ভিত্তিক প্রক্রিয়াকরণ ৯৫% ক্ষেত্রে কাজ করে।

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

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

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

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

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

প্রক্রিয়াকরণের সময় ট্যাব বন্ধ করলে কী হয়? প্রক্রিয়াকরণ তাৎক্ষণিকভাবে বন্ধ হয়। ব্রাউজার ট্যাবের মেমরি গার্বেজ কালেক্ট হয়। ডিস্কে আপনার মূল ফাইল অপরিবর্তিত থাকে।

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

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