تعمیل آڈٹ میں آپ کی PDF/A فائلیں کیوں مسترد ہوتی رہتی ہیں۔

اس کی تصویر بنائیں۔ ایک فنانس ٹیم کلائنٹ کے بیانات اور لین دین کے ریکارڈ کو بطور آرکائیو کر رہی ہے۔ PDF/A پچھلے چھ سالوں سے. ہر فائل میں صحیح میٹا ڈیٹا ٹیگ ہوتا ہے۔ ہر ملازم کا خیال ہے کہ فائل کے محفوظ ہونے کے ساتھ ہی کام ہو گیا ہے۔ پھر ایک ریگولیٹر معمول کے جائزے کے لیے ظاہر ہوتا ہے، ان فائلوں میں سے مٹھی بھر کو ایک توثیق کار کے ذریعے چلاتا ہے، اور ان میں سے آدھی ناکام ہوجاتی ہیں۔

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

لہذا اگر آپ کی آرکائیونگ کی کوششیں ناکام ہو رہی ہیں اور/یا اگر آپ عمل کے دائیں جانب رہنا چاہتے ہیں، تو یہ ہے کہ واقعی کیا غلط ہو رہا ہے اور اس کے لیے ایک مضبوط ورک فلو کیسے قائم کیا جائے PDF/A تعمیل.

PDF/A کی تعمیل زیادہ تر ٹیموں کے احساس سے زیادہ کیوں اہم ہے۔

PDF/A صرف "آرکائیول کے ساتھ پی ڈی ایف" نہیں ہے۔ یہ ایک ایسا فارمیٹ ہے جس کی وضاحت ISO معیارات کے ذریعے کی گئی ہے تاکہ یہ یقینی بنایا جا سکے کہ کوئی دستاویز کھلے گی اور بالکل اسی طرح نظر آئے گی، ابھی، دس سالوں میں، اور پچاس سالوں میں، اس بات سے کوئی فرق نہیں پڑتا ہے کہ اس وقت اسے پڑھنے کے لیے کون سا سافٹ ویئر یا فونٹ انسٹال کیا گیا ہے۔

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

جس کی وجہ سے جب PDF/A تعمیل آرکائیو کی کمی ہے، اسے ٹیکنالوجی کے ساتھ کوئی مسئلہ نہیں سمجھا جاتا ہے۔ اسے ریگولیٹری تعمیل کا مسئلہ سمجھا جاتا ہے، اور اس کی ذمہ داری زیر بحث فرم پر عائد ہوتی ہے۔

PDF/A فائلوں کی توثیق میں ناکام ہونے کی سب سے عام وجوہات

زیادہ تر PDF/A ناکامیاں بار بار آنے والے مسائل کی ایک مختصر فہرست میں واپس آتی ہیں۔ یہ وہ جگہ ہے جہاں چیزیں عام طور پر غلط ہوجاتی ہیں۔

ایسے فونٹس جو مکمل طور پر سرایت شدہ نہیں ہیں۔

بلاشبہ، یہ مسئلہ کی سب سے عام وجہ ہے. پی ڈی ایف/اے فائل کے لیے، دستاویز میں استعمال ہونے والے تمام فونٹس کو فائل میں ایمبیڈ کرنا ضروری ہے تاکہ ناظرین کو اپنی مشین پر فونٹس انسٹال کرنے کی ضرورت نہ پڑے۔ بہت سی مثالوں میں، فونٹ کا صرف ذیلی سیٹ پی ڈی ایف فائل میں سرایت کرتا ہے، جو عام طور پر توثیق کے عمل میں ناکام ہوجاتا ہے۔ حقیقی زندگی کی PDF/A فائلوں پر کیے گئے ماضی کے مطالعے سے، یہ دیکھا گیا ہے کہ آدھے سے زیادہ غیر موافق واقعات فونٹس سے پیدا ہوتے ہیں۔

غیر ڈیوائس سے آزاد رنگ کی جگہیں۔

PDF/A کے تقاضوں کے مطابق، رنگ کو آلہ کے آزاد ICC پروفائلز کے ذریعے بیان کرنا ہوتا ہے تاکہ مسلسل رینڈرنگ کو یقینی بنایا جا سکے، قطع نظر اس کے کہ آپ دستاویز کو دیکھنے کے لیے کون سا ڈسپلے مانیٹر، پرنٹر یا ایپلیکیشن سافٹ ویئر استعمال کرتے ہیں۔ دلچسپ بات یہ ہے کہ PDF/A کی تخلیق میں سب سے عام غلطیوں میں سے ایک میں کچھ رنگ کی جگہ (جیسے سادہ sRGB) پر مبنی دستاویز شامل ہوتی ہے جس میں مطلوبہ ICC پروفائل کی کمی ہوتی ہے۔

