การตรวจสอบความถูกต้องของ PDF/X ใน Delphi ด้วยคอมโพเนนต์

คอมโพเนนต์ PDFium สำหรับ Delphi สามารถใช้ตรวจสอบความถูกต้องของเอกสาร PDF/X ที่พร้อมสำหรับพิมพ์ผ่านฟังก์ชัน TPdf.ValidatePdfX ซึ่งใช้ระบบตรวจสอบมาตรฐาน ISO 15930 แบบสองชั้น: ได้แก่ การตรวจสอบเนื้อหาในระดับไบต์แปดรายการ (การห้ามบีบอัดข้อมูลแบบ LZW, โค้ด JavaScript, ฟิลด์แบบฟอร์ม, การอ้างอิง OPI, การขาด TrimBox, ข้อมูลคีย์ Trapped ที่ไม่ได้ระบุ และอื่นๆ) ร่วมกับการตรวจสอบแบบจำลองออบเจกต์ของ PDFium ที่ใช้คำสั่ง FPDFFont_GetIsEmbedded เพื่อตรวจสอบการฝังตัวฟอนต์ในทุกออบเจกต์ข้อความของทุกหน้ากระดาษ ผลลัพธ์ที่ได้คือเรกคอร์ด TPdfXValidationResult ที่ระบุระดับความเข้ากันได้ที่ตรวจพบและแสดงข้อบกพร่องแต่ละรายการเป็นโครงสร้าง enum เพื่อให้แอปพลิเคชัน Delphi ของคุณสามารถแจ้งลูกค้าได้ทันทีว่าทำไมไฟล์จึงถูกปฏิเสธที่โรงพิมพ์ ก่อนที่จะเข้าสู่กระบวนการพิมพ์จริง

หากคุณเคยส่งงานพิมพ์ไปยังโรงพิมพ์การค้าแล้วถูกส่งกลับคืนมาพร้อมข้อความปฏิเสธสั้นๆ เช่น "ไม่มี TrimBox", "ฟอนต์ไม่ได้ฝังมา" หรือ "ไม่ได้ตั้งค่า Trapped" คุณคงทราบถึงต้นทุนของความสูญเสียเมื่อตรวจพบความผิดพลาดล่าช้า มาตรฐาน PDF/X คือข้อกำหนดฝั่งการเตรียมพิมพ์ (prepress) ที่คู่ขนานกับมาตรฐาน PDF/A: ในขณะที่ PDF/A เน้นรับประกันการแสดงผลเอกสารที่เหมือนเดิมทุกประการในอีกหลายทศวรรษข้างหน้า มาตรฐาน PDF/X จะรับประกันว่าเอกสารสามารถแยกสี แสดงผลภาพ และตัดขอบได้เหมือนกันบนระบบประมวลผล (RIP) ของผู้อื่นในวันพรุ่งนี้ ทั้งสองมาตรฐานใช้ส่วนประกอบพื้นฐานร่วมกัน (เช่น XMP identification, OutputIntents, โปรไฟล์ ICC ที่ฝังตัวมา) แต่ใช้ตอบคำถามที่ต่างกัน ซึ่งเป็นเหตุผลว่าทำไมคอมโพเนนต์จึงแยกตัวตรวจสอบสำหรับทั้งสองฝั่งออกจากกัน — รายละเอียดด้าน PDF/A อธิบายไว้ในบทความเรื่องการตรวจสอบเอกสาร PDF/A ล่วงหน้าด้วยคอมโพเนนต์ PDFium

มาตรฐาน ISO 15930 กำหนดข้อบังคับใดบ้างสำหรับไฟล์ PDF ที่พร้อมพิมพ์?

