का केवळ काळा बॉक्स पुरेसा नाही
बहुतेक PDF टूल्स वापरकर्त्यांना संवेदनशील मजकुराच्या वर काळा आयत (rectangle) काढून "redact" करण्याची परवानगी देतात. हा आयत स्क्रीनवरील शब्द लपवतो, परंतु मूळ अक्षरे फाईलच्या कंटेंट स्ट्रीममध्ये (content stream) तशीच राहतात. कोणीही तो लपवलेला मजकूर निवडू शकतो, कॉपी करू शकतो किंवा तो काढण्यासाठी एक साधा स्क्रिप्ट चालवू शकतो. दुसऱ्या शब्दांत सांगायचे तर, डेटा अजूनही तिथेच असतो; काळा बॉक्स केवळ एक दृश्य आवरण (visual cover) असतो.
डेव्हलपरसमोर आलेली समस्या
लेखकाला अशा PDF एडिटरची गरज होती जो सर्व्हरवर फाईल्स अपलोड न करता पूर्णपणे ब्राउझरमध्ये चालतो. या मर्यादेमुळे मजकूर काढून टाकण्यासाठी बॅक-एंड (back-end) सेवेवर अवलंबून राहणे अशक्य होते. सध्याचे क्लायंट-साइड (client-side) उपाय केवळ मजकुराच्या वर एक आकार जोडतात, ज्यामुळे मूळ मजकूर तसाच राहतो. आव्हान हे होते की, प्रक्रिया वेगवान आणि दस्तऐवज वापरण्यायोग्य ठेवून मजकूर कायमस्वरूपी काढून टाकणे.
निवडक पेज रॅस्टरलायझेशन: मुख्य कल्पना
संपूर्ण PDF चे इमेजमध्ये रूपांतर करण्याऐवजी—ज्यामुळे फाईलचा आकार वाढेल आणि शोधण्याची क्षमता (searchability) नष्ट होईल—या उपायामध्ये केवळ ज्या पानांमध्ये रेडॅक्शन (redactions) आहे, त्यांचीच रॅस्टरलायझेशन केली जाते. ती पाने बिटमॅप्स (bitmaps) बनतात; इतर सर्व पाने वेक्टर PDF (vector PDF) म्हणून राहतात, ज्यामुळे मजकूर निवडणे, शोधणे आणि फाईलचा लहान आकार कायम राहतो.
या पद्धतीमुळे दस्तऐवज सामान्य वाटतो: १९ पाने स्पष्ट आणि शोधण्यायोग्य राहतात, तर संवेदनशील पान हे केवळ पिक्सेल-आधारित इमेज असते जिथे लपवलेली माहिती आता अस्तित्वात नसते.
विश्वसनीय रूपांतरणासाठी तीन व्यावहारिक नियम
- तीनपट स्केलवर रेंडर करा – बिटमॅप पानांच्या सामान्य रिझोल्यूशनच्या तीनपट स्केलवर तयार केला जातो. कमी रिझोल्यूशनचे रेंडरिंग आजूबाजूच्या वेक्टर पानांच्या तुलनेत अस्पष्ट दिसते, ज्यामुळे संशय निर्माण होऊ शकतो किंवा ते अनप्रोफेशनल वाटू शकते.
- सर्व दृश्य घटक बिटमॅपमध्ये विलीन करा – पान रॅस्टर करण्यापूर्वी अॅनोटेशन्स (annotations), स्वाक्षरी, वॉटरमार्क आणि रेडॅक्शन आयत एकत्र जोडले जातात. एकाच पानावर वेक्टर अॅनोटेशन्स आणि रॅस्टर इमेज एकत्र केल्यास PDF रीडर्स गोंधळू शकतात, ज्यामुळे डिस्प्ले त्रुटी (display errors) येऊ शकतात.
- पिक्सेलऐवजी व्ह्यूपोर्टला (viewport) अँकर करा – अॅनोटेशन्स पानांच्या व्ह्यूपोर्ट कोऑर्डिनेट्सशी (viewport coordinates) जोडलेले असतात. जेव्हा वापरकर्ता झूम करतो, तेव्हा घटक विचलित न होता किंवा विसंगतपणे स्केल न होता योग्य ठिकाणी राहतात, अन्यथा मूळ मजकूर उघड होऊ शकतो.
रेस कंडिशन्सपासून (race conditions) संरक्षण
प्रत्येक पान रेंडर करणे हे एक असिंक्रोनस (asynchronous) कार्य आहे. जर वापरकर्त्याने ब्राउझर विंडो वेगाने रिसाईज केली, तर अनेक रेंडर जॉब्स एकमेकांवर येऊ शकतात, ज्यामुळे कॅनव्हासवर तुटलेले किंवा एकमेकांवर आलेले फ्रेम्स तयार होऊ शकतात. अंमलबजावणीमध्ये प्रत्येक पानासाठी एक 'रेंडर टोकन' (render token) वापरले जाते: प्रत्येक नवीन रेंडर विनंती मागील टोकन अवैध ठरवते, ज्यामुळे जुने कार्य आपोआप रद्द होते. याचा परिणाम म्हणजे जलद UI बदलांमध्येही एक स्मूथ आणि ग्लिच-मुक्त अनुभव मिळतो.
तडजोडी (trade-offs) कशा दिसतात
एखाद्या पानाचे बिटमॅपमध्ये रूपांतर केल्यामुळे कोणताही लपवलेला मजकूर निघून जातो, परंतु त्या पानातील मजकूर शोधण्याची किंवा कॉपी करण्याची क्षमता देखील नष्ट होते.
हे पुढे कुठे जाऊ शकते
निष्कर्ष
साधा काळा बॉक्स डेटा डिलीट करत नाही; तो केवळ तो लपवतो. ज्या पानांना रेडॅक्शनची गरज आहे त्यांचे केवळ उच्च-रिझोल्यूशन बिटमॅप्समध्ये रूपांतर करून आणि उर्वरित PDF वेक्टर-आधारित ठेवून, ब्राउझर-ओन्ली एडिटर संवेदनशील मजकूर कायमस्वरूपी पुसून टाकू शकतो आणि त्याच वेळी दस्तऐवज वेगवान, शोधण्यायोग्य आणि खाजगी ठेवू शकतो. ही पद्धत सुरक्षा आणि वापरण्यायोग्यता यांचा समतोल राखते, परंतु अनेक पाने रेडॅक्ट करताना फाईलचा आकार आणि शोधण्यायोग्यतेवर होणाऱ्या एकत्रित परिणामांकडे वापरकर्त्यांनी लक्ष दिले पाहिजे.