میٹا ڈیٹا جو حقیقت سے میل نہیں کھاتا

ہر PDF/A دستاویز میں XMP میٹا ڈیٹا ہونا چاہیے جس میں بتایا جائے کہ PDF/A کا کون سا ورژن (PDF/A-1، -2 یا -3) کی تعمیل کرتا ہے اور کس تعمیل کی سطح پر (A، B یا U)۔ اس طرح کا میٹا ڈیٹا فراہم کرنے میں ناکامی یا اسے ناقص یا گمراہ کن انداز میں فراہم کرنے کا مطلب ہے کہ آڈٹ شروع ہونے سے پہلے ہی فوری ناکامی ہو۔

ایک گندی بڑھتی ہوئی اپ ڈیٹ کی تاریخ

اضافی اپ ڈیٹ موجودہ پی ڈی ایف دستاویز میں اضافی ڈیٹا کو شروع سے پوری دستاویز کو دوبارہ لکھے بغیر شامل کرتا ہے۔ یہ معیاری پی ڈی ایف فائلوں میں ایک آسان آپشن ہے، لیکن اس کے لیے PDF/A فائلیں۔، یہ احتیاط سے کیا جاتا ہے:

• •PDF/A-1 اضافی اپ ڈیٹس کی بالکل اجازت نہیں دیتا ہے۔ کسی بھی ترمیم کو فائل کی مکمل دوبارہ لکھنا پڑتی ہے۔
• •PDF/A-2 اور PDF/A-3 میں، اضافی اپ ڈیٹس کی اجازت ہے۔ تاہم، منسلک ڈیٹا باقی دستاویز کے مطابق ہونا چاہیے۔ غیر ایمبیڈڈ فونٹس کا استعمال کرتے ہوئے نظرثانی کو شامل کرنا، مثال کے طور پر، پوری فائل کو غلط قرار دیتا ہے۔
• •فائل کے ہیڈر میں موجود ورژن نمبر کو بھی دستاویز کے اندرونی کیٹلاگ کے اندر اعلان کردہ ورژن سے ملنے کی ضرورت ہے۔ یہاں ایک مماثلت کھونا ایک آسان چیز ہے اور توثیق کو ناکام کرنے کا ایک آسان طریقہ ہے۔

کسی دستاویز کو PDF/A میں تبدیل کرنا PDF/A کی توثیق کے مترادف نہیں ہے۔

یہ وہ علاقہ ہے جہاں بہت سی کمپنیاں ٹھوکر کھاتی ہیں۔ اور یہ واضح طور پر بیان کیا جانا چاہئے.

تبدیلی ایک دستاویز لیتی ہے، قطع نظر اس کے اصل فارمیٹ (وہ لفظ دستاویز، ایچ ٹی ایم ایل صفحہ، یا پی ڈی ایف ہو)، اور اسے PDF/A فائل. ایسا کرنے میں، سافٹ ویئر میٹا ڈیٹا کا اضافہ کرتا ہے جو نئی تخلیق شدہ فائل کو پی ڈی ایف/اے-مطابق فائل کے طور پر تصدیق کرتا ہے۔

توثیق بالکل مختلف عمل ہے جہاں خصوصی پروگرام اس بات کی تصدیق کرتا ہے کہ فائل واقعی تصدیق شدہ بننے کے لیے تمام تقاضوں کو پورا کرتی ہے۔

لیکن یہاں موڑ ہے: تبدیلی کے مرحلے پر داخل کیا گیا میٹا ڈیٹا ایک دعویٰ ہے، ثبوت نہیں۔ فائل میں اپنے میٹا ڈیٹا میں یہ معلومات شامل ہو سکتی ہے کہ یہ PDF/A-2b کے مطابق ہے، پھر بھی PDF/A-2b توثیق پاس کرنے میں ناکام رہی۔

اسے مزید خراب کرنا، بہت سے مفت اور اوپن سورس PDF/A توثیق کار ہیورسٹکس کا استعمال کریں نہ کہ پوری تفصیلات کے مقابلے لائن بہ لائن موازنہ۔ اس کا مطلب یہ ہے کہ وہ اکثر دعویٰ کریں گے کہ کوئی دستاویز "شاید" درست ہے، جو پہلے تو اچھی خبر لگتی ہے، لیکن یہ یقینی طور پر نہیں ہے۔ تعمیل کی توثیق کا ایک اور طریقہ ضعف ہے، جہاں کوئی شخص محض دستاویز کو کھولتا ہے اور دیکھتا ہے کہ آیا یہ صحیح لگ رہا ہے۔

کم از کم، ہر PDF/A فائل کو یہ کرنے کی ضرورت ہے:

