HotPDF는 로드된 PDF 페이지를 단일 진입점 RenderLoadedPageToDevice로 렌더링하며, 넘겨주는 디바이스가 결과가 비트맵인지, 프린터 캔버스 같은 외부 디바이스 컨텍스트의 그림인지, 벡터 확장 메타파일인지를 결정합니다. RenderOverprintPreview를 True로 설정하면 같은 호출이 CMYK 프로세스 잉크 오버프린트를 시뮬레이션하여, 운영자가 화면에서 그렇지 않으면 인쇄물에서만 나타날 잉크 상호작용을 봅니다
이 두 기능은 같은 코드 경로에서 만나는 서로 다른 문제를 해결합니다. 디바이스 추상화는 미리보기, 인쇄, 내보내기가 각각 자신만의 렌더링 호출과 자신만의 드리프트를 가지던 분기를 제거합니다. 오버프린트 교정은 모든 뷰어에서 올바르게 보이다가 인쇄기에서는 틀리게 나오는 부류의 생산 오류를 제거합니다
페이지가 미리보기와 다르게 인쇄되는 이유는 무엇인가
오버프린트가 페인트 연산이 아니라 이미징 디바이스에 대한 지시이기 때문입니다. 페이지가 그래픽 상태에서 /OP 또는 /op를 참으로 설정하면, RIP에게 아래의 잉크를 녹아웃하지 말라고 말하는 것입니다. 노란색 위에 그려진 시안 객체는 노란색을 제자리에 남기며, 시트는 초록으로 보입니다. 오버프린트를 무시하는 뷰어는 정상적으로 녹아웃하고 시안을 보여줍니다. 어느 쪽도 자체 기준에서는 틀리지 않으며, 바로 그것이 문제입니다. 화면과 인쇄기가 다르고, 교정이 돌아오기 전까지 아무도 알지 못합니다
RenderOverprintPreview는 HotPDF가 /OP, /op, /OPM 1로 통제되는 DeviceCMYK 페인트에 대해 그 지시를 진지하게 받아들이게 만듭니다. 결과는 뷰어 미리보기가 아니라 교정 미리보기입니다. 틴트 위에 오버프린트된 블랙은 구멍을 뚫는 대신 풍부한 오버레이로 남으며, 디자이너가 흰 텍스트에 실수로 오버프린트를 설정한 것은 곧 사라질 텍스트로서 가시화됩니다
var
Pdf: THotPDF;
Device: THPDFBitmapRenderDevice;
Proof: TBitmap;
begin
Pdf := THotPDF.Create(nil);
try
Pdf.LoadFromFile('cover-cmyk.pdf');
Pdf.RenderOverprintPreview := True; // proof, not plain preview
Device := THPDFBitmapRenderDevice.Create;
try
if Pdf.RenderLoadedPageToDevice(0, 150, Device) then
begin
Proof := Device.TakeBitmap; // ownership moves to the caller
try
Image1.Picture.Assign(Proof);
finally
Proof.Free;
end;
end;
finally
Device.Free;
end;
finally
Pdf.Free;
end;
end;
이 설정은 메모리와 디스크 양쪽에서 렌더 캐시 식별에 참여하므로, 일반 미리보기와 교정 미리보기가 결코 비트맵을 공유하지 않습니다. 프로퍼티를 토글하는 것이 손으로 무효화할 것을 요구하지 않습니다. 둘 중 잘못된 것을 반환하는 캐시는 아예 캐시가 없는 것보다 못하기 때문입니다
세 개의 디바이스, 하나의 렌더링 호출
THPDFRenderDevice는 중요한 두 멤버를 가진 추상 클래스입니다. 대상을 rdkBitmap, rdkDeviceContext, rdkEnhancedMetafile로 보고하는 Kind와 라이브러리가 호출하는 Execute입니다. 세 개의 구체적 디바이스가 HotPDF와 함께 배포되며, 각각은 출력을 서로 다르게 소유합니다
THPDFBitmapRenderDevice는 TakeBitmap이 소유권을 여러분에게 옮기기 전까지 TBitmap을 소유합니다. THPDFDeviceContextRenderDevice는 기존 HDC와 너비, 높이를 받아 그 안에 직접 그리며, 이것이 비트맵 왕복 없이 프린터 캔버스에 렌더링하는 방법입니다. THPDFMetafileRenderDevice는 TakeMetafile이 소유권을 옮기기 전까지 TMetafile을 소유하며, 이것이 벡터 콘텐츠를 필요로 하는 소비자에게 벡터로 유지합니다
var
Device: THPDFDeviceContextRenderDevice;
begin
Printer.BeginDoc;
try
Device := THPDFDeviceContextRenderDevice.Create(
Printer.Canvas.Handle, Printer.PageWidth, Printer.PageHeight);
try
Pdf.RenderLoadedPageToDevice(PageIndex, 300, Device);
finally
Device.Free;
end;
finally
Printer.EndDoc;
end;
end;
런타임 클래스를 테스트하는 대신 Kind를 읽는 것은 의도적입니다. 디바이스 종류로 디스패치하는 애플리케이션 코드는 디바이스가 감싸지거나 장식되거나 교체될 때도 계속 작동하며, is THPDFBitmapRenderDevice를 테스트하는 코드는 그렇지 않습니다
소유권 이전이 실제로 의미하는 바
TakeBitmap 또는 TakeMetafile 전에는 디바이스가 객체를 소유하고 자신의 소멸자에서 해제합니다. 호출 후에는 여러분이 그것을 소유하고 디바이스는 더 이상 소유하지 않습니다. 두 패턴 모두 정당합니다. 객체가 렌더링 호출보다 오래 살 필요가 없을 때는 Bitmap 또는 Metafile 프로퍼티를 사용하고, 객체가 디바이스보다 오래 살 때는 소유권을 가지십시오
실패 모드는 일반적인 Delphi의 그것입니다. 비트맵을 가져오고, 디바이스를 해제하고, 비트맵 해제를 잊으면 페이지 수에 비례해 자라는 누수가 생깁니다. 5페이지 테스트에서는 보이지 않고 500페이지 배치에서는 분명해집니다. 두 객체를 하나를 공유하는 대신 각자의 try/finally로 감싸면, 소유권 질문은 스스로 답합니다
같은 페이지 안의 오버프린트 교정과 투명도
오버프린트 미리보기가 켜져 있을 때도 투명도 그룹 녹아웃은 활성 상태로 남으며, 둘 다 동일한 경계가 있는 페인트 스냅샷 경로에서 합성됩니다. 이것은 중요한데, 실제 인쇄용 파일은 둘을 끊임없이 섞기 때문입니다. 아트워크를 담은 투명도 그룹이 블랙이 오버프린트로 설정된 배경 위에 놓이며, 한쪽만 시뮬레이션하면 올바른 것이 아니라 새로운 방식으로 틀린 교정을 만들어냅니다
한계는 잘 봐두십시오. 오버프린트 미리보기는 위에서 이름 지은 오버프린트 통제 아래의 DeviceCMYK 페인트에 대해 프로세스 잉크 동작을 시뮬레이션합니다. 이것은 잉크 상호작용의 교정이지 색 관리된 계약 교정이 아닙니다. ICC 워크플로를 대체하지 않으며, 특정 인쇄기와 용지가 무엇을 낼 것인지 알려주지 않습니다. 이것을 프리프레스 운영자가 전문 뷰어의 오버프린트 미리보기를 대하는 방식처럼 대하십시오. 즉 일반 미리보기를 보는 것으로는 아무도 잡지 못하는 오류를 잡는 검사로 말입니다
프리플라이트 단계에 교정 끼워 넣기
이것이 유용한 자리는 이미 실행하는 검사 옆입니다. 프리플라이트 패스가 블랙 텍스트가 오버프린트로 설정되었다고 보고하면, 교정 렌더가 운영자에게 그것이 페이지에서 무엇을 의미하는지 보여주며, 둘 다 같은 보고서에 들어갑니다. 오버프린트와 빈번하게 동반되는 패키징 작업의 스포트 컬러에 대해서는 Separation과 DeviceN 스포트 컬러 렌더링 산책문이 같은 페이지의 색료 측면을 다루고, PDF 페이지를 비트맵으로 렌더링하기와 TPrinter로 로드된 PDF 인쇄하기에 관한 글은 두 디바이스 대상을 일반적인 비교정 형태로 다룹니다
HotPDF는 Delphi와 C++Builder를 위한 네이티브 VCL 코드로 로드된 PDF 페이지를 렌더링, 교정, 인쇄하며, 애플리케이션 옆에 배포할 외부 렌더링 DLL이 없습니다. HotPDF 컴포넌트 페이지에 렌더링 기능 목록과 평가판 빌드가 있습니다