มาตรฐาน ISO 15930 จัดตั้งขึ้นเพื่อให้กระบวนการ แลกเปลี่ยนข้อมูลแบบอิสระ (blind exchange) สามารถเกิดขึ้นได้จริง: กล่าวคือผู้ออกแบบส่งไฟล์ให้กับโรงพิมพ์ที่พวกเขาไม่เคยพูดคุยด้วยเลย และโรงพิมพ์ก็ยังสามารถผลิตผลงานที่ถูกต้องออกมาได้โดยไม่ต้องโทรศัพท์สอบถาม ไม่ต้องส่งอีเมลทวงฟอนต์ที่ขาดหาย และไม่มีปัญหารูปภาพที่เชื่อมโยงตกหล่นอยู่บนคอมพิวเตอร์ของผู้ออกแบบ ทุกกฎเกณฑ์ในมาตรฐานนี้ทำหน้าที่รองรับเป้าหมายดังกล่าว ฟอนต์ต้องถูกฝังมาในตัวเนื่องจากระบบ RIP ปลายทางอาจไม่มีฟอนต์เหล่านั้นติดตั้งอยู่ การอ้างอิงไฟล์ภายนอกจะถูกห้ามเนื่องจากไฟล์ต้องมีความครบถ้วนสมบูรณ์ในตัวเอง ฟังก์ชันตอบโต้ (interactive) จะถูกห้ามเนื่องจากหมึกพิมพ์ไม่มีตัวประมวลผลเหตุการณ์คลิกเลือก

คอมโพเนนต์ PDFium จะแยกแยะกลุ่มความเข้ากันได้สามกลุ่มและรายงานผลลัพธ์ผ่านตัวแปร enum TPdfXConformance: ได้แก่ pxc1a สำหรับ PDF/X-1a:2001 (มาตรฐาน ISO 15930-1 ซึ่งจำกัดสเปกเฉพาะ CMYK และสีพิเศษ (spot color) บนฐานข้อมูล PDF 1.3/1.4), pxc3 สำหรับ PDF/X-3:2002 (มาตรฐาน ISO 15930-3 ซึ่งรองรับ RGB, Lab และระบบการจัดการสีแบบ ICC) และ pxc4 สำหรับ PDF/X-4:2010 (มาตรฐาน ISO 15930-7 ซึ่งรองรับการตั้งค่าความโปร่งแสงและเลเยอร์บนฐานข้อมูล PDF 1.6) เอกสารที่ไม่มีตัวระบุมาตรฐาน PDF/X เลยจะส่งกลับมาเป็นค่า pxcNone ซึ่งเป็นข้อมูลที่มีประโยชน์เช่นกัน: เพื่อระบุว่าเอกสารไม่เคยประกาศตัวว่าพร้อมสำหรับการพิมพ์ และหัวข้อข้อบกพร่องอื่นๆ ที่รายงานจะช่วยอธิบายว่าต้องดำเนินการอย่างไรเพิ่มเติมเพื่อให้ได้ตามเกณฑ์

ข้อห้ามต่างๆ จะมีความเข้าใจได้ง่ายขึ้นเมื่อพิจารณาในมุมมองของโรงพิมพ์ ตัวกรอง /LZWDecode จะถูกห้ามในทุกรูปแบบของ PDF/X เพื่อให้ตัวรับข้อมูลปลายทางไม่ต้องพึ่งพาระบบตัวกรองที่มีประวัติปัญหาความเข้ากันได้และลิขสิทธิ์ ตัวกรอง Flate สามารถทำหน้าที่ได้เท่าเทียมกันโดยไม่มีปัญหาเหล่านั้นตามมา ส่วนโค้ด JavaScript, ฟิลด์แบบฟอร์ม AcroForm และพจนานุกรมการทำงานเพิ่มเติม /AA จะถูกห้ามทั้งหมด เนื่องจากไฟล์พิมพ์ควรเป็นเพียงคำอธิบายตำแหน่งเครื่องหมายบนกระดาษอย่างคงที่ — สิ่งใดก็ตามที่สามารถปรับเปลี่ยนการแสดงผลขณะเปิดไฟล์จะทำให้การรับประกันว่า "สิ่งที่เห็นคือสิ่งที่จะพิมพ์" เสียไป และ OPI (Open Prepress Interface) จะถูกห้ามเพราะตามโครงสร้างของมันจะเป็นการอ้างอิงถึงรูปภาพความละเอียดสูงที่จัดเก็บอยู่จุดอื่น และคำว่า "จุดอื่น" คือสิ่งที่ระบบแลกเปลี่ยนข้อมูลแบบอิสระห้ามโดยเด็ดขาด

