يبدو اختيار واجهة لتوليد PDF سهلا في البداية. لكن السوق مليء بالموردين، وصفحات التسويق متشابهة، ولا تظهر الفروق الحقيقية إلا بعد تشغيل آلاف المستندات في الإنتاج.

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

1. ما صيغة الإدخال: HTML أم JSON أم لغة قوالب؟

هذا أهم سؤال لأنه يحدد ما سيكتبه فريقك وما سيصححه عند حدوث مشكلة في منتصف الليل.

HTML/CSS مثل Puppeteer وDocRaptor وPrince: مألوف ومرن جدا، لكنه مكلف في التشغيل وصعب في الإخراج الحتمي.
JSON / بيانات منظمة مثل gPdf: رخيص في الرندر، متطابق على مستوى البايت، لكنه يحتاج mapper صغيرا من نموذج بياناتك إلى نموذج المستند.
لغة قوالب مثل PDFKit وReportLab وApache PDFBox: تحكم كامل ومسؤولية كاملة عن الصفحات والتخطيط والخطوط.

لا توجد إجابة صحيحة للجميع. توجد إجابة خاطئة لفريقك. اسأل المهندسين: أين يفضلون تصحيح خطأ pagination يستغرق ثلاث ساعات؟

2. ما زمن cold start وهل هو قابل للتنبؤ؟

بعض المحركات تبدأ في ميكروثوان، خاصة WASM أو binary native. وبعضها يستغرق ثواني، خصوصا المعتمد على Chromium. يظهر الفرق عند ذروة المرور.

اسأل المورد:

ما p99 لأول طلب على worker بارد؟
متى يصبح worker باردا بعد آخر طلب؟
هل تنشرون بيانات cold start في صفحة الحالة؟

إن لم تكن الإجابة رقما، افترض أنها سيئة.

3. كيف تحسب تكلفة كل render؟

النماذج الشائعة:

سعر لكل صفحة: واضح وسهل الميزانية، لكنه مكلف عند التوسع.
اشتراك مع overage: رخيص في أحجام كثيرة، لكنه يحتاج تقدير استخدام جيد.
سعر حسب الحوسبة: تدفع أنت تكلفة Lambda أو الحاويات وذاكرة Chromium والـ cold starts.

احسب الفاتورة عند الاستخدام الحالي و5x و50x. شكل منحنى التكلفة أهم من الرقم الموجود في العنوان.

4. هل الإخراج deterministic؟

أي نفس الإدخال يعطي نفس البايتات. تحتاج ذلك عند diff في CI، أو حفظ فواتير قانونيا، أو حساب hash للأرشفة، أو مراجعة قانونية للمخرجات.

المحركات المعتمدة على المتصفح غالبا لا تكون deterministic بين نسخ Chromium. المحركات native أفضل عادة. اسأل مباشرة: هل ستتغير البايتات إذا حدثتم المحرك؟

5. كيف يتعامل مع الخطوط وCJK وRTL؟

مشكلات الخطوط من أكثر مفاجآت PDF شيوعا. يعمل كل شيء في السوق المحلي، ثم يظهر □□□□ عند دخول سوق يحتاج CJK أو Arabic shaping.

اسأل:

ما الكتابات المضمنة بلا إعداد إضافي؟
ماذا يحدث عند glyph غير معروف؟
هل يمكن إضافة خط في الطلب؟
هل يوجد دعم shaping للنص RTL؟

الإجابة الجيدة تذكر NotoSans CJK وfallback واضحا. “ندعم الخطوط” ليست إجابة كافية.

6. ما ملفات الامتثال المدعومة؟

إن كنت قد تصدر فواتير في الاتحاد الأوروبي، أو تحفظ PDF/A، أو ترفق XML طبيا، أو تستخدم توقيعات رقمية، فاسأل عن الدعم native. “حوّله بأداة أخرى لاحقا” يعني pipeline إضافية عليك تشغيلها ومراقبتها.

الإجابات الجيدة تبدو مثل { profile: "PDF/A-3b" } أو { einvoice: { format: "factur-x", xml: "..." } }.

7. هل الرندر stateless؟ أين تذهب المستندات؟

في stateless rendering يدخل الطلب ويخرج PDF ولا يخزن المورد شيئا. أنت تدير التخزين بنفسك، وهذا أنسب للأنظمة المنظمة.

في stateful rendering يخزن المورد PDF ويعطيك رابطا موقّعا. هذا مريح أحيانا، لكنه يعني أن طرفا ثالثا يحتفظ بنسخ من مستنداتك.

اسأل أين تخزن المستندات، مدة الاحتفاظ، وهل يوجد ضمان مكتوب بعدم التخزين.

8. ماذا يحدث عند الفشل؟

كل renderer يفشل أحيانا. المهم كيف يظهر الفشل.

هل الخطأ 4xx/5xx منظم أم PDF فارغ؟
هل retry idempotent؟
هل تدفع مقابل الفشل؟
هل توجد status page وwebhooks وp50/p99 حسب المنطقة؟
هل لدى المورد synthetic probes؟

افتح صفحة الحالة الآن. إن كانت بلا تفاصيل، فهذا مستوى الشفافية المتوقع بعد الشراء.

بطاقة gPdf

#	السؤال	إجابة gPdf
1	الإدخال	JSON `DocumentRequest`
2	Cold start	5-20 ms، V8 isolate، بلا متصفح
3	التكلفة	$0/$5/$8/$12 شهريا؛ overage $0.00005/صفحة
4	Determinism	نفس البايتات لنفس إصدار المحرك
5	الخطوط	NotoSans CJK وfallback لاتيني مدمجان
6	الامتثال	PDF/A-1b/2b/3b/4 وFactur-X / ZUGFeRD
7	Stateless	نعم، بلا تخزين مستندات
8	الفشل	صفحة حالة عامة وأخطاء منظمة وidempotency

نخسر عندما يكون الإدخال HTML لا يمكن تغييره. عندها قد يكون DocRaptor أو Prince أفضل.

الخلاصة

لا تسأل عن “أفضل API للـ PDF”. اسأل هذه الأسئلة الثمانية، قيّم الإجابات، واختر المورد المناسب لعبء العمل الفعلي. إن كانت مستنداتك فواتير أو إيصالات أو بيانات منظمة، يمكنك تجربة gPdf من Playground.