• •تمام فونٹس، تصاویر اور مواد کو براہ راست ایمبیڈ کریں، کسی بھی چیز کا بیرونی حوالہ نہ دیا جائے۔
• •آڈیو، ویڈیو، JavaScript، اور XFA فارموں سے مکمل طور پر پرہیز کریں۔
• •LZW کمپریشن، انکرپشن، اور پاس ورڈ کے تحفظ کو چھوڑ دیں۔
• •ہر انٹرایکٹو فارم فیلڈ کو ایک مناسب ظاہری لغت دیں۔
• •XMP معیار کا استعمال کرتے ہوئے میٹا ڈیٹا اسٹور کریں۔

توثیق کو چھوڑیں، اور آپ کو یقین ہے کہ ان میں سے ہر ایک باکس کو درست طریقے سے چیک کیا گیا ہے، اس کی تصدیق کیے بغیر۔

مطابقت کی سطحیں قابل تبادلہ نہیں ہیں۔

ناکام آڈٹ کا ایک اور پرسکون ذریعہ مطابقت کی سطح کی مماثلت ہے، جہاں ایک فائل تعمیل کی سطح کا دعوی کرتی ہے جو حقیقت میں پوری نہیں ہوتی ہے۔

یہاں دو چیزیں سمجھنے کے قابل ہیں:

معیار خود ایک دوسرے سے مختلف ہیں۔ PDF/A-1، PDF/A-2، اور PDF/A-3 برسوں کے فاصلے پر شائع ہوئے تھے اور ان کے ایک جیسے اصول نہیں ہیں۔ PDF/A-1، مثال کے طور پر، شفافیت یا تہوں کو سپورٹ نہیں کرتا ہے اور صرف A اور B کے موافقت کی سطح پیش کرتا ہے۔ PDF/A-2 شفافیت، تہوں، اور یہاں تک کہ دیگر PDF/A فائلوں کو سرایت کرنے کے لیے نئی سطح کے ساتھ، U.

مطابقت کی سطحیں ایک دوسرے پر بنتی ہیں۔ لیول U میں لیول B کے لیے درکار ہر چیز شامل ہوتی ہے، اور لیول A میں لیول U کے لیے درکار ہر چیز شامل ہوتی ہے، اس کے علاوہ مزید۔ صحیح سطح کا انتخاب صرف ایک تکنیکی تفصیل نہیں ہے، یہ ایک ایسا فیصلہ ہے جس کے حقیقی نتائج ہوں گے کہ آپ کا محفوظ شدہ دستاویزات کئی سالوں سے کس حد تک قابل استعمال ہوگا۔ ایک کلیمز آرکائیو جہاں دستاویزات کو تلاش کے قابل اور متن سے نکالنے کے قابل رہنے کی ضرورت ہے، مثال کے طور پر، کم از کم سطح U کی ضرورت ہے۔ اکیلے لیول B اس کی ضمانت نہیں دے گا۔

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

آڈٹ پروف PDF/A پائپ لائن دراصل کیسی دکھتی ہے۔

ایک قابل دفاع آرکائیونگ عمل عام طور پر اس شکل کی پیروی کرتا ہے:

ماخذ دستاویز کو معمول بنائیں → PDF/A میں تبدیل کریں → آزادانہ طور پر توثیق کریں → فائل کو آرکائیو کریں

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

ایک ٹھوس آڈٹ ٹریل میں شامل ہونا چاہئے:

• •ہر فائل کو کس نے اور کب تبدیل کیا اس کا ریکارڈ
• •استعمال شدہ ٹول کا نام اور ورژن
• •ایک آزاد توثیق کی رپورٹ جو دعوی کردہ مطابقت کی سطح کی تصدیق کرتی ہے، مثالی طور پر ٹائم اسٹیمپڈ اور دستاویز کے ساتھ ہی ذخیرہ شدہ

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

نتیجہ

ایک PDF/A فائل جس کی آزادانہ طور پر توثیق نہیں کی گئی ہے وہ واقعی صرف ایک فائل ہے جو امید کرتی ہے کہ یہ مطابقت رکھتی ہے۔ یہ برسوں تک ٹھیک ہو سکتا ہے، اس وقت تک جب تک کہ کوئی ریگولیٹر محفوظ شدہ دستاویزات کو دیکھنے کے لیے نہ کہے۔ عمارت PDF/A توثیق پائپ لائن میں ایک الگ، خود مختار قدم کے طور پر ایک امید مند آرکائیو کو قابل دفاع میں بدل دیتا ہے، اور بعد میں ادا کرنے کے جرمانے کے مقابلے میں ابھی تعمیر کرنا بہت سستی عادت ہے۔

---