ทำไมโรงพิมพ์จึงปฏิเสธไฟล์ PDF ที่ไม่มี TrimBox?

พื้นที่ TrimBox คือขนาดของหน้ากระดาษที่เสร็จสมบูรณ์ — ซึ่งก็คือขอบพื้นที่สี่เหลี่ยมที่จะเหลืออยู่หลังจากขั้นตอนการตัดเจียนกระดาษจริง ส่วน MediaBox ที่หน้า PDF ทุกหน้ามีอยู่แล้ว เป็นเพียงขนาดของแผ่นพิมพ์ดิบ: ซึ่งรวมถึงระยะเผื่อตัดตก (bleed), เครื่องหมายตัดเจียน (crop mark), เป้าหมายการทับซ้อนสี และแถบสี ซอฟต์แวร์จัดหน้าจะวางตำแหน่งหน้าบนแผ่นพิมพ์อ้างอิงจากระยะ TrimBox เป็นหลัก หากไม่มีส่วนนี้ เจ้าหน้าที่ควบคุมเครื่องพิมพ์จะต้องเดาว่าขอบเขตของนามบัตรของคุณสิ้นสุดตรงจุดใด และการเดาที่ผิดพลาดอาจส่งผลให้พื้นที่ตัดตกของคุณหลุดหายไปหรือทิ้งขอบสีขาวไว้ที่มุมกระดาษ นั่นคือเหตุผลที่ ISO 32000-1 กำหนดให้ต้องมี TrimBox (or ArtBox) บนหน้ากระดาษทุกหน้า และเป็นเหตุผลว่าทำไม ValidatePdfX จะแจ้งสถานะ pvxiMissingTrimBox เมื่อไม่พบข้อมูลคีย์ /TrimBox ในหน้ากระดาษใดกระดาษหนึ่งของเอกสาร

แผนภาพ PDFium Component ของหน้า PDF ที่พร้อมพิมพ์ แสดงแผ่น MediaBox พร้อม bleed, รอยตัด (crop marks), แถบสี และเครื่องหมายวางแนว รอบสี่เหลี่ยม TrimBox ที่ ISO 15930 กำหนด โดยยก pvxiMissingTrimBox เมื่อคีย์ไม่อยู่ — MediaBox คือแผ่นเต็มที่มี bleed, เครื่องหมายตัด และแถบสี ในขณะที่ TrimBox คือหน้าสำเร็จรูปที่ใบมีดกุโจต้องหาเจอ ISO 15930 กำหนดให้มีทุกหน้า

ตัวแปรคีย์ /Trapped ใช้สำหรับตอบคำถามกระบวนการผลิตจุดอื่น กระบวนการ Trapping คือเทคนิคการพิมพ์ซ้อนทับกันเล็กน้อยระหว่างสีที่อยู่ข้างเคียงกันเพื่อป้องกันไม่ให้ระยะเครื่องพิมพ์เคลื่อนเกิดขอบขาวขึ้นตรงกลาง โรงพิมพ์จำเป็นต้องทราบว่าขั้นตอนดังกล่าวได้รับการจัดการมาเรียบร้อยแล้วหรือไม่: การประมวลผล trapping กับไฟล์ที่จัดการมาแล้วจะทำให้เกิดสีทับซ้อนมากเกินไป และการข้ามไปสำหรับไฟล์ที่ยังไม่จัดการจะเสี่ยงต่อการเกิดขอบขาว มาตรฐาน PDF/X จึงกำหนดให้พจนานุกรม Info ระบุสถานะ /Trapped /True หรือ /Trapped /False อย่างชัดเจน — การขาดข้อมูลคีย์ตัวนี้หรือการตั้งค่าเป็น /Unknown จะบังคับให้ต้องมีเจ้าหน้าที่เข้ามาตรวจสอบไฟล์ด้วยตัวเอง ซึ่งนี่คือหัวข้อการสนทนาที่ระบบแลกเปลี่ยนข้อมูลแบบอิสระพยายามหลีกเลี่ยง คอมโพเนนต์จะแจ้งเตือนกรณีนี้เป็น pvxiTrappedNotSet

