این مقاله فارسی موضوع خروجی PDF/A، PDF/X و PDF/UA در Delphi با HotPDF را برای تیمهایی توضیح میدهد که با Delphi، C++Builder، Lazarus/FPC و کامپوننتهای losLab راهکارهای تولیدی میسازند
تمرکز بر تصمیمهای عملی، ریسکها و نکتههای بازبینی است تا خروجی در محیط واقعی قابل اعتماد بماند
زمانی که این موضوع مهم میشود
این موضوع زمانی اهمیت دارد که پردازش PDF، صفحهگسترده یا سند باید در محیط واقعی قابل تکرار، قابل بررسی و قابل پشتیبانی باشد، نه فقط در یک نمونه نمایشی.
- فایلهای ورودی، مجوزها، خروجی مورد انتظار و حالتهای خطا را از ابتدا مشخص کنید
- نام محصولها، نام APIها و نام فایلها را دقیقاً مانند مستندات نگه دارید
- برای پشتیبانی آینده فایلهای آزمون و لاگهای کوتاه نگهداری کنید
گردشکار عملی
نکتههای اصلی متن انگلیسی را به یک گردشکار عملی Delphi تبدیل کنید. محورهای مهم منبع عبارتاند از:
- سه استاندارد ISO، سه تعهد متفاوت
- PDF/A در HotPDF: همهچیز به OutputIntent بستگی دارد
- PDF/X برای چاپ: Trapped، CMYK و پروفایل چاپخانه
- PDF/UA: ساختار باید از ابتدا تولید شود، نه بعداً اضافه
- اعتبارسنجی: به validator اعتماد کنید، نه به viewer
- پرسشهای متداول
ابتدا یک نمونه کوچک و قابل بازتولید بسازید، سپس فراخوانیهای کامپوننت، مدیریت خطا و پیامهای کاربر را به آن وصل کنید. در قالبهای سندی، جزئیات کوچک معمولاً تفاوت بین خروجی قابل اعتماد و خطای پشتیبانینشده را ایجاد میکنند.
نشانههای API و کد
var
Pdf: THotPDF;
ICC: TFileStream;
begin
Pdf := THotPDF.Create(nil);
try
Pdf.FileName := 'invoice-archival.pdf';
Pdf.PDFACompliance := 'B'; // level B: visual fidelity
Pdf.Lang := 'en-US';
Pdf.StandardFontEmulation := False; // embed real fonts, no Base-14 emulation
ICC := TFileStream.Create('sRGB.icc', fmOpenRead);
try
Pdf.AddPDFAOutputIntent('sRGB IEC61966-2.1', '', ICC, 3, 'DeviceRGB');
finally
ICC.Free;
end;
Pdf.BeginDoc;
Pdf.CurrentPage.SetFont('Arial', [], 11);
Pdf.CurrentPage.TextOut(50, 760, 0, 'Archival invoice body');
Pdf.EndDoc;
finally
Pdf.Free;
end;
end;Pdf.PDFXCompliance := 'X-1a';
Pdf.Trapped := 'Unknown'; // mandatory key under ISO 15930
ICC := TFileStream.Create('FOGRA39.icc', fmOpenRead);
try
Pdf.AddPDFXOutputIntent('FOGRA39 (ISO 12647-2:2004)', '', ICC, 4, 'DeviceCMYK');
finally
ICC.Free;
end;
Pdf.BeginDoc;
// draw with CMYK-safe colors, no transparency, no encryption
Pdf.EndDoc;بازبینی پیش از انتشار
پیش از انتشار، فایل خروجی، فراداده، رمزگذاری، رندرینگ یا وضعیت واردشده را بر اساس موضوع مقاله بررسی کنید. نسخه ابزار، نسخه کامپوننت، فایل آزمون و نتیجه مشاهدهشده را ثبت کنید.
نام محصولات، نام APIها و قطعهکدها بدون تغییر حفظ شدهاند تا توسعهدهندگان بتوانند متن را با مستندات و کد منبع تطبیق دهند
مطالعه مرتبط
- مقاله ما درباره خروجی گزارش، قلمها و تصاویر با HotPDF
- مقاله همراه درباره خودکارسازی بررسیهای preflight PDF
- HotPDF Component
نمونههای کد تکمیلی
Pdf.PDFUACompliance := True; // auto-enables tagged PDF
Pdf.Lang := 'en-US'; // set explicitly; empty falls back to 'en'
Pdf.BeginDoc;
Root := Pdf.AddStructureElement(sstDocument, nil);
H1 := Pdf.EmitTaggedHeading(1, Root, 50, 700, 'Quarterly Report');
Para := Pdf.BeginTaggedContent('P', Root);
Pdf.CurrentPage.TextOut(50, 650, 0, 'Revenue grew in all regions.');
Pdf.EndTaggedContent;
Pdf.EndDoc;یادداشتهای تکمیلی
این بخش تکمیلی نسخه کوتاه را به یک راهنمای عملیتر تبدیل میکند و همچنان با عنوان PDF/A, PDF/X, and PDF/UA Output in Delphi: a HotPDF Guide و توضیح پایهٔ انگلیسی آن هماهنگ میماند. متن اصلی باید مشخص کند که مسئله از چه ورودیای شروع میشود، چه خروجیای انتظار میرود و چه وضعیتی باید بهصورت دقیق در validation دیده شود.
در هنگام بازنویسی، ترتیب تصمیمها مهم است: ابتدا شکل داده، سپس محدودهٔ تغییر، بعد وابستگیهای API و در پایان رفتار نهایی. اگر مقاله به انتخاب میان چند مسیر اشاره میکند، توضیح بده چرا یکی از مسیرها برای نگهداری، پشتیبانی و بازتولید خطا قابلدفاعتر است.
هر جا code block، نام فایل، نام API یا مقدار literal وجود دارد، همان مقدار باید بدون تغییر بماند. توضیح پیرامونی میتواند گستردهتر شود، اما نمونهٔ کد باید همان مرجع دقیق باشد تا خواننده بتواند متن را با پروژهٔ Delphi، C++Builder یا Lazarus/FPC خودش تطبیق دهد.
در بخش validation باید از نمونهٔ ورودی کوچک، مقایسهٔ خروجی و ثبت نسخهٔ component یا validator حرف زده شود. اگر رفتار bug fix یا migration توضیح داده میشود، مسیر بازتولید، مشاهدهٔ اولیه و نقطهٔ تأیید باید صریح باشد تا بعداً بتوان regression را بدون حدس دنبال کرد.
این نوع گسترش به صفحه کمک میکند بعد از خواندن اول هم ارزش داشته باشد: برای reviewer بهعنوان توضیح تصمیم، برای support بهعنوان زمینهٔ تشخیص، و برای تیم نگهداری بهعنوان یادداشت قابل استناد هنگام تغییرهای بعدی.
- نام محصول، API، فایل و literal را تغییر نده
- در صورت وجود code block آن را همانطور نگه دار
- validation را با فایل نمونه و خروجی قابل مقایسه توضیح بده
- مسیر تصمیمگیری را بهجای خلاصهٔ خیلی کوتاه روشن کن