مقاله فنی

Tagged PDF Structure Trees in Delphi with PDFlibPas به فارسی

این مقاله فارسی موضوع Tagged PDF Structure Trees in Delphi with PDFlibPas به فارسی را برای تیم‌هایی توضیح می‌دهد که با Delphi، C++Builder، Lazarus/FPC و کامپوننت‌های losLab راهکارهای تولیدی می‌سازند

تمرکز بر تصمیم‌های عملی، ریسک‌ها و نکته‌های بازبینی است تا خروجی در محیط واقعی قابل اعتماد بماند

زمانی که این موضوع مهم می‌شود

این موضوع زمانی اهمیت دارد که پردازش PDF، صفحه‌گسترده یا سند باید در محیط واقعی قابل تکرار، قابل بررسی و قابل پشتیبانی باشد، نه فقط در یک نمونه نمایشی.

  • فایل‌های ورودی، مجوزها، خروجی مورد انتظار و حالت‌های خطا را از ابتدا مشخص کنید
  • نام محصول‌ها، نام APIها و نام فایل‌ها را دقیقاً مانند مستندات نگه دارید
  • برای پشتیبانی آینده فایل‌های آزمون و لاگ‌های کوتاه نگهداری کنید

گردش‌کار عملی

نکته‌های اصلی متن انگلیسی را به یک گردش‌کار عملی Delphi تبدیل کنید. محورهای مهم منبع عبارت‌اند از:

  • سناریوی کاربردی را پیش از تغییر کد مشخص کنید
  • نتیجه را با فایل‌های آزمون کوچک بررسی کنید
  • نام APIها و مقدارهای literal را بدون تغییر نگه دارید

ابتدا یک نمونه کوچک و قابل بازتولید بسازید، سپس فراخوانی‌های کامپوننت، مدیریت خطا و پیام‌های کاربر را به آن وصل کنید. در قالب‌های سندی، جزئیات کوچک معمولاً تفاوت بین خروجی قابل اعتماد و خطای پشتیبانی‌نشده را ایجاد می‌کنند.

نشانه‌های API و کد

var
  Lib: TPDFlib;
begin
  Lib := TPDFlib.Create;
  try
    Lib.SetOrigin(1);                          // top-left origin
    Lib.SetPDFUAMode('en-US');                 // bumps the save version to PDF 1.7
    Lib.SetInformation(1, 'Service Manual');   // /Title is mandatory for PDF/UA
    Lib.AddRoleMap('ManualTitle', 'H1');       // custom type -> standard role
    Lib.AddStandardFont(4);
    Lib.SetTextSize(18);
    Lib.BeginTagEx2('ManualTitle', '', '', 'en-US', '', 'h1-cover', '');
    Lib.DrawText(72, 96, 'Service Manual');
    Lib.EndTag;
    Lib.BeginTag('Figure', 'Exploded view of the gearbox assembly', '');
    Lib.AddImageFromFile('gearbox.png', 0);
    Lib.EndTag;
    Lib.BeginArtifact('Layout');               // page decoration: excluded from reading
    // ... draw rules and background tint ...
    Lib.EndArtifact;
    Lib.SaveToFile('manual.pdf');
  finally
    Lib.Free;
  end;
end;
Lib.BeginTag('Table', '', '');
Lib.BeginTag('TR', '', '');
Lib.BeginTagEx2('TH', '', '', '', '', 'col-part', '');
Lib.SetStructElemScope('Column');          // valid only while this TH is open
Lib.DrawText(72, 120, 'Part');
Lib.EndTag;
Lib.BeginTagEx2('TH', '', '', '', '', 'col-torque', '');
Lib.SetStructElemScope('Column');
Lib.SetStructElemColSpan(2);               // header spans the value and unit columns
Lib.DrawText(200, 120, 'Tightening torque');
Lib.EndTag;
Lib.EndTag;
Lib.BeginTag('TR', '', '');
Lib.BeginTag('TD', '', '');
Lib.SetStructElemHeaders('col-part');      // explicit binding for irregular tables
Lib.DrawText(72, 140, 'M8 flange bolt');
Lib.EndTag;
Lib.EndTag;
Lib.EndTag; // Table

بازبینی پیش از انتشار

پیش از انتشار، فایل خروجی، فراداده، رمزگذاری، رندرینگ یا وضعیت واردشده را بر اساس موضوع مقاله بررسی کنید. نسخه ابزار، نسخه کامپوننت، فایل آزمون و نتیجه مشاهده‌شده را ثبت کنید.

نام محصولات، نام APIها و قطعه‌کدها بدون تغییر حفظ شده‌اند تا توسعه‌دهندگان بتوانند متن را با مستندات و کد منبع تطبیق دهند

مطالعه مرتبط

یادداشت‌های تکمیلی

این بخش تکمیلی نسخه کوتاه را به یک راهنمای عملی‌تر تبدیل می‌کند و همچنان با عنوان Building Tagged PDF Structure Trees in Delphi with PDFlibPas و توضیح پایهٔ انگلیسی آن هماهنگ می‌ماند. متن اصلی باید مشخص کند که مسئله از چه ورودی‌ای شروع می‌شود، چه خروجی‌ای انتظار می‌رود و چه وضعیتی باید به‌صورت دقیق در 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 را با فایل نمونه و خروجی قابل مقایسه توضیح بده
  • مسیر تصمیم‌گیری را به‌جای خلاصهٔ خیلی کوتاه روشن کن