การรันระบบตรวจสอบสองชั้นด้วย TPdf.ValidatePdfX

เมธอด TPdf.ValidatePdfX จะทำงานโดยไม่มีอาร์กิวเมนต์เพิ่ม และส่งกลับเรกคอร์ด TPdfXValidationResult ที่เก็บข้อมูลสมาชิกสามส่วน ได้แก่: Conformance (รุ่นย่อยของ PDF/Xที่ตรวจพบ), Issues (กลุ่มของ TPdfXValidationIssue) และฟังก์ชัน IsCompliant รหัสภายในจะแปลงเอกสารที่โหลดเป็นสตรีมในหน่วยความจำ รันสแกนตรวจสอบในระดับไบต์ และเดินตรวจสอบต่อด้วยแบบจำลองออบเจกต์ PDFium สำหรับฟอนต์แต่ละตัว ตัวอย่างการเขียนโค้ดตรวจสอบขั้นพื้นฐาน:

uses PDFium, FPdfPdfx;

procedure CheckPrintReadiness(const FileName: string);
var
  Pdf: TPdf;
  Res: TPdfXValidationResult;
begin
  Pdf := TPdf.Create(nil);
  try
    Pdf.FileName := FileName;
    Pdf.Active := True;

    Res := Pdf.ValidatePdfX;
    Writeln('Detected conformance: ',
      Ord(Res.Conformance)); // pxc1a, pxc3, pxc4, pxcNone...

    if Res.IsCompliant then
      Writeln('PDF/X checks passed')
    else
    begin
      if pvxiMissingTrimBox in Res.Issues then
        Writeln('REJECT: ไม่มี /TrimBox บนหน้ากระดาษ');
      if pvxiTrappedNotSet in Res.Issues then
        Writeln('REJECT: /Trapped ขาดหายไป หรือระบุเป็น /Unknown');
      if pvxiPdfiumFontNotEmbedded in Res.Issues then
        Writeln('REJECT: มีหน้ากระดาษใช้ฟอนต์ที่ไม่ได้ฝังมา');
      if pvxiLzwForbidden in Res.Issues then
        Writeln('REJECT: ตรวจพบตัวกรอง LZWDecode');
    end;
  finally
    Pdf.Free;
  end;
end;

เนื่องจากตัวแปร Issues เป็นโครงสร้าง set ทั่วไปของ Pascal คุณจึงสามารถแบ่งแยกการตรวจสอบได้ตามที่เวิร์กโฟลว์ของคุณต้องการ — เช่น กำหนดปัญหาโครงสร้างหลักเป็นหัวข้อปฏิเสธทันที และกำหนด pvxiMissingTitle (ซึ่งตามมาตรฐานระบุว่าควรมี แต่ไม่ได้บังคับ) เป็นเพียงข้อความแจ้งเตือน และบันทึกประวัติส่วนที่เหลือ โครงสร้างเรกคอร์ดเดียวกันนี้ยังป้อนให้กับระบบสร้างรายงานของคอมโพเนนต์ด้วย ดังนั้นหากคุณต้องการสร้างเอกสารรายงานที่คนอ่านง่ายแทนการตรวจสอบ enum ผ่านโปรแกรม แนวทางการเขียนรหัสในการสร้างรายงานการตรวจสอบล่วงหน้าแบบแบทช์ผ่าน CLI ด้วยคอมโพเนนต์ PDFium สามารถนำมาใช้กับ PDF/X ได้ตามปกติไม่มีการเปลี่ยนแปลง

สิ่งที่ชั้นระดับไบต์ตรวจพบ — และสิ่งที่ระบบมองข้าม

