وثائق PDF/E-1 الهندسية في Delphi مع PDFlibPas

PDF/E-1 هي ملف تعريف الأرشفة للوثائق الهندسية، وتنفذها PDFlibPas بوصفها وضع تأليف تفعّله بـ SetPDFEMode مع فحص مسبق محدود المقدار يقرأ تدفقات المحتوى معاملًا معاملًا. وليس ملف التعريف هذا PDF/A بملصق مختلف: فله نطاق تعريف خاص به، ومطلب بيانات وصفية لدورة الحياة خاص به، وقاعدة واحدة تجعل التحقق من المحتوى أشد مما في أي ملف تعريف أرشفة قابلته

المخرجات الهندسية هي سبب وجود ملف التعريف هذا. مجموعة مخططات لا بد أن تبقى مقروءة ومثبتة عدم التغيير بعد عشرين عامًا، مع تاريخ مراجعات ينجو، ولون يعني الشيء نفسه على الآلة الراسمة في مبنى آخر. تلك المتطلبات تنتج مواصفة تقع مطالبها غالبًا خارج محتوى الصفحة، في البيانات الوصفية وإدارة الألوان، وهو تحديدًا الموضع الذي يخطئ فيه كاتب PDF عام

تعريف خاص به، لا تنويعة على PDF/A

والأول أن تعرف أن تعريف PDF/E-1 لا يمكن إنتاجه بتكييف نمط PDF/A أو PDF/X. فالنطاق XMP مستقل، هو http://www.aim.org/pdfe/ns/id/، وقيمة الإصدار يجب أن تظهر في موضعين: كمدخل معلومات وثيقة وكخاصية XMP مؤهلة بالنطاق. إصدار خاصية XMP وحدها، أو مدخل المعلومات وحده، ينتج ملفًا يحمل النية ويرسب في التحقق

ولنية الإخراج (output intent) شكل محدد بالقدر نفسه. فـ PDF/E-1 تطلب ملف تعريف ICC مضمَّنًا بمعرف النمط الفرعي ISO_PDFE1، وعلى ملف التعريف أن يملك عدد مكونات يطابق عائلة ألوان الجهاز التي تستخدمها الوثيقة فعلًا. وهذه العبارة الأخيرة هي موضع الخطأ الصامت عند المنفذين، لأنها تعني أن النية لا يمكن اختيارها مقدمًا ثم نسيانها

لماذا يحتاج لون الجهاز إلى مسح شامل للوثيقة كلها

لأن فضاءات الألوان تختبئ في قواميس الموارد التي لا يصل إليها مسح على مستوى الصفحة قط. فـ PDF/E-1 تعامل DeviceRGB وDeviceCMYK بوصفهما عائلتين لا تجتمعان في وثيقة، لذا فالتحقق من ملف التعريف يعني معرفة كل فضاء لون جهاز تستخدمه أي شيء في الملف. فالـ form XObject له موارد خاصة، وكذلك النمط (pattern) وكذلك الصورة. ونمط tiling داخل form XObject داخل صفحة يقع على عمق ثلاثة مستويات، والمدقق الذي يفحص موارد الصفحة العلوية فقط سيمرّر وثيقة تستخدم العائلتين معًا

لذا يسجل المسح فضاءات الألوان أثناء المرور على الصفحات والنماذج والصور والأنماط بعبور واحد، ثم يقرر وحدهما إن كان للوثيقة انسجام وهل تنسجم نية الإخراج. والاستدلال نفسه يقود بنية الفحص المسبق عمومًا: العبور الجزئي ينتج نجاحات كاذبة، والنجاح الكاذب في فحص مطابقة أسوأ من لا فحص، لأنه يسجل بوصفه دليلًا

var
  Lib: TPDFlib;
  Diag: WideString;
