این مقاله فارسی موضوع Delphi PDF Reports with HotPDF: TextOut, Fonts, Images به فارسی را برای تیمهایی توضیح میدهد که با Delphi، C++Builder، Lazarus/FPC و کامپوننتهای losLab راهکارهای تولیدی میسازند
تمرکز بر تصمیمهای عملی، ریسکها و نکتههای بازبینی است تا خروجی در محیط واقعی قابل اعتماد بماند
زمانی که این موضوع مهم میشود
این موضوع زمانی اهمیت دارد که پردازش PDF، صفحهگسترده یا سند باید در محیط واقعی قابل تکرار، قابل بررسی و قابل پشتیبانی باشد، نه فقط در یک نمونه نمایشی.
- فایلهای ورودی، مجوزها، خروجی مورد انتظار و حالتهای خطا را از ابتدا مشخص کنید
- نام محصولها، نام APIها و نام فایلها را دقیقاً مانند مستندات نگه دارید
- برای پشتیبانی آینده فایلهای آزمون و لاگهای کوتاه نگهداری کنید
گردشکار عملی
نکتههای اصلی متن انگلیسی را به یک گردشکار عملی Delphi تبدیل کنید. محورهای مهم منبع عبارتاند از:
- سناریوی کاربردی را پیش از تغییر کد مشخص کنید
- نتیجه را با فایلهای آزمون کوچک بررسی کنید
- نام APIها و مقدارهای literal را بدون تغییر نگه دارید
ابتدا یک نمونه کوچک و قابل بازتولید بسازید، سپس فراخوانیهای کامپوننت، مدیریت خطا و پیامهای کاربر را به آن وصل کنید. در قالبهای سندی، جزئیات کوچک معمولاً تفاوت بین خروجی قابل اعتماد و خطای پشتیبانینشده را ایجاد میکنند.
نشانههای API و کد
var
Pdf: THotPDF;
begin
Pdf := THotPDF.Create(nil);
try
Pdf.FileName := 'invoice-0001.pdf';
Pdf.BeginDoc;
Pdf.CurrentPage.SetFont('Arial', [fsBold], 16);
Pdf.CurrentPage.TextOut(50, 792 - 50, 0, 'INVOICE'); // 50pt from top of Letter
Pdf.CurrentPage.SetFont('Arial', [], 10);
Pdf.CurrentPage.TextOut(50, 792 - 70, 0, 'Date: 2026-06-11');
Pdf.CurrentPage.TextOut(300, 400, 45, 'COPY'); // rotated stamp
Pdf.AddPage; // CurrentPage now points here
Pdf.CurrentPage.SetFont('Arial', [], 10); // font state does not carry over
Pdf.CurrentPage.TextOut(50, 742, 0, 'Page 2 detail rows');
Pdf.EndDoc;
finally
Pdf.Free;
end;
end;Pdf.RegisterUnicodeTTF('C:\ProgramData\MyApp\Fonts\NotoSans.ttf');
Pdf.CurrentPage.SetFont('NotoSans', [], 12);
Pdf.CurrentPage.TextOut(50, 700, 0, WideString('Łódź — Ünïcode test ✓'));بازبینی پیش از انتشار
پیش از انتشار، فایل خروجی، فراداده، رمزگذاری، رندرینگ یا وضعیت واردشده را بر اساس موضوع مقاله بررسی کنید. نسخه ابزار، نسخه کامپوننت، فایل آزمون و نتیجه مشاهدهشده را ثبت کنید.
نام محصولات، نام APIها و قطعهکدها بدون تغییر حفظ شدهاند تا توسعهدهندگان بتوانند متن را با مستندات و کد منبع تطبیق دهند
مطالعه مرتبط
- our article on complex script text shaping with HotPDF
- the HotPDF PDF/A, PDF/X, and PDF/UA guide
- HotPDF Component
نمونههای کد تکمیلی
var
Png: TPngImage;
Logo: TBitmap;
LogoIdx: Integer;
begin
Png := TPngImage.Create;
Logo := TBitmap.Create;
try
Png.LoadFromFile('brand-logo.png');
Logo.Assign(Png); // decode PNG to a bitmap
LogoIdx := Pdf.AddImage(Logo, icFlate); // lossless for flat-color art
finally
Logo.Free;
Png.Free;
end;
// (Index, X, Y, Width, Height, Angle) — not (X1, Y1, X2, Y2)
Pdf.CurrentPage.ShowImage(LogoIdx, 50, 700, 120, 40, 0);
end;// Horizontal rule under the table header
Pdf.CurrentPage.SetLineWidth(0.75);
Pdf.CurrentPage.MoveTo(50, 660);
Pdf.CurrentPage.LineTo(545, 660);
Pdf.CurrentPage.Stroke;
// Shaded totals box: X, Y, width, height
Pdf.CurrentPage.SetRGBFillColor(RGB(235, 235, 235));
Pdf.CurrentPage.Rectangle(395, 120, 150, 40);
Pdf.CurrentPage.Fill;یادداشتهای تکمیلی
این بخش تکمیلی نسخه کوتاه را به یک راهنمای عملیتر تبدیل میکند و همچنان با عنوان Delphi PDF Reports with HotPDF: TextOut, Fonts, and Images و توضیح پایهٔ انگلیسی آن هماهنگ میماند. متن اصلی باید مشخص کند که مسئله از چه ورودیای شروع میشود، چه خروجیای انتظار میرود و چه وضعیتی باید بهصورت دقیق در 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 را با فایل نمونه و خروجی قابل مقایسه توضیح بده
- مسیر تصمیمگیری را بهجای خلاصهٔ خیلی کوتاه روشن کن