ระบบการตรวจสอบในระดับไบต์จะเป็นการสแกนโทเค็นข้อมูลโครงสร้างเอกสารโดยละเว้นข้อมูลสตรีมภายใน เพื่อไม่ให้ไฟล์ภาพถ่ายหรือข้อมูลอื่นที่บังเอิญตรงกับคำหลักเช่น /JavaScript สร้างข้อผิดพลาดแจ้งเตือนล่วง (false positive) นอกจากการตรวจสอบตัวระบุมาตรฐาน (เช่น XMP pdfxid:GTS_PDFXVersion, OutputIntent ร่วมกับโปรไฟล์ ICC, trailer /ID และการห้ามการเข้ารหัสไฟล์) ชั้นระดับไบต์จะเช็กเนื้อหาเพิ่มอีกแปดหัวข้อ ดังนี้:

pvxiLzwForbidden — พบตัวกรอง /LZWDecode ในตำแหน่งใดก็ตามของไฟล์ (ห้ามใช้ในทุกรูปแบบของ PDF/X)
pvxiJavaScriptForbidden — ตรวจพบกระบวนการรัน /JavaScript หรือโครงสร้างชื่อของรหัสโปรแกรม
pvxiFormFieldsForbidden — พบพจนานุกรม /AcroForm หรือรายการ /XFA
pvxiAdditionalActions — พบพจนานุกรมการทำงานเพิ่มเติม /AA
pvxiEmbeddedFilesForbidden — พบฟังก์ชัน /EmbeddedFiles หรือคำอธิบายประกอบ /FileAttachment
pvxiOpiForbidden — พบรายการ /OPI หรือ /Alternates ที่อ้างอิงถึงรูปภาพที่ต้องทับแทนที่
pvxiMissingTrimBox — ไม่พบ /TrimBox ในหน้ากระดาษใดๆ
pvxiTrappedNotSet — ไม่มีข้อมูล /Trapped หรือตั้งค่าเป็น /Unknown

การสแกนระดับไบต์ทำงานรวดเร็วมากและไม่ต้องพึ่งพาเอนจินวาดผลภาพ แต่ก็มีจุดบอดเรื่องฟอนต์โดยธรรมชาติ: เนื่องจากในระดับไบต์นั้น ตัวตรวจสอบสามารถดึงพฤติกรรมกว้างๆ ได้เท่านั้น — มันจะแจ้งสถานะไม่ผ่านเมื่อไม่พบข้อมูลฟอนต์ฝังตัวอยู่เลย ไฟล์ที่ฝังฟอนต์มาเก้าฟอนต์และมีฟอนต์ระบบสอดแทรกเข้ามาหนึ่งฟอนต์จะดูเป็นปกติในการตรวจสอบระดับไบต์ ช่องโหว่นี้เองคือเหตุผลที่ต้องมีชั้นการทำงานที่สองเข้ามาเสริม

การตรวจสอบการฝังตัวฟอนต์แต่ละตัวผ่านแบบจำลองออบเจกต์ PDFium

ชั้นข้อมูลแบบจำลองออบเจกต์ของคอมโพเนนต์ PDFium จะตอบคำถามเรื่องฟอนต์ได้อย่างแม่นยำ หลังจากผ่านขั้นตอนระดับไบต์แล้ว ฟังก์ชัน TPdf.ValidatePdfX จะเข้าไปแกะตรวจหน้ากระดาษทุกหน้า เรียกใช้คำสั่ง FPDFPage_CountObjects เพื่อขอรายการออบเจกต์ทั้งหมด และสำหรับออบเจกต์ข้อความแต่ละชิ้น จะวิเคราะห์หาแฮนเดิลฟอนต์ผ่านคำสั่ง FPDFTextObj_GetFont และตรวจสอบค่าด้วย FPDFFont_GetIsEmbedded การพบฟอนต์ที่ไม่ได้ฝังตัวแม้เพียงฟอนต์เดียวในเอกสารจะทำให้มีการเพิ่ม pvxiPdfiumFontNotEmbedded ลงในกลุ่มข้อบกพร่อง การตรวจสอบมีระบบลัดวงจรการทำงานสองชั้น — คือมันจะหยุดสแกนออบเจกต์บนหน้านั้น และหยุดโหลดหน้าถัดไปทันทีที่ยืนยันจุดบกพร่องได้แล้ว — ดังนั้นสำหรับเอกสารแค็ตตาล็อกความยาว 300 หน้าที่ทำผิดกฎ คำตัดสินว่าไม่ผ่านการตรวจสอบมักจะมาถึงตั้งแต่การสแกนหน้าแรกเสร็จสิ้น