begin
  Lib := TPDFlib.Create(nil);
  try
    Lib.LoadFromFile('assembly-drawings.pdf');

    if Lib.SetPDFEMode(1) = 0 then
      raise Exception.Create('PDF/E author mode was refused');

    // وضع التأليف يبقي البيانات الوصفية لدورة الحياة متزامنة عند كل حفظ.
    // اسأل قبل الحفظ هل ستجتاز الوثيقة بوابتها الخاصة
    if not Lib.PDFEReadyForSave then
    begin
      Diag := Lib.GetPDFEDiagnostics;
      Writeln('PDF/E blockers: ', Diag);
      Exit;
    end;

    Lib.SaveToFile('assembly-drawings-pdfe.pdf');
  finally
    Lib.Free;
  end;
end;

البيانات الوصفية لدورة الحياة التزام متجدد مع كل حفظ

تطلب PDF/E-1 أكثر من معرف وثيقة. فالمجموعة الدنيا تشمل معرف وثيقة إدارة الوسائط، ومعرف إصدار، وصنف rendition، ووقت الإنشاء، ووقت التعديل، ووقت البيانات الوصفية، وعنوانًا. هذه مفردات تتبع المراجعات، وهي موجودة لأن المخرج الهندسي يُتوقع أن يعاد إصداره لا أن يُكتب مرة واحدة

والنتيجة على أي تنفيذ أن هذه الحقول لا يمكن ضبطها عند إنشاء الوثيقة. فإن كُتب وقت التعديل حين فعّلت الوضع ثم حُررت الوثيقة بعدها، فإن لقطة XMP وحالة الوثيقة الفعلية قد تفرقتا، والمدقق الذي يقارنهما يبلّغ عن تناقض لم يقصده أحد. لذا يزامن وضع التأليف الحقول قبل كل حفظ مباشرة، فتصف البيانات الوصفية البايتات التي ستُكتب لا البايتات التي كانت موجودة حين فُعّل الوضع

وهذا مبدأ عام للبيانات الوصفية للمطابقة يستحق أن يُذكر منفصلًا عن PDF/E: البيانات الوصفية المشتقة مكانها مسار الحفظ لا مسار التحرير. فأي حقل محسوب من حالة الوثيقة يجب أن يُعاد حسابه لحظة تجميد الحالة، وإلا فهو كاش بلا إبطال

القاعدة التي تجعل التحقق من المحتوى صارمًا

لا تسمح PDF/E-1 لمعاملَي قسم التوافق بابتلاع محتوى مجهول. ففي PDF العادي يحيط BX وEX بمنطقة يجب على المستهلك فيها تجاهل المعاملات التي لا يتعرف عليها، وهي فتحة النجاة التي تمكّن المنتج من إخراج بنى أحدث دون كسر القراء الأقدم. وتحت PDF/E-1 تلك الفتحة مغلقة، فأي معامل لا يتعرف عليه الفحص المسبق يُبلَّغ عنه دون شرط، كان داخل قسم توافق أو خارجه

والأثر على المدقق كبير. فهو لا يستطيع تخطي المناطق التي لا يفهمها، أي أن محلل الوسائط عليه فعلًا أن يحلل كل معامل في كل تدفق محتوى. ومن هنا تأتي الحدود. فالعبور محدود بـ 128 مستوى تداخل، ومليون كائن، و64 MiB من المحتوى، وهذه الحدود ليست ضبطًا للأداء. فالملف العدائي أو المعطوب مجردًا يستطيع تقديم مخطط كائنات فيه حلقات أو عمق تداخل يحوّل مدققًا تعاوديًا إلى stack overflow، والحدود هي ما يمنع تمريرة تحقق من أن تصبح متجه هجوم حجب خدمة. والموقف الدفاعي نفسه تصفه مقالة التحليل الآمن لملفات PDF غير الموثوقة

// تحقق مستقل من ملف لم تنتجه أنت، دون تحميله في
// نموذج وثيقة
var
  Issues: TStringList;
  Stream: TFileStream;
  I: Integer;
