Windows 서명 appearance 프로파일

Windows sign 연산은 이름 붙은 내장 프리셋과 명시적으로 공급한 임베드 가능 TrueType 폰트로 보이는 Unicode 서명 appearance를 만들 수 있습니다

{"schemaVersion":1,"type":"sign","incremental":true,
 "existingField":true,"fieldName":"ApprovalOne",
 "pfxFile":"C:/keys/signer.pfx","pfxPassword":"password",
 "appearance":{"profileName":"HotPDF.StandardApproval",
   "text":"Signed by Alice","fontFile":"C:/fonts/DejaVuSans.ttf"}}

실제 프리셋 선택

선택된 프리셋은 호출자가 정의한 시각 옵션에 이름표를 붙이는 게 아니라 실제 프로듀서를 설정합니다. HPDFSelectHeadlessSignatureAppearanceProfile이 반환하는 구성과 동일합니다

text가 실제 캡션을, fontFile이 그 TrueType 프로그램을 공급합니다. 둘 다 필수이고 비어 있지 않은 Unicode 문자열이며, 세 appearance 문자열 모두 NUL 없는 16,384 UTF-8 바이트로 제한됩니다

폰트 임베딩 권한, Unicode 유효성, 가용 글리프, 복잡한 셰이핑 요구, 캡션 맞춤, 설정된 한도는 생성 중에 강제됩니다

위젯과 서명된 문서

생성은 선택된 서명 field에 속한 모든 Widget의 normal AP/N Form XObject를 갱신합니다. 병합된 field와 별도 Widget 자식을 둔 field도 포함입니다

각 Widget은 자기만의 양수 사각형 크기와 선택적 MK/R 회전 0, 90, 180, 270도를 공급합니다. 프리셋 정렬이 상속된 정렬 힌트보다 우선합니다

기존 AP 사전이 있으면 rollover와 down appearance는 유지됩니다. 잘못된 지오메트리, appearance 사전, 회전, 순환 Widget 계층은 생성을 거부합니다

서명 연산은 기존 field, 새 field, 증분 암호화 갱신, 서명 없는 문서 서명, 첫 인증 서명, P2나 P3 및 field 잠금 정책이 허용하는 이후 승인 서명을 지원합니다

실제 인증 동작은 certificationPermission으로 고르세요. StandardCertification appearance만 고른다고 문서가 인증되지는 않습니다

생성된 폰트와 appearance 객체는 원본 문서 암호화 정책을 따르고, 허용된 증분 서명에서는 원본 소스 접두어와 이전 서명이 그대로 유지됩니다

seed 요구와 한도

필수 SV AppearanceFilter는 이 서명 연산에서 실제 생성된 프리셋하고만 일치합니다. 기존 메타데이터나 이전에 저장한 appearance만으로는 그 요구를 충족하지 못합니다

AP 사전은 검사를 위해 HotPDFProfile을 기록하고, 성공한 결과는 appearanceProfile을 보고합니다. 둘 다 이 연산이 쓴 프리셋을 기술합니다

폰트 바이트는 8 MiB와 memoryBytes의 1/8 중 작은 값으로 제한되고, 생성 appearance 바이트는 memoryBytes의 1/8 상한을 공유하며, 각 Widget은 objectCount의 대상인 유한한 객체 일곱 개를 더합니다

취소, 잘못된 프리셋, 충족되지 않은 필수 seed, 잘못된 생성은 원본 문서 핸들을 유지하고 PDF 바이트를 발행하지 않습니다. 출력 콜백은 기존 콜백 실패 의미론을 유지합니다

appearance는 실제 서명 타임스탬프, 인증과 법적 증명, 또는 인증된 서명 폐기 정보와 조합하세요

연산 수명 주기, 권한, 예산, 발행 계약은 증분 PFX 서명을 참고하세요