ขอบเขตการทำงานสองประการที่ควรทราบ ประการแรกคือ ชั้นข้อมูลนี้ต้องการการโหลดไลบรารี PDFium และบิลด์ระบบที่ส่งออกคำสั่ง FPDFFont_GetIsEmbedded เผยแพร่ด้วย เมื่อไม่มีคำสั่งนี้ ขั้นตอนการเช็กจะถูกข้ามไปโดยไม่แจ้งผลล้มเหลว เพื่อไม่ให้การใช้ DLL รุ่นเก่ากว่าสร้างข้อผิดพลาดลวง ประการที่สองคือ ขั้นตอนการตรวจสอบจะรายงานเพียงสถานะ "ฝังตัวหรือไม่ฝังตัว" เท่านั้น — โดยไม่มีการแยกแยะระหว่างการฝังตัวเต็มรูปแบบกับการฝังเฉพาะบางส่วน (subsetting) หรือตรวจสอบรายละเอียดของช่วงตัวอักษร เมื่อไฟล์ล้มเหลวและคุณต้องการทราบรายละเอียดเพิ่มเติมว่าเกิดบน ฟอนต์ใด ใน หน้ากระดาษใด เทคนิคการแจกแจงที่แสดงในบทความเรื่องการวิเคราะห์คุณสมบัติฟอนต์ PDF ด้วย PDFium ใน Delphi จะเข้ามารับช่วงต่อจากค่าบูลีนที่ระบบตรวจสอบส่งกลับมา

การตรวจสอบสตรีมข้อมูลโดยไม่โหลดเอกสาร — หรือไฟล์ DLL

ฟังก์ชันตรวจสอบในระดับไบต์ยังมีให้บริการเป็นฟังก์ชันอิสระคือ ValidatePdfXCompliance(Source: TStream) ภายใต้หน่วย FPdfPdfx ซึ่งเขียนขึ้นด้วยภาษา Object Pascal ล้วนโดยไม่มีการพึ่งพาไฟล์ DLL ของ PDFium เลย ส่งผลให้สามารถนำไปติดตั้งในส่วนงานที่คุณไม่ต้องการเปิดโปรแกรมวาดภาพได้: เช่น บนระบบรับอัปโหลดข้อมูลขนาดเบาบนเว็บเซิร์ฟเวอร์, กระบวนการตรวจสอบสิทธิในระบบ CI หรือบริการประมวลผลหลังบ้านของ Lazarus บนแพลตฟอร์มที่คุณไม่ต้องการส่งออกไฟล์ไบนารีระบบเนทีฟไปด้วย เพียงแค่ป้อนสตรีมข้อมูลเข้ามา:

แผนภาพ TPdf.ValidatePdfX ใน PDFium Component สำหรับ Delphi ที่รันการสแกน token ระดับไบต์พร้อมการตรวจเนื้อหาแปดข้อ และรอบตรวจการฝังฟอนต์ตาม object model ของ PDFium รวมเข้า record TPdfXValidationResult หนึ่งตัว — ValidatePdfX กระจายเอกสารที่โหลดแล้วหนึ่งชุดผ่านการตรวจเนื้อหาระดับไบต์และรอบฟอนต์ของโมเดลออบเจกต์ PDFium แล้วจึงรวมสองชั้นเป็น record ผลลัพธ์ที่มีชนิดชุดเดียว

uses Classes, FPdfPdfx;

// ตรวจสอบความถูกต้องอย่างรวดเร็ว
function QuickPdfXGate(const FileName: string): Boolean;
var
  Fs: TFileStream;
  Res: TPdfXValidationResult;
