إما أن يطابق ملف PDF معيار PDF/A-3 أو لا يطابقه. فلماذا نفحص الملف نفسه بمحركين؟

الإجابة المختصرة: لأن المواصفة كبيرة بما يكفي لأن تختلف تطبيقات صحيحة عند الحواف، ولأن سير العمل الصالح للتدقيق يتعامل مع نتيجة “Pass” من محرك واحد كضوء أصفر، لا أخضر. هذه هي النسخة الطويلة.

PDF/A مجموعة قواعد متفاوض عليها، لا خوارزمية واحدة

يمتد PDF/A عبر عدة أجزاء من ISO 19005:‏ PDF/A-1 وPDF/A-2 وPDF/A-3 وPDF/A-4، ومعها مستويات b وa وu وe وf. وفوق ذلك كله يعتمد على مواصفة PDF الأساسية ISO 32000. مساحة القواعد هنا آلاف الصفحات.

أمثلة على مناطق يحدث فيها اختلاف:

الشفافية في PDF/A-2/3: مسموحة بشروط محددة، لكن تفسير الشروط قد يختلف.
ملفات ICC اللونية: هل الملف مطلوب أم موصى به فقط؟ بعض المحركات تشدد أكثر من غيرها.
بيانات الملفات المرفقة في PDF/A-3:‏ AFRelationship و/AF وXMP يجب أن تتطابق بدقة.
تجزئة الخطوط: خطوط CID والـ subsets الجزئية قد تكشف اختلافات دقيقة بين المحركات.

هذه ليست بالضرورة bugs. إنها النتيجة الطبيعية لمواصفة معقدة تنفذها فرق مستقلة من نص معياري. الموقف المحافظ، وهو موقف معظم القطاعات المنظمة، هو طلب تأكيدات مستقلة متعددة.

محرك مرجعي ورأي مستقل

veraPDF هو التطبيق المرجعي الذي ترعاه PDF Association، وهي الجهة التي تنشر PDF/A. إنه مفتوح المصدر، ومدقق من مجموعات عمل صناعية، وقواعده هي التفسير canonical لنص ISO 19005. إذا قال veraPDF إن الملف “Pass”، فهذه أقوى إشارة يمكنك الحصول عليها من محرك واحد.

لكن أقوى إشارة من محرك واحد لا تعني دليلًا ينجح في التدقيق. المدققون في مؤسسات منظمة، مثل البنوك وأرشيفات السجلات الطبية ومكاتب السجلات الحكومية، يطلبون كثيرًا تأكيدًا مستقلًا ثانيًا لأن:

الطرف المستلم قد يستخدم مدققا آخر ويرفض الملف لاحقا.
أي محرك قد يحتوي على خطأ، ولا يمكن كشفه بإعادة تشغيل المحرك نفسه.
مبدأ “تأكيدين مستقلين” مستخدم على نطاق واسع في مجالات الامتثال؛ وترث PDF/A هذا التوقع من حالات الأرشفة.

يعتمد اختيار المحرك الثاني على المتاح:

Adobe Acrobat Preflight مدفوع ومغلق المصدر؛ مناسب كمحرك تأكيد لكنه يحد من قدرة الآخرين على إعادة التحقق.
callas pdfaPilot مدفوع وخيار مؤسسي فعلي، لكنه أيضًا يحد من إعادة التحقق المستقلة.
محرك مفتوح المصدر ثانٍ؛ توجد بعض الخيارات، لكنها غالبًا أقل اكتمالًا من veraPDF.

ما فعلناه في gPdf هو بناء محرك مستقل خاص بنا بـ Rust + WebAssembly كإعادة تنفيذ مقصودة للمواصفة نفسها من فريق مختلف. عندما ينجح المحركان على الملف نفسه، تكون النتيجة أقوى بكثير مما يستطيع أي منهما تقديمه منفردًا. وعندما يختلفان، لديك bug واضح للتحقيق، إما في أحد المحركين أو في الملف.

تقريران من رابط واحد

نستضيف الاثنين على gpdf.com/validator/ مجانًا، بلا تسجيل دخول. يمر الملف على veraPDF وعلى محرك gPdf Edge بالتوازي، ثم تعود التقارير جنبًا إلى جنب.

الاستخدامات المعتادة:

قبل تسليم PDF/A: ارفع الملف، تأكد من نجاح المحركين، وأرفق تقارير JSON كدليل QA.
محرك ينجح وآخر يفشل: لديك bug دقيق؛ قارن التقارير واعثر على الحقل المخالف. غالبًا يكون شيئًا دقيقًا مثل XMP timestamp غير متطابق أو مرجع /AF مفقود في PDF/A-3.
كلاهما يفشل: أصلح الملف من مصدر التوليد.
تدقيق دفعة أرشيف: افحص عينات عشوائية، وسجل report URLs، وأرفقها بورقة العمل. عبارة “تحققنا عبر veraPDF ومحرك مستقل” أقوى من “شغّلنا مدقق المورّد”.

الملف الذي ترفعه لا يغادر الطلب: تعمل المحركات في الذاكرة على Cloudflare Workers، ويتم التخلص من الملف بعد عرض التقرير. لا تسجيل دخول، لا persistence، ولا quota.

النمط نفسه، بشكل أوسع

هذا لا يخص PDF/A وحده. نمط “تأكيدين مستقلين” يمتد إلى:

فواتير Factur-X / ZUGFeRD الإلكترونية: يشغّل gpdf.com/validator/ Mustang (mustangproject.org) على EN 16931 CII XML المضمّن، إلى جانب فحص PDF/A. (التحقق من ZUGFeRD باستخدام Mustang: ما الذي ينجح وما الذي يفشل يشرح سير العمل هذا.)
شهادات TLS: تتم مراجعة كل CA log حديثة عبر monitors متعددة.
قابلية إعادة بناء البرمجيات: ينبغي أن ينتج rebuildان مستقلان من المصدر نفسه مخرجات byte-identical.

عالم الامتثال يعمل بهذه الفكرة منذ عقود. PDF/A فقط تلحق به.

TL;DR

نتيجة “Pass” من محرك واحد ضوء أصفر. نجاح محركين مستقلين ضوء أخضر. كلا المحركين مجانيان في validator: ارفع الملف، واحصل على تقريرين، وأرفقهما بدليل QA. وإذا كان الملف مولدًا عبر gPdf API، فالمدقق هو الإيصال العام بأن API نفذت claim الامتثال.

إذا كنت تبني فوق gPdf API، فإن مرجع E-invoice API (§5) يوضح كيف تخرج Factur-X / ZUGFeRD PDF/A-3 مباشرة. ثم يؤكدها validator خارجيًا. محركان، رفع واحد؛ هذا هو النمط الصالح للتدقيق.