begin
  Issues := TStringList.Create;
  Stream := TFileStream.Create('incoming.pdf', fmOpenRead or fmShareDenyWrite);
  try
    if CheckCompliancePDFE(Stream, '', 0, Issues) = 0 then
      for I := 0 to Issues.Count - 1 do
        Writeln('PDF/E: ', Issues[I]);
  finally
    Stream.Free;
    Issues.Free;
  end;
end;

ماذا يصلح بوّاب الحفظ وماذا يرفض

يقسم البوّاب عمله إلى مرحلتين، وهذا التقسيم فكرة تصميم نافعة بذاتها. أولًا يطبّع الأشياء القابلة للإصلاح بأمان: أعلام الطباعة للتعليقات، وعلمَي منع التكبير ومنع الدوران على تعليقات النص، وعلم توليد المظهر في قاموس النموذج. هذه إعدادات لها قيمة صحيحة واحدة تحت ملف التعريف وبلا محتوى معلوماتي، فإصلاحها بصمت صواب، والرفض بسببها توسّع لا داعي له

ثم يفحص القيود التي لا تُصلح دون تغيير ما تعنيه الوثيقة: الإصدار، والتعريف، والتشفير، ونية الإخراج، وانسجام لون الجهاز، ووجود محتوى نماذج ديناميكي. والوثيقة التي تُخفق في أي منها تُرفض، لأن اختراع نية إخراج أو اختيار عائلة ألوان نيابة عن المؤلف ينتج ملفًا يجتاز التحقق ويصف المحتوى وصفًا كاذبًا

وقراءة التشخيصات عبر GetPDFEDiagnostics قبل الحفظ تحوّل الرفض إلى قائمة قابلة للتنفيذ بدل عملية فاشلة. وفي خط معالجة دفعي، استدعها على كل وثيقة، وسجّل المعوقات لكل ملف، وحوّل الإخفاقات إلى طابور ينظر فيه إنسان. وهذا أنفع بكثير من حفظ يرفع استثناء، لأن المعوقات تتجمع عادة: أربعون وثيقة تخفق لنفس نية الإخراج المفقودة إصلاحها واحد لا أربعون

الاختيار بين ملفات تعريف الأرشفة

PDF/E-1 هي الهدف الصائب حين يكون المخرج وثائق هندسية بدورة حياة مراجعات، وتحديدًا حين يهم انسجام لون الجهاز لأن الإخراج يذهب إلى آلات رسم وطابعات كبيرة الصيغة. وPDF/A هي الهدف الصائب حين يكون الغرض قابلية قراءة طويلة الأمد للوثائق عمومًا، وهي ملف التعريف الأوسع دعمًا بين المدققين. والاثنان غير قابلين للتبادل، ووثيقة قد تجتاز أحدهما وترسب في الآخر

إن كنت تختار، فابدأ ممن يتحقق من الملف في الطرف الآخر. فأدوات التحقق من PDF/A في كل مكان، والفحص المسبق الموافق لها في PDFlibPas مشروح في الفحص المسبق لـ PDF/A وPDF/UA. أما التحقق من PDF/E فأكثر تخصصًا وهو عادة متطلب تعاقدي لا خيار افتراضي. وحين يلزم إدخال أرشيف قائم إلى ملف تعريف لم يُكتب له أصلًا، فمسار إصلاح البيانات الوصفية في التحويل إلى PDF/A مع إصلاح البيانات الوصفية هو النمط الذي تتبعه، والشكل نفسه ينطبق هنا: عرّف، وأصلح ما هو آمن، وارفض الباقي بقائمة

وضع التأليف والفحص المسبق المحدود للمحتوى وفحص المطابقة المستقل كلها ترد مع مكتبة PDFlibPas Delphi PDF، فيمكن إنتاج وثيقة تحت ملف التعريف والتحقق منها لاحقًا باستقلال عبر مسار كود منفصل، وهذا هو الترتيب الوحيد الذي يستحق الثقة في دعوى مطابقة