begin
  Fs := TFileStream.Create(FileName, fmOpenRead or fmShareDenyWrite);
  try
    Res := ValidatePdfXCompliance(Fs);
    Result := Res.IsCompliant and (Res.Conformance <> pxcNone);
  finally
    Fs.Free;
  end;
end;

ข้อจำกัดที่ชัดเจนคือ: เส้นทางทำงานอิสระจะรันตัวระบุระบบและเกณฑ์ควบคุมทั้งแปดข้อได้ทั้งหมด แต่จะไม่มีการเช็กฟอนต์ในระดับชั้นของ PDFium ดังนั้นผลลัพธ์ของฟอนต์จะกลับไปอิงกับกลไกประเมินกว้างๆ สถาปัตยกรรมที่เหมาะสมจึงมักเลือกใช้ ValidatePdfXCompliance เป็นขั้นตอนดักกรองด่านแรก และเรียกใช้ TPdf.ValidatePdfX แบบเต็มรูปแบบกับไฟล์ที่ผ่านขั้นตอนแรกมาแล้วเท่านั้น

จุดสิ้นสุดขอบเขตของตัวตรวจสอบนี้และการตรวจสอบล่วงหน้าเต็มรูปแบบ

ความตรงไปตรงมามีความสำคัญสำหรับเครื่องมือตรวจสอบ ขอบเขตการทำงานจึงควรชี้แจงดังนี้: ฟังก์ชัน ValidatePdfX จะตรวจสอบข้อมูลตัวระบุมาตรฐาน, ข้อห้ามเชิงโครงสร้าง, ข้อมูลคีย์พิกัดหน้ากระดาษ, การตั้งค่า Trapped และการฝังตัวฟอนต์ลงไปถึงออบเจกต์ข้อความแต่ละชิ้น แต่มันไม่ได้วัดปริมาณความหนาแน่นของหมึกพิมพ์ทั้งหมด (total ink coverage), ตรวจสอบว่าโหมดสีเป็นไปตามข้อกำหนดของรุ่นหรือไม่ (เช่น กฎเฉพาะ CMYK ของ X-1a), ตรวจสอบความละเอียดภาพเทียบกับสกรีนการพิมพ์ หรือประเมินพฤติกรรมการพิมพ์ทับ (overprint) และการรวมความโปร่งแสง — สิ่งเหล่านั้นต้องการเอนจินการเตรียมพิมพ์แบบควบคุมสีเชิงลึก และเอกสารประกอบการใช้งานของเราได้แนะนำให้จับคู่ตรวจสอบคู่ขนานกับเอนจินอื่นสำหรับขั้นตอนการรับรองขั้นสุดท้าย สิ่งที่การตรวจสอบสองชั้นนี้มอบให้คุณคือการตรวจพบจุดบกพร่องเชิงโครงสร้างกว่า 80% ได้ล่วงหน้าอย่างรวดเร็วในระดับมิลลิวินาทีภายในรหัส Delphi ของคุณเอง แทนการได้รับอีเมลปฏิเสธจากโรงพิมพ์ในวันถัดไป

ทั้งชั้นข้อมูลระบบตรวจสอบทั้งสองชั้น, API การเขียนข้อมูลระบุมาตรฐาน PDF/X สำหรับการส่งออกไฟล์ที่ถูกต้องตามกฎ และระบบตรวจสอบสำหรับ PDF/A, PDF/UA, PDF/E และ PDF/VT ที่ใช้โครงสร้างแบบเดียวกัน ทั้งหมดจัดส่งมาในชุดของคอมโพเนนต์ PDFium Component สำหรับ Delphi และ C++Builder — รวมฟังก์ชันการทำงานตั้งแต่การเปิดแสดงผลไปจนถึงการตรวจสอบขั้นตอนเตรียมพิมพ์ในคอมโพเนนต์เดียว

การตรวจสอบความถูกต้องของ PDF/X ใน Delphi ด้วยคอมโพเนนต์ PDFium