HotPDF リリースノート

Version history for HotPDF user-visible features, fixes, compatibility updates, and documentation changes.

Languages: English (US)English (UK) Español (España) Español (Latinoamérica) Deutsch Français Italiano 日本語 Português Nederlands Svenska Polski Türkçe 한국어 العربية Русский 简体中文繁體中文

Version 2.137.6

Added THotPDF.DACopyFile for large-file workflows that only need a page count and an original byte-for-byte saved copy without building the full normal object graph.
Improved file-based encrypted PDF loading so password opens no longer cache the whole source PDF just to recover raw encryption dictionary values.
Reduced AES-256 stream decryption memory copying by decrypting from existing buffers where possible, including loaded stream memory for large encrypted image streams.
The HugeFileBenchmark demo now includes a direct-copy row while the default operation set still covers the full LoadFromFile + SaveLoadedDocument path.

Version 2.137.5

Added Direct File API object-source editing for large-file workflows: applications can open a PDF with DAOpenFileReadOnly, inspect object counts and source bodies, replace or append object bodies, update document information, and save a full rewritten copy.
Expanded Direct File API indexing to cover traditional xref tables and xref streams, including compressed object entries, so image-heavy PDFs and object-heavy PDFs can use the lightweight path.
Optimized Direct File API full rewrites by copying unchanged direct objects in source-offset order and merging contiguous ranges, greatly reducing random I/O on PDFs with hundreds of thousands of objects.
The HugeFileBenchmark demo now includes a direct-rewrite operation and documents HTML/CSV benchmark runs for image-only and mixed text/image huge PDFs.

Version 2.137.4

Delphi の PreflightReport デモを、console sample から single-file preflight workflows 向けの対話型 VCL GUI ツールに強化しました。
GUI は標準の text、JSON、HTML レポート、任意のパスワード、profile INI files、組み込み presets、single-file PDF/VT validation、embedded-report PDF output、report preview、status logging、automatic output naming、生成ファイルへのクイックアクセスをサポートします。
command-line arguments が指定されていない場合に sample PDF と report を自動作成していた従来の起動動作を削除しました。

2026-05-26 Version 2.137.3

PDF/VT validation now recognizes XMP properties written as RDF attributes as well as element text, covering common pdfvtid:GTS_PDFVTVersion, pdfvtid:GTS_PDFVTModDate, and xmp:ModifyDate packet styles.
Added Delphi regression coverage that keeps attribute-style PDF/VT metadata detection separate from the remaining structural PDF/VT checks.

2026-05-26 Version 2.137.2

Improved embedded preflight report validation so source PDFs that legitimately end with a final line break after %%EOF keep matching their stored fingerprint.
Preflight profiles saved as UTF-8 with a BOM now load correctly when the first line is a section header.
Hardened PDF literal string escape decoding, improving password validation and unencrypted-copy output for encrypted PDFs with escaped owner or user entries.

2026-05-26 Version 2.137.1

Extended CFF parser safety to direct byte-array checks, restoring the reader position after malformed input and clearing stale layout state on failed checks.
Hardened the C++Builder wrapper-compatible CFF stream loader so nil stream input returns False and resets the wrapper state instead of dereferencing the stream.

2026-05-26 Version 2.137.0

Added THotPDF.ValidatePDFVT with password-aware overloads for focused PDF/VT validation. The text report checks the XMP PDF/VT claim, metadata namespace, PDF/VT modification date matching, PDF/X base marker, output intent, catalog DPartRoot structure, loadable pages, and page-level DPart coverage.
The standalone HotPDFPreflight CLI now accepts --pdfvt to write .pdfvt.txt validation reports for a single PDF or recursive directory scan.

2026-05-26 Version 2.136.8

Improved Type 1 PFB and CFF parser failure handling so malformed stream checks preserve the input position and clear stale metadata instead of leaving a previous font name visible after a failed check.
Added additional Type 1/CFF smoke coverage for malformed CFF and Type 1 streams, including stream-position preservation and stale-metadata cleanup after failed parser calls.

2026-05-26 Version 2.136.7

Hardened the Type 1 PFB and CFF parser entry points so stream-based checks preserve the caller's stream position, reject malformed data safely, and expose basic Type 1/CFF font metadata through the Delphi and C++Builder wrapper paths.
Expanded the Type 1/CFF smoke test with in-memory CFF data, ASCII Type 1 font data, wrapper-level PFB file loading, and wrapper-level CFF stream loading to protect both Delphi and C++Builder integration surfaces.

2026-05-26 Version 2.136.6

Added Delphi feature demos for CJK Unicode text output, large multi-page document generation, PFX signing, and expanded image-compression coverage with CCITT Group 3 1D and 2D output.

2026-05-26 Version 2.136.5

Preflight reports now continue when a loaded page entry cannot return a MediaBox. The report marks that page as unavailable instead of aborting, so large or inconsistent page trees still produce diagnostic output.
Optimized several byte-level preflight scanners to avoid repeated full-tail string copies and linear duplicate-object searches. The 10,000-page implementation-limit sample now completes within the 120-second stress-test budget.
The preflight stress runner now defaults to a 120-second per-file timeout, and the PreflightReport demo rebuilds cleanly after the profile-aware output path.

2026-05-26 Version 2.136.4

Added a preflight cookbook, a generated preflight API map, and a large-directory stress-test workflow for the HotPDFPreflight command-line tool. The stress runner isolates each PDF behind a per-file timeout and records JSON, Markdown, CSV, report, and log evidence.
Fixed a full rebuild issue in the preflight fingerprint helper by declaring the helper before CreatePreflightReport uses it, so console tools that rebuild HPDFDoc.pas from source compile cleanly.
Recorded a 1000-file baseline against D:\PDFdoc\PDF-Samples: 997 passed, 1 failed, 2 timed out, 111.422 seconds elapsed, 8.975 files per second.

2026-05-25 Version 2.136.3

The standalone HotPDFPreflight CLI tool gains an --aggregate <file> option that writes a batch summary produced by THotPDF.AggregatePreflightReports after the per-file reports finish. The aggregate lists every processed PDF with status / size / warning counts and totals.
Works with single files and recursive directory walks, with or without --profile / --preset. The aggregate is computed from the text body of each report so filtering by profile is reflected in the summary.
Example: HotPDFPreflight C:\Archive -r --preset silent-actions -f json -o C:\Archive\reports --aggregate C:\Archive\Aggregate.txt writes JSON reports for every PDF plus a single batch summary.

2026-05-25 Version 2.136.2

The standalone HotPDFPreflight CLI tool gains --profile <file> and --preset <name> options to filter each report through a preflight profile before writing it. Works alongside -f text|json|html, -p <password>, and -r recursive directory walks.
The two new options are mutually exclusive (passing both, the later one wins). The preset values match what THotPDF.GetBuiltInPreflightProfile recognises so CI pipelines can pull a canonical configuration without staging an INI file.
Example: HotPDFPreflight C:\Archive -r --preset silent-actions -f json -o C:\Archive\reports writes JSON reports for every PDF in the directory tree with the silent-actions preset applied.

2026-05-25 Version 2.136.1

The Delphi PreflightReport demo now accepts profile=<file> or preset=<name> as an additional CLI argument to filter the report through a profile before writing it. Works alongside the existing json / html / embed output format flag.
Examples: PreflightReport.exe Input.pdf Report.txt "" text profile=tuned.ini or preset=compact / preset=silent-actions.
The preset values mirror the names recognised by THotPDF.GetBuiltInPreflightProfile so the demo doubles as a profile testbed without having to author an INI file.

2026-05-25 Version 2.136.0

Added THotPDF.MergePreflightProfiles for layering profiles. The result is the deduplicated union of both inputs (DisableChecks and DisableWarnings are merged, DisableHints is the logical OR), useful for combining a preset such as compact with project-specific tweaks.
Added THotPDF.DiffPreflightProfiles for structural comparison. Returns True when two profiles are equivalent, otherwise the OnlyInA and OnlyInB out parameters list the entries exclusive to each side as newline-separated check:<name> / warn:<name> / option:hints=false tokens.
The two helpers complete the profile lifecycle: Load / GetBuiltIn / Save / Apply / Validate / Merge / Diff.

2026-05-25 Version 2.135.0

Added THotPDF.CreatePreflightReportWithProfile, a one-stop convenience wrapper that composes CreatePreflightReport, LoadPreflightProfile, ApplyPreflightProfile, and the format converters into a single call.
The new overload accepts a source PDF, optional password, optional profile file, and target format (pfText, pfJSON, or pfHTML) and returns the final report body. Passing an empty ProfileFile skips the profile step entirely so callers can keep a single call site regardless of whether they have a profile configured.
The four underlying APIs remain available so existing call chains keep working unchanged; the new wrapper is purely additive.

2026-05-25 Version 2.134.0

Added THotPDF.SavePreflightProfile for writing a THPDFPreflightProfile record back to an INI file. The output format matches what LoadPreflightProfile consumes, so the two functions are exact inverses for well-formed profiles.
Enables a 'load preset, tweak, save' workflow: pull a built-in preset with GetBuiltInPreflightProfile (v2.133.0), modify the lists or flags, then SavePreflightProfile the result for later reuse or sharing across projects.
Sections with no content are omitted from the output so an empty profile produces a single comment line instead of three empty section headers.

2026-05-25 Version 2.133.0

Added THotPDF.GetBuiltInPreflightProfile, which returns ready-to-use THPDFPreflightProfile records for common workflows so callers do not have to maintain INI files for canonical configurations.
Recognised names (case-insensitive): default or empty string returns an empty profile; compact disables every Hint line for shorter reports; silent-actions disables every PDF 1.7 sec 12.6.4 action warning plus EmbeddedFile and RichMedia, intended for workflows that intentionally embed multimedia or interactive actions.
Unknown names also return an empty profile so the function never raises on a typo; pair with ValidatePreflightProfile (v2.132.0) when the caller wants typos surfaced as errors.

2026-05-25 Version 2.132.0

Added THotPDF.ValidatePreflightProfile for defensive profile checking. The function walks the loaded profile's DisableChecks and DisableWarnings lists and flags any name that is not recognised by the current preflight implementation, returning the unknown names joined by ', ' in the UnknownNames out parameter.
Useful to detect profile files authored against a newer or older HotPDF version. Without validation a typo (OpneAction instead of OpenAction) or a renamed check would silently disable nothing.
The check is purely defensive; the profile itself is not modified. Callers can decide whether to abort, log a warning, or proceed with the partially-effective profile.

2026-05-25 Version 2.131.0

Added THotPDF.ConvertPreflightReportToVeraPDFStyle, a converter that shapes a HotPDF preflight report into a JSON document modeled on veraPDF's validation output: top-level profile, a jobs array containing itemDetails / taskResult / validationResult, plus a ruleViolations array under validationResult.details.
HotPDF-styled rather than wire-compatible with veraPDF; the goal is to let downstream tooling that already consumes veraPDF JSON adapt to HotPDF output with minimal field-name remapping rather than re-learning a different data layout.
Rule violations carry the same specification ISO clause cross-reference that the native HotPDF JSON output emits, so callers retain spec-level traceability when consuming via the veraPDF-style path.

2026-05-25 Version 2.130.0

Added THotPDF.EmbedPreflightReportAsXMP with two overloads (with and without an optional Password argument). The function writes a copy of the source PDF with the preflight report appended as a PDF-style comment block whose payload is XMP / RDF with the xmlns:hotpdf namespace.
Each report line becomes a hotpdf:<name> element. PASS / FAIL checks carry the severity as an attribute; warnings, hints, and info lines use warn, hint, and info prefixes on the element name.
XMP-aware tools that scan a file for xpacket markers can surface the embedded report. PDF readers continue to ignore the appended bytes because they fall outside the object graph. This is archival-friendly XMP embedding, not a spec-compliant XMP integration; the XMP payload is not referenced from the catalog /Metadata entry.

2026-05-25 Version 2.129.0

Added THotPDF.LoadPreflightProfile and THotPDF.ApplyPreflightProfile with a new THPDFPreflightProfile record. Profiles let callers tailor the report output without re-running the analysis, suppressing specific check / warning names or every Hint line.
Profile files use a simple INI-style format with [disable-checks], [disable-warnings], and [options] sections. Comments and blank lines are ignored. Empty profiles pass the report through unchanged.
After filtering, the trailing Summary and Warnings lines are recomputed so the suppressed entries no longer contribute to the Failed and Warnings totals. The rest of the report passes through unchanged, so JSON / HTML converters, diff helper, validate / embed / aggregate APIs continue to work on the filtered report without code changes.

2026-05-25 Version 2.128.2

Added a Delphi PreflightDashboard console demo that scans a directory of PDFs and writes a self-contained static HTML dashboard: one <stem>.preflight.html per file plus an index.html summary table.
The dashboard shows total / passed / failed counts at the top and a table of every PDF with status, size, summary, and a link to the detailed report. Failed rows are highlighted; PASS and FAIL badges are colour-coded for quick scanning.
Output is a static directory of files (no HTTP server required); publish the directory to a CI artifact page, serve it from any web server, or open index.html directly in a browser.

2026-05-25 Version 2.128.1

Added tools/validate-preflight-json.py, a Python utility that validates HotPDF preflight JSON output against the published schema (Docs/preflight-schema.json). The script reports one PASS/FAIL line per input and exits with a non-zero status when any input fails validation, so CI pipelines can gate on schema conformance.
Validation is strict because the schema declares additionalProperties: false on every object, so unknown fields cause a hard failure rather than silently slipping through. Required dependency is the standard jsonschema Python package.

2026-05-25 Version 2.128.0

Added THotPDF.AggregatePreflightReports for batch summaries. The function accepts an array of per-file preflight reports and emits a single aggregate that lists each file's pass/fail status with byte size and warning count, plus totals for passed, failed, warnings, and bytes scanned.
Pairs naturally with the v2.125.1 HotPDFPreflight standalone CLI: run the CLI to produce one report per PDF, then feed the report bodies into AggregatePreflightReports for a dashboard-ready batch summary.
Empty input arrays yield an empty result string so callers can append the aggregate to other output unconditionally without guarding against zero-file directories.

2026-05-25 Version 2.127.0

Added THotPDF.RepairPDFFromPreflightReport with two overloads (with and without an optional Password argument). The function applies a conservative subset of byte-level repairs to damaged PDFs: it drops trailing bytes that follow the final %%EOF marker, and appends a missing %%EOF when one is not present anywhere.
Returns True when at least one repair was applied; RepairsApplied is an out parameter that lists the repairs one per line, so callers can decide whether to keep the repaired file or escalate to a heavier recovery tool.
Object-graph repairs (rebuilding xref tables, patching stream lengths, fixing trailers) are intentionally out of scope because such fixes can make a partially-recoverable file less recoverable. The repairs in this overload are limited to operations that are unambiguously safe on well-formed and lightly-damaged PDFs alike.

2026-05-25 Version 2.126.1

Published a formal JSON Schema for the preflight JSON output at Docs/preflight-schema.json, conforming to JSON Schema draft 2020-12.
The schema documents every top-level field (input, size, pdfVersion, xrefStyle), the checks / info / hints / warnings arrays, and the summary object so consumer pipelines can validate the JSON output before parsing.
The help topic now points downstream consumers at the schema file for reference.

2026-05-25 Version 2.126.0

Added THotPDF.ComparePreflightReports for line-by-line preflight report comparison. The function emits a unified-diff-like body where shared lines use a two-space prefix, lines unique to ReportA use - , and lines unique to ReportB use + .
Pairs naturally with LoadAndValidatePreflightReport: when a roundtrip validation fails, feed the original and current reports into ComparePreflightReports to surface exactly which lines changed.
The diff algorithm is a small greedy walk tuned for the deterministic key/value output of CreatePreflightReport; it produces compact diffs for typical inputs without pulling in a general-purpose LCS implementation.

2026-05-25 Version 2.125.1

Added a standalone Delphi console tool HotPDFPreflight for batch-running the preflight report against single files or whole directories. The tool accepts -o output directory, -f text|json|html output format, -p password, -r recursive directory walk, and -v verbose progress flags.
Exit codes follow standard CLI conventions: 0 success, 1 usage error, 2 input not found, 3 one or more PDFs failed preflight, so the tool can be integrated into CI pipelines and shell scripts.
Each report is named <basename>.preflight.<ext> with the extension picked from the requested format.

2026-05-25 Version 2.125.0

Added THotPDF.LoadAndValidatePreflightReport with two overloads (with and without an optional Password argument). The function extracts the report that EmbedPreflightReportInPDF previously appended, re-runs the current preflight algorithm against the source bytes, and returns True when the embedded InputFingerprint still matches the freshly-generated one.
Out parameters OriginalReport and CurrentReport receive both reports so callers can diff them when validation fails, identifying what changed between the time the report was embedded and the validation run.
Pairs naturally with EmbedPreflightReportInPDF: embed once during archival, validate any time later to detect tampering or accidental modification.

2026-05-25 Version 2.124.2

Added two fingerprint lines to THotPDF.CreatePreflightReport for CI stability checks. InputFingerprint emits a 64-bit FNV-1a hash of the source PDF bytes as 16 lowercase hex digits, immediately after the Size: line. ReportFingerprint emits a 64-bit FNV-1a hash of the assembled report (everything above the fingerprint line) at the end of the report.
CI pipelines can compare fingerprints across runs to detect unintended drift in either the input file or the report content without parsing every diagnostic line.
Both fingerprints are non-cryptographic; FNV-1a is deliberately chosen for low overhead and inline implementation without pulling in an external hashing module.
JSON output places InputFingerprint in the info array and ReportFingerprint at the tail of info; both entries carry a spec field labelled "FNV-1a 64-bit (non-cryptographic)".

2026-05-25 Version 2.124.1

Added two conditional incremental-update revision diagnostic lines to THotPDF.CreatePreflightReport. When IncrementalUpdates > 0, the report now includes RevisionStartXRefPositions (byte offsets of each startxref keyword in the file, ordered oldest first) and RevisionXRefTargets (the xref offsets each marker points to), so callers can trace the incremental update chain without parsing the file manually.
Clean and single-revision PDFs remain byte-stable: the new lines are emitted only when more than one startxref marker is found.
ISO 32000-1 sec 7.5.6 spec references are added in the JSON output for the new fields.

2026-05-25 Version 2.124.0

Added THotPDF.EmbedPreflightReportInPDF with two overloads, one with an optional Password argument for supported encrypted PDFs. The method writes a copy of the source PDF with the preflight report appended after the last %%EOF as PDF-style comment lines.
The report travels with the document for archive workflows: text editors, grep, and audit tools can surface it long after the file leaves the originating workstation.
PDF readers continue to render the document as-is because the appended bytes fall outside the object graph; the cross-reference table and trailer dictionary are untouched.
The Delphi PreflightReport demo gains an embed CLI argument that writes the embedded variant alongside the standalone report.

2026-05-25 Version 2.123.1

Added a regression test that hand-crafts a PDF with duplicate object numbers, a malformed xref row, and an unbalanced stream/endstream pair, then verifies that the three Phase F root-cause diagnostic lines (DuplicateObjectList, FirstMalformedXRefOffset, StreamEndStreamDelta) trigger as expected.
No library behaviour change: the test fills a gap in the regression suite that previously only covered the clean and "not a PDF" cases.

2026-05-25 Version 2.123.0

Added HTML output format to THotPDF.CreatePreflightReport and THotPDF.SavePreflightReport. The THPDFPreflightFormat enum gains a third value pfHTML alongside pfText and pfJSON.
HTML output is a self-contained dashboard-style document with inline CSS, severity-coloured rows (green for PASS, red for FAIL, yellow for WARN), per-section tables for checks, hints, info, and warnings, plus a summary card. No external CSS, JavaScript, or fonts are required.
Each table row includes the ISO 32000-1 / ISO 19005 / ISO 15930 / ISO 14289 spec reference when available, matching the JSON output spec field added in v2.122.1.
HTML output is byte-safe: ampersand, less-than, greater-than, double-quote, and single-quote are escaped; UTF-8 byte sequences pass through unchanged.
The Delphi PreflightReport demo accepts html as the fourth CLI argument to request HTML output.

2026-05-25 Version 2.122.4

Added PDF/X subset detection to preflight reports. When a PDF/X claim is detected, the new Hint PDFXVersion line names the specific subset (X-1a:2001, X-1a:2003, X-3:2002, X-3:2003, X-4, X-4p, X-5g, X-5pg, X-5n, or X-5).
Added PDF/UA part extraction. When a PDF/UA claim is detected, the new Hint PDFUAPart line reports the value from pdfuaid:part in the XMP metadata.
ISO 15930 and ISO 14289 spec cross-references are added to the JSON output for the new hint entries.
Clean PDFs with no PDF/X or PDF/UA claim remain byte-stable: the new hints are only emitted when the underlying claim is detected.

2026-05-25 Version 2.122.3

Added root-cause diagnostic lines to THotPDF.CreatePreflightReport. When a damaged PDF triggers a defect count, the report now lists actionable detail.
DuplicateObjectList appears whenever DuplicateObjectNumbers > 0 and lists up to five repeated object numbers, so callers can pinpoint which objects collide.
FirstMalformedXRefOffset appears whenever XRefMalformedEntries > 0 and gives the 1-based byte offset of the first malformed cross-reference row.
StreamEndStreamDelta appears whenever the stream and endstream marker counts differ and gives the signed difference, indicating how many markers are missing or duplicated.
Clean PDFs remain byte-stable: the new diagnostic lines are only emitted when the underlying defect counters are non-zero.

2026-05-25 Version 2.122.2

Extended preflight action warnings to cover the full PDF 1.7 §12.6.4 action set. Added 15 advisory warnings: GoToRAction, GoToEAction, ThreadAction, URIAction, SoundAction, MovieAction, HideAction, NamedAction, SubmitFormAction, ResetFormAction, ImportDataAction, SetOCGStateAction, RenditionAction, TransAction, and GoTo3DViewAction.
Warnings are emitted only when the corresponding action token is detected; clean PDFs that contain no actions stay byte-stable.
The ISO 32000-1 spec cross-references in the JSON output now cover the new action warnings as well.

2026-05-25 Version 2.122.1

Extended THotPDF.CreatePreflightReport JSON output with ISO specification cross-references. Every checks, hints, and warnings entry now carries a spec field naming the ISO 32000-1, ISO 19005, ISO 15930, or ISO 14289 clause for that diagnostic.
The plain-text report is unchanged and remains byte-stable; the spec field appears only in pfJSON output.
The mapping covers every check, hint, and warning emitted by the report through v2.122.0, so JSON consumers can route findings to the matching spec clause without an external lookup table.

2026-05-25 Version 2.122.0

Added machine-readable JSON output to THotPDF.CreatePreflightReport and THotPDF.SavePreflightReport. New THPDFPreflightFormat enum exposes pfText (default plain-text path) and pfJSON (CI-friendly JSON document) values.
New format-aware overloads accept the Format parameter while keeping the legacy text overloads byte-stable. Existing applications continue to work without code changes.
JSON output groups entries into top-level input, size, pdfVersion, and xrefStyle fields plus checks, info, hints, warnings arrays and a summary object with failed, warnings, and result counters.
Built-in JSON encoder escapes ", \, control bytes, and preserves UTF-8 byte sequences without requiring an external JSON library.
The Delphi PreflightReport demo accepts a fourth CLI argument json to request JSON output for an input PDF.

2026-05-25 Version 2.121.36

Enhanced preflight reports with compliance marker hints. Reports now expose Hint PDFAClaimed, Hint PDFAPart, Hint PDFAConformance, Hint PDFXClaimed, Hint PDFUAClaimed, Hint TaggedPDF, and Hint HasTransparency lines for downstream tooling.
Added advisory warnings PDFAWithEncryption, PDFAWithJavaScript, and PDFA1WithTransparency that fire when a PDF/A-claimed document also carries encryption, JavaScript, or PDF/A-1-forbidden transparency markers.
Hint lines never increment the Failed counter, and the helpers remain advisory; they do not replace a full PDF/A, PDF/X, PDF/UA, or ISO 32000 conformance engine.

2026-05-25 Version 2.121.35

Enhanced preflight reports with content resource integrity diagnostics. Reports now include resource dictionary, font, embedded font program, image XObject, form XObject, ColorSpace, annotation, widget, and link counts.
Reports now include filter chain usage counts for FlateDecode, DCTDecode, CCITTFaxDecode, JBIG2Decode, LZWDecode, ASCIIHexDecode, ASCII85Decode, RunLengthDecode, and JPXDecode.
Added pass/fail check FontsHaveEmbeddedPrograms that verifies at least one /FontFile, /FontFile2, or /FontFile3 is present whenever font resources are declared.
Added pass/fail check AnnotationCountConsistent that verifies the sum of widget and link annotation counts does not exceed the overall annotation count.

2026-05-25 Version 2.121.34

Enhanced preflight reports with trailer root type diagnostics. Reports now verify that the trailer /Root indirect reference targets an object declared as /Type /Catalog.

2026-05-25 Version 2.121.33

Enhanced preflight reports with trailer ID diagnostics. Reports now count hex string entries in the trailer /ID array and verify that the file identifier is present as a valid two-entry pair when an ID array is supplied.

2026-05-25 Version 2.121.32

Enhanced preflight reports with trailer indirect-reference diagnostics. Reports now show the trailer /Root and /Info object references and verify that the referenced objects are defined in the file.

2026-05-25 Version 2.121.31

Enhanced preflight reports with stream length coverage diagnostics. Reports now count stream /Length entries and verify that detected streams have length entries available.

2026-05-25 Version 2.121.30

Enhanced preflight reports with revision marker diagnostics. Reports now count %%EOF markers and startxref sections, verify that the counts are balanced, and check that the final startxref marker appears before the final EOF marker.

2026-05-25 Version 2.121.29

Enhanced preflight reports with page tree consistency diagnostics. Reports now include the declared page tree /Count and pass/fail checks that compare it, and the counted page objects, with the pages loaded by HotPDF.

2026-05-25 Version 2.121.28

Enhanced preflight reports with xref table row diagnostics. Reports now include xref subsection, entry, free-entry, in-use-entry, and malformed-row counts, plus pass/fail checks for xref row syntax and whether xref coverage reaches the highest object number.

2026-05-25 Version 2.121.27

Enhanced preflight reports with bounded PDF name-pair counting and additional consistency checks. Reports now distinguish catalog, page tree, and page objects; verify that object numbers are unique; and check whether trailer /Size covers the highest object number and whether trailer /Root is present.

2026-05-25 Version 2.121.26

Enhanced the preflight report object and trailer diagnostics. Reports now include indirect object definition counts, highest object number, duplicate object number count, balanced stream/endstream checks, and trailer details for /Size, /Root, /Info, /ID, and /Encrypt.

2026-05-25 Version 2.121.25

Enhanced THotPDF.CreatePreflightReport and THotPDF.SavePreflightReport with deeper cross-reference diagnostics. Reports now verify that the final %%EOF marker is near the end of the file, parse the last startxref offset, identify whether it targets an xref table or xref stream, and include xref table, xref stream, object stream, trailer, incremental update, and linearization counts.

2026-05-25 Version 2.121.24

Expanded the preflight report helpers with password-aware overloads and richer diagnostics. Reports now include the PDF header version, xref style, resolved loaded page MediaBox entries, form field count, stream count, feature presence flags, JavaScript/action/media attachment warnings, warning totals, and pass/fail summaries for damaged files. The Delphi PreflightReport demo accepts an optional password argument for supported encrypted PDFs.

2026-05-25 Version 2.121.23

Added library-level preflight report helpers with THotPDF.CreatePreflightReport and THotPDF.SavePreflightReport. Applications can now generate a text summary for an input PDF covering the header, EOF marker, startxref, trailer or XRef stream, loadable page count, encryption state, catalog, page tree, page object, page box, information dictionary, root reference, indirect object count, and overall pass/fail status. The Delphi PreflightReport demo now uses these APIs directly.

2026-05-25 Version 2.121.22

Added a Delphi PreflightReport console demo that creates a sample PDF and writes a text report with lightweight structural checks, including the PDF header, EOF marker, loadable page count, encryption state, catalog, page tree, page box, and document information dictionary. The workflow keeps AutoLaunch disabled and can also report on an existing input PDF from the command line.

2026-05-25 Version 2.121.21

Added a Delphi SearchAndSelect console demo that builds a report, searches controlled text rows, and marks every matching term with PDF highlight annotations and /QuadPoints. The sample keeps AutoLaunch disabled so it is suitable for command-line and automated validation.

2026-05-25 Version 2.121.20

Added password loading for RC4-40 and RC4-128 Standard encrypted PDFs. Applications can now call LoadFromFile or LoadFromStream with a password, or call DecryptLoadedDocument after loading, then save an unencrypted loaded-document copy with SaveLoadedDocument. The new Delphi DecryptPDF console demo creates a password-protected sample and writes a decrypted copy without launching a PDF viewer.

2026-05-25 Version 2.121.19

Added a Delphi Printer console demo that generates a print-ready PDF preset. The sample writes print-focused /ViewerPreferences, page BleedBox and TrimBox entries, printable annotation flags, and a print-control ExtGState without launching a PDF viewer or sending a job to a physical printer.

2026-05-25 Version 2.121.18

Added a Delphi ConvertTo console demo that converts supported source graphics into PDF output files. The workflow creates separate PDF files from JPEG, BMP, TIFF, and EMF inputs with AutoLaunch disabled, making the sample suitable for command-line and automated checks.

2026-05-25 Version 2.121.17

Added loaded page operation helpers with InsertPagesFromDocument, ExtractPagesToFile, and MovePage. Applications can now insert pages from another loaded document, extract selected pages to a new PDF, and reorder loaded pages while keeping subsequent saves and extraction calls in the updated page order. The Delphi PageOperations demo shows the insert, extract, and reorder workflow without auto-launching a PDF viewer.

2026-05-25 Version 2.121.16

Expanded loaded AcroForm editing with RemoveFormField and FlattenFormFields. Applications can now remove loaded fields by index or name, or flatten loaded fields into static page content while removing the interactive AcroForm tree and widget annotations. The Delphi FormFields demo now shows descriptions, removal, and flattening without auto-launching a PDF viewer.

2026-05-25 Version 2.121.15

Added loaded bookmark title search with THotPDF.FindLoadedBookmarkPageIndex. Applications can now load an existing PDF, search the outline tree by bookmark title, and resolve matching /Dest or local GoTo action destinations to zero-based page indexes.

2026-05-24 Version 2.121.14

Added THPDFPage.AddTextWatermark for drawing rotated transparent text watermarks on generated or loaded pages. The new Delphi Watermark demo creates a source PDF, loads it, applies the watermark to every page, and saves the edited document.

2026-05-24 Version 2.121.13

Added loaded AcroForm field description inspection with GetFormFieldDescription. Applications can now read a loaded field's /TU tooltip text by index or name alongside field values, options, read-only state, and rename operations.

2026-05-24 Version 2.121.12

Added loaded choice-field option inspection with GetFormFieldOptionCount and GetFormFieldOptionValue. Applications can now load an existing combo box or list box field, enumerate its allowed /Opt values, and continue using the same loaded-form update and save workflow.

2026-05-24 Version 2.121.11

Expanded loaded AcroForm editing with IsFormFieldReadOnly and RenameFormField. Applications can now inspect a loaded field's read-only flag, rename fields by index or name, save the loaded document, and reload it with the updated field names intact.

2026-05-24 Version 2.121.10

Added THotPDF.GetLoadedPageBox for inspecting page boundaries after LoadFromFile. Applications can now read a loaded page's MediaBox, CropBox, BleedBox, TrimBox, and ArtBox, including the standard fallback chain for boxes that are not declared directly.

2026-05-24 Version 2.121.9

Added loaded AcroForm field inspection and update APIs. Applications can now load an existing form PDF, enumerate field names and types, read and update field values, toggle a field's read-only flag, and save the loaded document with SaveLoadedDocument. The new Delphi FormFields demo shows the full load, edit, and save workflow.

2026-05-24 Version 2.121.8

Added THotPDF.RegisterLineGraphicsState for reusable line drawing ExtGState resources. Applications can now register line width, cap style, join style, and miter limit once, then apply the named state with THPDFPage.SetGraphicsState before stroking paths.

2026-05-24 Version 2.121.7

Added annotation interaction helpers for writing annotation /F flags and link /H highlight modes. Link helper methods now update LastAnnotation, so flags, highlight modes, border styles, and popup helpers can be chained consistently after link creation.

2026-05-24 Version 2.121.6

Added reusable Form XObject authoring APIs with page-level drawing helpers, including placement, scaling, and rotation support. Added current-transformation-matrix convenience helpers and bounded text helpers for single-line alignment, wrapped text output, and row-count calculation.

2026-05-24 Version 2.121.5

Added reusable Type 1 PFB and CFF parser units for HotPDF, including byte-array readers, Type 1 glyph-outline command extraction, CFF dictionary, INDEX, charset, and encoding readers, plus Type 1 PFB metadata and glyph lookup helpers. Delphi and C++Builder package projects now include the new parser units.

2026-05-24 Version 2.121.4

PDFACompliance='2A' and PDFACompliance='3A' now enable Tagged PDF basics without implicitly emitting a PDF/UA-1 XMP claim. PDF/A Level A files keep /MarkInfo, /StructTreeRoot, document title, language, and archival metadata, while pdfuaid metadata is emitted only when PDFUACompliance is explicitly enabled.
The PDF/A-2/3 smoke coverage now includes PDF/A-3A and asserts that Level A archival output does not advertise PDF/UA unless requested separately. The generated PDF/A-2A and PDF/A-3A smoke files pass veraPDF validation.

2026-05-24 Version 2.121.3

THPDFPage.UnicodeTextOut は、補助平面 Unicode の出力で RegisterUnicodeTTF が生成した Type 0 フォントリソースを再利用するようになり、ページテキストと AcroForm 外観ストリームが同じ内部 CID エンコード経路を共有します。
共有の最終化パスは、FUnicodeUsedCps、/CIDToGIDMap、descendant font の /W、/ToUnicode を通じてページレベルの SMP 出力を同期し、従来のページローカル SMP マップを回避します。

2026-05-24 Version 2.121.2

THPDFPage.UnicodeTextOut 现在将辅助平面 Unicode 字符通过页面的字体中注册的 cmap 格式 12 字形映射进行处理，前提是 RegisterUnicodeTTF 已加载活动字体。表情符号和其他 U+10000 及以上的标量值将以单个字形 CID 的形式输出到页面文本流中，而不是两个代理半字形 CID。
ページフォントの ` /ToUnicode` CMap レコードは、SMP のグリフ CID を元の UTF-16BE サロゲートペアにマッピングし、テキスト抽出とアクセシビリティを維持しながら、既存の ` /CIDToGIDMap /Identity` ページフォントパスを保持します。

2026-05-24 Version 2.121.1

RegisterUnicodeTTF ベースの AcroForm 外観ストリームは、emoji などの補助平面 Unicode 文字を、UTF-16 サロゲートペアを 2 つの Identity-H CID として書き込む代わりに、1 つの内部 CID で描画するようになりました。生成される /CIDToGIDMap はその CID を実際の glyph に向け、/ToUnicode はテキスト抽出用に元の UTF-16BE サロゲートペアへ戻します。
Unicode フォントの最終処理において、すべての表示ストリームが内部 CID マッピングを登録した後、/CIDToGIDMap、/W、および/ToUnicodeが更新されます。これにより、TrueType のサブセット化と生成されたフォームの表示において、最終的な CID 使用セットが適用されます。

2026-05-23 Version 2.121.0

PDF 1.7 §12.6.4.13–15 中，与多媒体操作（渲染/声音/电影）相关的三个新的按钮辅助方法，已添加到 `THPDFPage` 中： `AddPushButtonWithRenditionAction` 用于 §12.6.4.13（将屏幕注释绑定到 MediaRendition + MediaClipData，描述音频/视频片段，以及 /OP 操作 0..4）； `AddPushButtonWithSoundAction` 用于 §12.6.4.14，提供了两个重载版本（文件路径或原始 `TBytes` 数据），以及调用者提供的 `THPDFSoundParams` 记录（采样率/通道/每样本位数/编码），以及可选的 /Volume、/Repeat 和 /Synchronous 参数； `AddPushButtonWithMovieAction` 用于 §12.6.4.15（通过 /Annotation 引用电影注释，并选择 /Operation 为播放/停止/暂停/恢复）。
AddScreenAnnotation および AddMovieAnnotation が、作成された注釈辞書を返すようになりました。これにより、呼び出し元はそれを対応するアクションヘルパーにチェーンすることができます。シグネチャが procedure から function に変更されましたが、これは Delphi の ABI と互換性があり、既存の呼び出し元がこれらを呼び出し、結果を破棄する場合でも、コンパイルでき、バイト単位で同一の PDF が生成されます。
標準の実装深度：各ヘルパーは、仕様で規定されている必須項目に加え、一般的に必要なオプション項目も出力します。オプションのMediaPlayParameters、MediaScreenParameters、Selector Rendition、およびSound/Mixは、意図的に省略されています。これは、標準のデフォルト設定で95%のケースをカバーでき、ヘルパー自体を最小限に保つためです。
PDF/A（所有级别）和PDF/X（所有配置）会拒绝所有三种多媒体操作，并在辅助程序入口处显示一个基于ISO标准的诊断信息（ISO 19005-1 §6.6.1 / ISO 19005-2 §6.5.1 / ISO 19005-3 §6.5.1 / ISO 15930）。现有的注释功能，即AddScreenAnnotation、AddSoundAnnotation和AddMovieAnnotation，仍然有效。
Renditionアクションは、MediaClipDataファイル仕様と、§13.2.6.1の表280で定義されている/P /TF (TEMPACCESS)メディア権限を関連付けます。これは、ユーザーがペイロードをプラットフォームのオーディオ/ビデオコーデックに渡すことができる最小限の権限レベルです。
サウンドアクションストリームでは、オプションのフィールドを仕様で定義されたデフォルト値（Volume=1.0、Repeat=false、Synchronous=false）に設定し、呼び出し元がデフォルト以外の値を渡した場合にのみそれらを出力します。これにより、一般的なケースではアクション辞書のサイズを最小限に抑えることができます。
Sound stream metadata (/R sample rate / /C channels / /B bits per sample / /E encoding) is caller-supplied via the new THPDFSoundParams record. The v2.16-era AddSoundAnnotation entry point still hard-codes 22050 / 16-bit / Stereo / Signed; the new Sound action path avoids that pitfall so callers can play 44.1 kHz mp3, 8 kHz µ-law telephony audio, or any other source at the correct rate.
新しいWin32およびWin64環境で検証済み。 `smoke_multimedia_actions`テスト（4種類の操作の正パスカバレッジ、およびスクリーン/ムービー注釈の連携）と、`smoke_multimedia_actions_pdfa_pdfx`テスト（3種類の操作×PDF/A + PDF/Xをカバーする8つのアサーション）は、`AddScreenAnnotation`および`AddMovieAnnotation`の手順から関数へのリファクタリング後も、引き続き合格しています。また、`smoke_button_actions`の回帰テストも合格しています。

2026-05-23 Version 2.120.15

修正：在执行两个构建后处理操作（来自 v2.84.0 的 TrueType 字体子集器以及来自 v2.94.0 的 PDF/UA-1 §7.18.3 /Tabs /S 自动添加器）之前，`EndDoc` 函数会序列化 PDF 对象图，因此这些更改未能应用到最终文件。使用 `RegisterUnicodeTTF + AddTextField` 的文档会包含完整的字体文件（约 1 MB Latin / 约 14 MB CJK），而不是子集（约 150 KB / 约 500 KB）。`/BaseFont` 缺少六个字母的 AAAAAA+ 子集前缀。PDF/A 的字体描述符中的 `/CIDSet` 流缺失（veraPDF 标记为 ISO 19005-1 §6.3.5 / -2 -3 §6.2.11 失败）。缺少 PDF/UA-1 §7.18.3 /Tabs /S 键的注释页面的 PDF/UA-1 PDF 文档会触发 Matterhorn 检查规则 21-001 和 PAC 3 "Tabs" 错误。
両方の変更器は、`SaveToStream` / `SaveToFile` の前に実行されます。これらは、間接オブジェクトのリストを走査し、PDF を書き込みます。 Unicode TTF を登録しない場合、または `PDFUACompliance` を有効にしないドキュメントの場合、出力は v2.120.14 とバイト単位で同じです。これらの場合、両方の変更器はすでに無効化されていたため、リオーダリングは、v2.120.14 の出力が静かに破損していたドキュメントにのみ影響します。
Win32 smoke_unicode_ttf_subset テストで検証しました (サブセットは、ディスク上の Arial の 33.6% に相当し、676 KB の削減があります。/BaseFont プレフィックスは UYENHH+ArialMT であり、Type 0 /CIDFontType2 /FontDescriptor.FontName で一貫しています)。また、Win32 smoke_pdfua_annot_structparents テストでは、注釈付きページ辞書に "/Tabs /S" がスタンプされており、すべての 5 つの §7.18.3 の注釈構造関連の検証で問題ありませんでした。

2026-05-23 Version 2.120.14

PDF/UA-1 严格结构-角色验证（ISO 14289-1 §7.7 + ISO 32000-1 §14.7.3）：当启用 PDFUACompliance 时，AddStructureElement 现在会拒绝任何不属于 PDF 1.7 §14.8.4 表 333 中定义的 41 种标准结构类型（Document / Part / Art / Sect / Div / BlockQuote / Caption / TOC / TOCI / Index / NonStruct / Private / H / H1..H6 / P / L / LI / Lbl / LBody / Table / TR / TH / TD / THead / TBody / TFoot / Span / Quote / Note / Reference / BibEntry / Code / Link / Annot / Ruby / RB / RT / RP / Warichu / WT / WP / Figure / Formula / Form）或调用者预先注册的自定义角色的 /S 角色。诊断异常信息包含违规的角色字符串，并引用 PDF/UA-1 §7.7 / 表 333，并建议使用 AddStructRoleMap 进行修复。空角色也会被拒绝，并显示相应的错误消息。如果没有此验证，不符合规范的角色将静默地出现在结构树中，并在后续的 veraPDF / PAC 工具中显示为“未知结构类型”错误。
新しいゲートは、PDFUACompliance が True の場合にのみ有効になります。 UA 以外の呼び出し元は、v2.120.14 以前の自由形式ロールの動作をそのまま維持します。 4 つの AddStructureElement のオーバーロード（4 つの引数を持つ AnsiString ベースのもの、v2.88.0 の 6 つの引数を持つ /Alt + /ActualText オーバーロード、v2.95.0 の 7 つの引数を持つ /ID オーバーロード、および v2.119.41 の THPDFStandardStructureType 列挙型オーバーロード）はすべて同じパスに収束するため、1 つのガードで十分です。列挙型オーバーロードは常に表 333 の名前を渡し、したがって常にチェックを通過します。呼び出し元は、このオーバーロードを好んで使用し、コンパイル時にタイプミスや大文字と小文字の区別による問題（例：'Para' と 'P'、'Lbody' と 'LBody'）を回避します。
v2.119.41 已经发布了 THPDFStandardStructureType 枚举 (包含 41 个规范名称，按 5 个 PDF 角色分组：§14.8.4.1 Grouping / §14.8.4.2 Block-level / §14.8.4.3 Inline-level / §14.8.4.4 Ruby+Warichu / §14.8.4.5 Illustration)，以及 StandardStructureTypeToName(T) 用于枚举到名称的查找，和 IsStandardStructureType(Name) 用于调用方验证。v2.120.14 将这些功能集成到 AddStructureElement 入口点，以便自动进行严格检查。一个新的私有辅助函数 _IsCustomRoleInRoleMap 使用安全的字节比较 CompareMem 遍历 FStructRoleMap 动态数组，可以正确匹配自定义的非 ASCII 角色名称，尤其是在 CP_ACP=65001 的主机上。

2026-05-23 Version 2.120.13

修正：HotPDF v2.120.12 的源代码在 RAD Studio 上无法编译，因为两个 `EnableShapingFeatureForSubset` 的重载函数位于 THotPDF 的已发布部分，而 Delphi 会以 E2266 错误（“一组重载方法中只能有一个被发布”）来拒绝。v2.120.13 使用本地化的公共部分对这两个重载函数进行了封装，以便相同的公共 API 可以在 dcc32 / dcc64 上干净地编译；周围的属性和辅助函数保持不变。运行时行为没有改变。

2026-05-23 Version 2.120.12

EnableShapingFeatureForSubset (阶段 8f 完成): THotPDF.EnableShapingFeatureForSubset (FeatureTag) / the THPDFShapingFeature 枚举重载，遍历与请求的特性相关的每个 GSUB 查找。 SetGSUBScript / SetGSUBLanguage 设置 GSUBLanguage 选择状态，枚举所有潜在的替代 GID，遍历 LookupType 1 (Single — Format 1 覆盖 glyphs + Format 2 substituteGlyphIDs 数组), LookupType 2 (Multiple — Sequence.substituteGlyphIDs[]), LookupType 3 (Alternate — AlternateSet.alternateGlyphIDs[]), LookupType 4 (Ligature — Ligature.ligatureGlyph), LookupType 5 / 6 (Contextual / Chained Contextual — 递归进入 SequenceLookupRecord 嵌套查找，深度限制为 8)，LookupType 7 (Extension — 自动转换为有效的查找类型)，以及 LookupType 8 (Reverse Chained — substituteGlyphIDs[]), 并使用 OR 方式将 GID 合并到 FUnicodeExtraUsedGlyphs 中，以便 v2.84.0 的 EndDoc 子集生成器将特性可以生成的每个字形都包含在嵌入的字形子集中。阶段 8f 补充了 v2.119.50 的每个字形的 MarkUnicodeGlyphUsed 功能，并为调用者提供特性级别的批量选项，以便其生产管道可以全局启用某个特性。
この列挙型のオーバーロードは、各THPDFShapingFeature値を、標準的な4バイトのOpenType機能タグセットに割り当てます。 sfArabicGSUB → init / medi / fina / isol / rlig; sfStandardLigatures → liga; sfContextualLigatures → clig + rlig; sfStylisticAlternates → salt; sfIndicShaping → nukt / akhn / rphf / rkrf / pref / half / vatu / cjct / pres / blws / abvs / psts / haln / pstf; sfContextualAlternates → rclt + calt。文字列タグのオーバーロードは、バンドルされた列挙型のケースを超える、正確なターゲット設定のために、任意の4バイトのOpenType機能タグを受け入れます。サブセットの肥大化に関する警告：広範な機能（例：aalt、すべての代替文字にアクセスするなど、一部のフォントではスクリプト内のすべてのグリフが埋め込まれています）を有効にすると、フォントのグリフセットの大部分がサブセットに組み込まれ、v2.84.0のサイズ削減の効果が損なわれます。呼び出し元は、正確なGIDがわかっている場合は、Phase 9 MarkUnicodeGlyphUsedを使用することを推奨します。デフォルトではオフで、明示的に有効にする必要があります。これにより、GSUBエンジンのロードマップのPhase 8の最後のサブフェーズが完了します。
防御型契約与 v2.119.50 版本一致：没有注册任何字体，没有 GSUB 表，使用了非 4 字节的标记，在 (脚本、语言) 路径中缺少功能，查找链为空——所有“无需执行任何操作”的情况都以静默方式执行 (不抛出异常)。重复调用是幂等的 (位图会被按位或合并)。格式 1 / 2 的上下文子表嵌套查找将推迟到未来的版本；格式 3 在实际字体中占主导地位，并且已实现。需要精确格式 1 / 2 上下文覆盖的调用者可以回退到每个字形的 MarkUnicodeGlyphUsed。

2026-05-23 Version 2.120.11

ToUnicode CMap caller-side reverse mapping (Phase 8d completion): three new public methods on THotPDF let callers register additional (substitute codepoint, original Unicode source codepoint sequence) reverse mappings into the EndDoc Adobe-Identity-UCS ToUnicode CMap. The v2.119.61 / v2.119.62 / v2.119.65 release series added 35 hard-coded bfchar entries for the Arabic ligatures (LAM-ALEF / YEH-HAMZA / Allah / Bismillah) and Latin Alphabetic Presentation Forms (fi / fl / ffi / ffl / ff / ſt / st) that HotPDF's producer-side shaping pipeline emits automatically; v2.120.11 closes Phase 8d by letting callers register their own mappings for the substitute glyphs they drive via the v2.119.43-50 GSUB engine APIs (GetSingleSubstituteGlyph, GetMultipleSubstituteGlyphs, GetAlternateGlyph, ApplyLigatureSubstitution, ApplyContextualSubst, ApplyReverseChainedContextualSubst).
RegisterToUnicodeReverseMapping (SubstCodepoint, SourceCodepoints) 记录一个 (替换 → 源) 映射条目。典型的用例包括：在多重替换 (1 GID → N GIDs) 之后，输出替换序列，并注册反向映射，以便消费者读取器可以进行复制/粘贴操作，从而还原到原始的码点；在连字替换 (N GIDs → 1 ligature GID) 之后，输出连字，并注册连字的码点，将其反向映射到 N 个元素的源序列（例如，一个任意的 CALT 上下文连字，将其反向映射到其组成码点）。 ClearToUnicodeReverseMappings 清除所有注册的映射；ToUnicodeReverseMappingCount 报告有多少映射正在等待处理。
EndDoc emit は、呼び出し元が登録したエントリを、組み込みの35エントリブロックの後に、追加の bfchar ブロックとして追加します。これらのブロックは、Adobe CMap 仕様（Technical Note #5014）§1.4.2 および CIDFont Files Specification に従って、自動的に100エントリのサブブロックに分割されます。BMP コードポイントは4つの16進数で出力され、SMP コードポイントは Adobe CMap 仕様に従って、UTF-16BE のサロゲートペア（8つの16進数）で出力されます。登録順序は保持されるため、PDF リーダーの bfchar の「最後に書き込まれたものが優先される」という動作により、呼び出し元は組み込みの35エントリとの衝突に対して、決定的なオーバーライド動作を実現できます（たとえば、呼び出し元が <FB01> "fi" のためのカスタムマッピングを登録すると、v2.119.65 のデフォルトがリーダー側で上書きされます）。RegisterToUnicodeReverseMapping を呼び出さない呼び出し元は、ToUnicode CMap を v2.120.10 のベースラインと完全に同じ状態に保ちます。SetFormUnicodeFontDict ('', nil) を設定すると、パスがクリアされ、呼び出し元の登録がリセットされるため、次の Unicode フォント登録をクリーンな状態から開始できます。

2026-05-23 Version 2.120.10

ミャンマーテキストシェーパ (Phase 8f.10): ミャンマー文字を登録します。 (OpenTypeタグ mymr) を、HotPDFにおける10番目であり最後のインド文字として登録します。これは、ミャンマーのコアブロック (U+1000-U+109F: Burmese, Mon, Sgaw Karen, Western Pwo, Shan, Rumai Palaung, Pa'o) と拡張-A (U+AA60-U+AA7F) をカバーします。新しい ApplyMyanmarReorder は、前処理の並べ替えを行い、 GetMyanmarCategory は、コードポイントの参照を行います。これらは、ApplyIndicReorder ディスパッチャを通じて再利用可能です。
バッチ内の最も複雑な音節構造：Kinzi 3-CP 音節の先頭にある接頭辞（U+1004 + U+103A + U+1039）が検出され、一時的に保持され、R8に従って出力の非常に最初の部分で出力されます。母音E（U+1031）は、R10に従って音節の先頭に移動します。4つの母音字Y / R / W / H（U+103B-U+103E）が収集され、R9に従って固定されたY → R → W → Hの順序で出力されます。この順序は、元の順序に関係なく適用されます。
ASAT (U+103A) および VIRAMA (U+1039) は、どちらも重ね字の処理において、virama として扱われます。DOT BELOW (U+1037) は、ベース文字の下に表示されます。その他のアクセント記号は、ベース文字の上に表示されます。ANUSVARA (Bindu) は、ベース文字の上に表示され、VISARGA は、その後に表示されます。Repha は適用されません。
2つの`IndicScripts`レジストリ項目（メインブロックと拡張-A）が、同じミャンマー語の文字並べ替え関数を共有しているため、拡張-Aの母音とパオ・カレン語の音調記号が、ディスパッチャによって透過的に処理されます。
**完成了11个阶段的非梵文字母语种字形处理批处理**（阶段8f.0-8f.10）：基础设施 + 10个已注册的语种，包括：梵文字母、孟加拉语、古吉拉特语、泰米尔语、泰卢固语、卡纳达语、马拉雅拉姆语、僧伽罗语（婆罗米语系）、高棉语、缅甸语（东南亚语系）。
Unicode 16.0 §16.3 (缅甸语) 以及 OpenType 缅甸语排版规范。

2026-05-23 Version 2.120.9

Khmerテキストシェーパ (Phase 8f.9): Khmerを登録します。 (OpenTypeタグ `khmr`、Unicodeブロック U+1780-U+17FF) を、HotPDFにおける9番目のインド系スクリプトおよび最初の東南アジア系スクリプトとして登録します。新しい`ApplyKhmerReorder`は、前処理の並べ替えを行い、`GetKhmerCategory`は、コードポイントの参照を行います。これらは、`ApplyIndicReorder`ディスパッチャを通じて再利用可能です。
独立音节结构（与 Phases 8f.1-8f.8 使用的婆罗米 R1-R5 模式不同）：前缀元音（E / AE / AI / OE / OO / AU）移动到音节开头；变音符号（MUUSIKATOAN, TRIISAP）和其他上部符号路由到上部缓冲区；Bindu (NIKAHIT) 位于上方；Visarga (REAHMUK, YUUKALEAPINTU) 位于下方。
COENG サブスクリプトの処理：各 COENG (U+17D2) と子音の組み合わせは、元の順序でベースバッファに格納された重子音クラスターを形成し、フォントの 'pres' / 'blws' GSUB 機能がサブスクリプトの位置を調整します。ネストされた COENG もサポートされています。
Rephaがないため：クメール文字はRephaの視覚的な表現を形成しないため、 Ra + COENG + 母音は、音節の末尾に回転する代わりに、元の順序のままになります。
Unicode 16.0 §16.4（高棉语）以及OpenType高棉语字形规范。

2026-05-23 Version 2.120.8

PAdES adbe-revocationInfoArchival CMS signed attribute (PAdES Phase 9): Adobe独自のOIDを生成します。 1.2.840.113583.1.1.8 に、CMSシグネチャ内に含まれるCRLとOCSPの取り消し情報を格納します。 Adobe Acrobatは、この属性を優先的に使用してシグネチャの取り消しチェックを行い、DSS辞書参照やネットワーク経由のOCSP/CRLの取得よりも優先されます。これは、オフライン環境でも検証可能なPDFを実現し、Adobe Acrobatとの互換性を最適化するために重要です。
新しい `THPDFCMSSignOptions` フィールド：
- AdobeCRLsDER: TBytes の配列 - 各要素は、X.509 `CertificateList` (RFC 5280) の DER 形式でエンコードされたデータであり、DSS `/CRLs` ストリームに含まれるものと同じ形式です。
- AdobeOCSPsDER: TBytes の配列 - 各要素は、`BasicOCSPResponse` シーケンス (RFC 6960 §4.2.1) の DER 形式でエンコードされたデータです。注意：これは、外側の `OCSPResponse` ラッパーではありません。完全な `OCSPResponse` を持つ呼び出し元は、まず `responseBytes.response` のオクテット文字列をアンラップして、`BasicOCSPResponse` を抽出する必要があります。
有効化：この属性は、2つの配列のいずれか1つが空でない場合に生成されます。デフォルトでは空（両方の配列）であり、これによりv2.120.7のバイトレベルの安定性が維持されます。
ASN.1 DER 格式，遵循 Adobe 规范： RevocationInfoArchival ::= SEQUENCE { crl [0] EXPLICIT SEQUENCE OF CRL OPTIONAL, ocsp [1] EXPLICIT SEQUENCE OF BasicOCSPResponse OPTIONAL, otherRevInfo [2] EXPLICIT SEQUENCE OF OtherRevInfo OPTIONAL }。HotPDF 使用 [0] 和 [1]；[2] （用于非 X.509 吊销系统的 otherRevInfo）超出范围。
ワイヤ形状（両ブランチが設定済み）： 30 A0 30 <...> A1 30 <...>
**与 DSS 字典共存**: 此属性与 PAdES-B-LT DSS 字典（在 v2.110.0 中引入的目录级别 `/DSS /Certs /OCSPs /CRLs /VRI）是并行的（而不是替代）。严格的 PAdES 验证器（EU DSS、mTOM）通常会尊重 DSS；Adobe Acrobat 会尊重 `adbe-revocationInfoArchival`。为了实现最大的兼容性，请使用 AddPAdESDSSCRL / AddPAdESDSSOCSP 以及 `AdobeCRLsDER` / `AdobeOCSPsDER`，将两个层都填充相同的 CRL / OCSP 字节。
4つの引数を持つ `HPDFCMSBuildSignedData` ラッパーは、新しいフィールドをゼロに設定し、これにより、古い CMS バンドルがバイト単位で同一のままになります。
Adobe Acrobat PDF リファレンス、RFC 5280 (CRL) および RFC 6960 (OCSP) に準拠。

2026-05-23 Version 2.120.7

PAdES content-time-stamp CMS 签名属性（PAdES 第 8 阶段）：发出 id-aa-ets-contentTimestamp（OID 1.2.840.113549.1.9.16.2.20，ETSI EN 319 122-1 §5.2.8 + RFC 5126 §5.11.4），其中包含在签名之前，用于证明文档内容存在于 TSA 声称的时间的预签名 RFC 3161 TimeStampToken。与 signature-time-stamp（第 4 阶段的未签名属性，签名后）不同。
新しい `THPDFCMSSignOptions` フィールドを追加しました。 `GetContentTimeStamp: THPDFCMSTimestampCallback`。 v2.120.3 の `GetSignatureTimeStamp` のミラーイメージです。 HotPDF は、コールバック関数を呼び出し、その際、ドキュメントの SHA-256 ハッシュ（`messageDigest` 属性に格納されているものと同じハッシュ）を渡します。そして、返された TimeStampToken の DER エンコードされた値を、SignedAttributes 内の content-time-stamp 属性の値として埋め込みます。
デフォルトの `nil` は、コンテンツタイムスタンプが生成されないことを意味します。タイムスタンプが必要な場合は、RFC 3161 に準拠した TSA (Timestamping Service) を HTTP で提供するクロージャを割り当ててください。空の `TBytes` が返された場合、エラーを無視して処理を続行します (TSA にアクセスできない場合の安全なエラー処理)。
**免费的TSA端点**（无需订阅），适用于非合格用例： http://timestamp.digicert.com, http://timestamp.sectigo.com, http://timestamp.globalsign.com/tsa/r6advanced1, https://freetsa.org/tsr, http://timestamp.apple.com/ts01。eIDAS认证场景需要商业版QTSA；非法律用途的签名可以使用免费端点（速率受限，但足以满足典型的工作流程）。
コールバック契約：各署名操作ごとに1回呼び出されます。これは、SignedAttributesが確定される前に発生します。TSTバイトは署名の一部となり、署名自体がコンテンツとタイムスタンプをカバーします。そのため、これは署名属性（署名タイムスタンプとは異なり、署名タイムスタンプは署名なしでunsignedAttrsに格納されます）です。
4引数の `HPDFCMSBuildSignedData` ラッパーを設定することで、 `GetContentTimeStamp` を `nil` に設定し、レガシー CMS バンドルがバイト単位で同一のままであるようにします。
呼び出し元の責任：PAdESプレースホルダーには、署名とコンテンツタイムスタンプ（TST）の両方が含まれるように、適切なサイズ（通常は4〜8KB）が必要です。B-Tワークフローでコンテンツタイムスタンプと署名タイムスタンプを組み合わせる場合は、両方のTSTを考慮してください。`AddPAdESSignatureField(Profile='B-T')`のデフォルト値である16KBで、ほとんどの組み合わせに対応しています。
ETSI EN 319 122-1 V1.2.1 §5.2.8 および RFC 3161 §6 および RFC 5126 に準拠。§5.11.4.

2026-05-23 Version 2.120.6

PAdES signer-attributes-v2 signedAssertions [2] branch (PAdES Phase 7): 结束并关闭第三个也是最终的 SignerAttributeV2 可选字段。允许签名者将具有 OID 标识的签名声明（SAML 2.0 声明、JWT 紧凑形式令牌、OAuth 凭证、组织特定的凭证令牌）嵌入到 CMS 签名中。
新しい `THPDFSignedAssertion` レコード： `SignedAssertionID` (アサーションのタイプを識別するドット付き OID) と、`AssertionBody: TBytes` (OID のスキーマで定義された、あらかじめエンコードされた任意のバイト列。通常は SAML XML または JWT のコンパクト形式をラップした OCTET STRING) を含みます。`AssertionBody` が空の場合、ANY フィールドが省略され、`signedAssertionID` だけが残ります (これにより、OID で登録されたブール型の assertion は仕様に準拠します)。
新しい `THPDFCMSSignOptions` フィールドを追加しました。 `SignedAssertions`: `THPDFSignedAssertion` の配列。複数のアサーションをサポートしており、HotPDF はこれらを `[2] EXPLICIT` (タグ `0xA2`) でラップします。
SignerAttributeV2 の生成条件は、現在、3つのオプションフィールドのいずれかが存在する場合にトリガーされます。すべてのフィールドに値を設定すると、仕様のフィールド順序で、次のようになります。 SignerAttributeV2 SEQUENCE { [0] claimed..., [1] certified..., [2] signedAssertions... }
ASN.1 に準拠し、ETSI EN 319 122-1 §5.2.6 に従って: SignedAssertion ::= SEQUENCE { signedAssertionID OBJECT IDENTIFIER, signedAssertion ANY DEFINED BY signedAssertionID OPTIONAL }。単一のAssertionのデータ構造は以下の通りです: A2 30 30 06。
`CMSEncodeOIDFromString` (v2.120.1) を再利用して、アサーション OID のエンコードを行います。ドット表記の OID はすべて有効です。
4つの引数を持つ `HPDFCMSBuildSignedData` ラッパーは、新しいフィールドをゼロに設定し、これにより、古い CMS バンドルがバイト単位で同一のままになります。
signer-attributes-v2 收口: all three OPTIONAL fields ([0] claimedAttributes, [1] certifiedAttributesV2, [2] signedAssertions) now wired through Phases 5/6/7. Full ETSI EN 319 122-1 §5.2.6 attribute coverage from the PAdES producer side.
ETSI EN 319 122-1 V1.2.1 第 5.2.6 节，以及附录 A.1。

2026-05-23 Version 2.120.5

PAdES signer-attributes-v2 certifiedAttributesV2 [1] ブランチ (PAdES Phase 6): X.509 属性証明書 (RFC 5755) を、SignerAttributeV2 シーケンス内に、 v2.120.4 の claimedAttributes [0] と並行して、またはその代わりに出力します。これにより、署名者は、属性認証機関 (Attribute Authority) が発行した、主張されている身元/能力を暗号的に裏付ける証明書を添付できます。
新しい `THPDFCMSSignOptions` フィールドを追加しました。 `CertifiedAttributeCertsDER: TBytes の配列`。各要素は、発行元 AA から呼び出し元が受け取った、完全な DER 形式エンコードされた `AttributeCertificate` (RFC 5755) です。HotPDF は、これらの値を変更せずに、 `[1] EXPLICIT` (タグ `0xA1`) でラップされた `CertifiedAttributesV2 SEQUENCE OF` に出力します。
signer-attributes-v2 属性现在会在以下情况下生成：当 `ClaimedRoles` 或 `CertifiedAttributeCertsDER` 至少有一个非空时。如果两者都包含内容，则会生成一个 `SignerAttributeV2` 序列，其中包含 `[0]` + `[1]`，以匹配规范中的顺序。
ASN.1 DER 形式 (仅限 `CertifiedAttributesV2`): A1 30 ，其中每个 ACn 是由调用方提供的，完全符合 RFC 5755 中定义的 AttributeCertificate SEQUENCE。 AttributeCertificate 和 OtherAttributeCertificate 之间的选择由调用方提供的 DER 输入来确定（两种情况都以 SEQUENCE 0x30 标签开头；HotPDF 不会进行内部检查）。
`HPDFCMSBuildSignedData` 包装器的 4 个参数版本将新字段设置为零，以便旧版 CMS 捆绑包与 v2.119.27 版本保持字节完全一致。
Scope: signedAssertions [2] (SAML / JWT / 任意のOIDトークン) の対応は未完了であり、次フェーズで実装されます。
ETSI EN 319 122-1 V1.2.1 第 5.2.6 节 + 附录 A.1 + RFC 5755。

2026-05-23 Version 2.120.4

PAdES **signer-attributes-v2** CMS 签名属性（PAdES 第 5 阶段）：发出 id-aa-ets-signerAttrV2（OID 0.4.0.19122.1.1，ETSI EN 319 122-1 §5.2.6），允许签名者在 CMS 捆绑包中声明其角色（例如“首席财务官”、“授权代表”）。此功能取代了已弃用的 v1 signerAttr（RFC 5126 §5.10），适用于新的签名。
新しい `THPDFClaimedRole` レコード： `RoleOID` (属性タイプの OID、ドット表記で記述され、通常は組織の役割の OID、または `1.3.6.1.5.5.7.20.1 id-id-aa-PERMrole` のような ID) + `RoleValue` (UTF-8 文字列で、人間が読める役割のラベルを格納)。
新しい `THPDFCMSSignOptions` フィールドを追加しました。 `ClaimedRoles`: `THPDFClaimedRole` の配列。複数のロールをサポートしており、それぞれが `claimedAttributes [0]` のシーケンス内の 1 つの `Attribute` になります。空の配列 (デフォルト) は、この属性を抑制し、v2.120.3 でのバイトレベルの安定性を、オプトインしなかった呼び出し元に対して維持します。
ASN.1 DER 形式，符合 ETSI EN 319 122-1 §5.2.6 + 附录 A.1 (模块，`DEFINITIONS EXPLICIT TAGS`): `SignerAttributeV2 SEQUENCE { [0] EXPLICIT ClaimedAttributes }`，其中 `ClaimedAttributes ::= SEQUENCE OF Attribute`。每个角色都序列化为 `Attribute { type OID, values SET OF UTF8String}`。 `EXPLICIT` 标签意味着 `0xA0` 完整地包含内部的 `SEQUENCE OF` (内部的 `0x30` 标签会被保留)。
OID 本体は手動でエンコードされています。 04 00 81 95 32 01 01 (arc 0.4.0.19122.1.1; base-128 継続: 19122 → 0x81 0x95 0x32)。将来的には、v2.120.1 以降で提供される CMSEncodeOIDFromString を使用して、カスタム値を設定できます。
**対象範囲:** 該当機能のみ。 `claimedAttributes [0]` は、このフェーズで実装されます。 `certifiedAttributesV2 [1]` (RFC 5755 に基づく X.509 属性証明書) および `signedAssertions [2]` (SAML / JWT スタイルのトークン) は、追加の機能が必要であり、具体的な要求があるまで対象外とします。
4引数の `HPDFCMSBuildSignedData` ラッパーがゼロに設定されます。 `ClaimedRoles` の長さが調整されるため、古い CMS バンドルが v2.119.27 と同じバイト構成になります。
ETSI EN 319 122-1 V1.2.1 §5.2.6 および EN 319 142-1 V1.2.1 §6.3 表1 の行 "signer-attributes-v2" (オプション、0または1)。

2026-05-23 Version 2.120.3

PAdES **signature-time-stamp** CMS 署名時のタイムスタンプ属性 (PAdES Phase 4): 発行します。 id-aa-signatureTimeStampToken (OID 1.2.840.113549.1.9.16.2.14, RFC 3161 §6 + ETSI EN 319 122-1 §5.3) を、SignerInfo の [1] IMPLICIT unsignedAttrs SET 内に配置します。これにより、PAdES-B-T の信頼されたタイムスタンプサービスのための **signature-time-stamp** パスが提供されます (表 1: B-T は、 signature-time-stamp または document-time-stamp を使用して提供される必要があります)。
新しい `THPDFCMSTimestampCallback` 匿名メソッド型：`reference to function(const SigValueSHA256: TBytes): TBytes`。HotPDFはこのコールバックを、`SignerInfo.signatureValue` のSHA-256ハッシュ値（RFC 3161の§2.4.2で定義された`messageImprint`）と共に呼び出し、返されたTimeStampTokenのDERエンコードを属性値として埋め込みます。
新しい `THPDFCMSSignOptions` フィールドを追加しました。 `GetSignatureTimeStamp`。デフォルトは `nil` です。これは、タイムスタンプがないことを意味します。PAdES-B-T を呼び出す場合は、TSA (Timestamping Authority) との HTTP/RFC 3161 連携を制御し、TST バイトを返すクロージャを割り当てます。空の TBytes を返した場合、エラーなしでスキップされます (たとえば、TSA にアクセスできない場合でも、署名は引き続き生成されます)。
ネットワーク、認証、およびTSAアカウントの処理仍然在调用代码中；HotPDF仅将结果传递到unsignedAttrs。这与现有的AddPAdESSignatureField(Profile='B-T', ContentsBytes >= 16384)占位符大小设置相匹配。
ASN.1 形式：`SignerInfo` 序列现在可以选择性地包含一个尾部 `[1] IMPLICIT SET OF Attribute` (标签 `0xA1`)，该尾部包含一个 `signature-time-stamp` 属性，其值为调用者提供的 `TimeStampToken ContentInfo` 的精确副本。
4引数の `HPDFCMSBuildSignedData` ラッパーを設定することで、 `GetSignatureTimeStamp` を `nil` に設定し、レガシー CMS バンドルがバイト単位で同一のままになるようにします。
RFC 3161 §6 および ETSI EN 319 122-1 §5.3 および EN 319 142-1 に準拠。 V1.2.1 §6.3 表1 の注釈 q (B-T は、信頼できる時間のために、署名時刻またはドキュメント時刻のいずれかを使用できます)。

2026-05-23 Version 2.120.2

PAdES commitment-type-indication CMS SignedAttribute のサポート (PAdES Phase 3): id-aa-ets-commitmentType 属性 (OID 1.2.840.113549.1.9.16.2.16, ETSI EN 319 122-1 §5.2.3 + RFC 5126 §5.11) を発行し、署名者が署名を通じて行うコミットメントの種類を宣言します (例: 起源の証明 / 受領 / 配信 / 送信者 / 承認 / 作成)。
新しい `THPDFCommitmentType` 列挙型を追加しました。 `ctNone` (デフォルト値で、この属性を抑制します)、 `ctProofOfOrigin`、`ctProofOfReceipt`、 `ctProofOfDelivery`、`ctProofOfSender`、 `ctProofOfApproval`、`ctProofOfCreation` (RFC 5126 §5.11.1 に記載されている、標準的な `id-cti-ets-*` OID 6 つ: `1.2.840.113549.1.9.16.6.{1..6}`)、および `ctCustom` (呼び出し元が新しい `CommitmentTypeOID` フィールドを通じて、任意の OID を指定します)。
変更点： `THPDFCMSSignOptions.CommitmentType` が `ctNone` でない場合に、常に発生します。デフォルト値が空であることで、v2.120.1 で、opt-in しなかった呼び出し元に対して、バイトレベルでの安定性を維持します。
**调用者的责任 (PAdES 第 1 部分 §6.3 表 1 备注 d)**：当发出承诺类型指示时，签名字典中的 `Reason` 字段必须不存在（互斥）。HPDFCMS 不会观察签名字典的状态，调用者可以通过 `AddPAdESSignatureField(Reason='', ...)` 加上 `CommitmentType`，或者通过将 `CommitmentType` 设置为 `ctNone` 并提供 `Reason` 来选择其中一种方式。
ASN.1 DER 構造: CommitmentTypeIndication SEQUENCE { commitmentTypeId OBJECT IDENTIFIER }。CommitmentTypeQualifier (RFC 5126 §5.11.2) は、6つの標準 id-cti-ets-* OID がクオリファイアを定義していないため、省略されます。クオリファイアを必要とするカスタムコミットメントは、ヘルパー機能を拡張できます。
`HPDFCMSBuildSignedData` 包装器的 4 个参数将新的 `CommitmentType` 字段设置为零，以便旧版 CMS 捆绑包与 v2.119.27 版本保持字节相同。
CRITICAL RULES — preserve verbatim, do NOT translate: - HTML tags: , , , , ,
, , ,
,

, etc. - HTML entities: ", &, <, >, , etc. - API names / identifiers: THotPDF, GetSingleSubstituteGlyph, TextOut, AddXFAPacket, RegisterUnicodeTTF, THPDFPage, AddTextField, RegisterSampledFunction, THPDFDictionaryObject, THPDFStreamObject, AddImageWithSMask, ShowImage, etc. - PDF spec references: "PDF 1.7 §12.7.6", "ISO 32000-1 8.9.5.4", "ISO 19005-1 §6.4.2", "UAX #38", "Unicode 16.0 §13.5", "ISO 14289-1", etc. - OpenType feature tags (single-quoted): 'liga', 'salt', 'aalt', 'init', 'medi', 'fina', 'isol', 'mong', 'arab', 'rlig', 'syrc', 'pres', 'cjct', 'akhn', 'rclt', 'clig', 'calt'. - Unicode block names / font names / codepoints: Arabic Extended-A, Mongolian Baiti, Noto Sans Mongolian, Devanagari, U+1800-U+18AF, U+0671, NIRUGU, LAM-ALEF, Estrangelo Edessa, Identity-H, etc. - PDF object names: /Fields, /XFA, /Filter, /WMode, /AcroForm, /Length, /MarkInfo, /StructTreeRoot, /Metadata, /Lang, /AP, /RV, /V, /DV, /DR, /MK, /AA, /SMask, /AIS, /BG, /UCR, /OP, /OPM, /SA, /RI, /FL, /TR, /CIDToGIDMap, /FontFile2, /W, /Encoding, /Default, /None, /SpotFunction, /Type, /ObjStm, etc. - Version numbers: v2.119.54, v2.84.0, v2.119.43-50, v2.55.0-v2.59.0, etc. - PDF operators: Tj, Tm, Td, T*, TL, Tf, BDC, EMC, scn, SCN. - Hex / numeric constants: $7FF8000000000000, 0x0002, U+FE70..U+FEFF, etc. - File / encoding names: CCITTFaxDecode, FlateDecode, UTF-16BE, DeviceGray, DeviceRGB, DeviceCMYK, Identity-H. Translate ONLY the descriptive English prose (verbs, adjectives, narrative sentences). Return ONLY the translation — no explanations, no markdown wrappers, no "[[N]]" tags, no leading/trailing whitespace, no extra newlines beyond what was in the input. TEXT: Per ETSI EN 319 122-1 §5.2.3 + RFC 5126 §5.11 + ETSI EN 319 142-1 V1.2.1 §6.3 Table 1 note d. この変更は、ETSI EN 319 122-1 の §5.2.3、RFC 5126 の §5.11、および ETSI EN 319 142-1 V1.2.1 の §6.3 の表 1 の注釈 d に基づいています。

2026-05-23 Version 2.120.1

PAdES signature-policy-identifier CMS SignedAttribute のサポート (PAdES Phase 2): id-aa-ets-sigPolicyId 属性 (OID 1.2.840.113549.1.9.16.2.15, ETSI EN 319 122-1 §5.2.9 + RFC 5126 §5.8) を出力し、この属性は、生成された署名に関連する署名ポリシーを宣言します。これは、PAdES-E-EPES (Part 2 V1.2.1 §5.4 表 2: 必須) で必須であり、他のすべての PAdES レベルではオプションです。

新しい `THPDFCMSSignOptions` レコードフィールド： `SignaturePolicyOID` (ポリシー文書のドット付きOID文字列)、`SignaturePolicyHash` (ポリシー文書のハッシュ値)、`SignaturePolicyHashAlgOID` (ハッシュアルゴリズムのOID。空の場合はSHA-256がデフォルト)、および `SignaturePolicyURI` (オプションのSPuri修飾子。RFC 5126 §5.8.1、OID `1.2.840.113549.1.9.16.5.1`、ポリシー文書のURLを指す)。

変更点： Activation: ポリシー属性は、呼び出し元によって `SignaturePolicyOID` と `SignaturePolicyHash` の両方が設定されている場合にのみ出力されます。デフォルト値が空の場合、この属性は抑制されます。これにより、ベースラインの署名者は v2.120.0 の出力でバイトレベルでの安定性を維持します。

新しいヘルパー関数 `CMSEncodeOIDFromString` は、任意のドット表記の OID を、X.690 §8.19 に従って DER 形式でエンコードします（最初の 2 つの弧は `40*arc1 + arc2` として結合され、その後の弧は 128 進数で、継続ビットを使用します）。ポリシー OID は、ビジネス固有の情報であるため、プロデューサーはそれをバイトリテラルとしてハードコードできません。

ASN.1 DER 構造： SignaturePolicyId SEQUENCE { sigPolicyId OBJECT IDENTIFIER, sigPolicyHash OtherHashAlgAndValue [, sigPolicyQualifiers SEQUENCE OF SigPolicyQualifierInfo] }。 SPuri 修饰符将 URL 作为 IA5String（标签 0x16）包含在 SigPolicyQualifierInfo 中。

互換性：v2.120.0 版本中，如果调用者没有填充新的策略字段，则输出结果与之前的版本完全相同。`HPDFCMSBuildSignedData` 包装器中的 4 个参数版本会将新的字段设置为零，以确保旧的 CMS 捆绑包保持不变。

ETSI EN 319 122-1 §5.2.9 および ETSI EN 319 142-2 V1.2.1 §5.4 に準拠。表 2 および RFC 5126 §5.8 にも準拠。

2026-05-23 Version 2.120.0

PAdES基本CMS属性合规性（PAdES阶段1）： SignPDFWithPFX现在默认输出 ESS signing-certificate-v2 签名属性（RFC 5035 / OID 1.2.840.113549.1.9.16.2.47），从而保护签名证书身份，防止替换攻击。ETSI EN 319 142-1 V1.2.1 §6.3 表1将此列为 必须提供，适用于所有基本级别（B-B / B-T / B-LT / B-LTA）。

PAdESの基本設定において、CMSの`signing-time`属性がデフォルトで省略されるようになりました。表1では、基本プロファイルにおいてこの属性の出現回数は0と規定されています（署名時間に関する情報は、表1の注記gに従って、Signature Dictionaryの`/M`エントリに格納されます）。以前のv2.119.27では、プロファイルに関わらず`signing-time`属性が含まれていましたが、厳格なPAdES検証ツール（EU DSS、Adobe AcrobatのPAdES基本設定モード）では、この属性があるとエラーとなります。

新しい公開API：`THPDFPAdESLevel`列挙型（8つの値、ベースラインB-B / B-T / B-LT / B-LTA、拡張E-BES / E-EPES / E-LTV、およびレガシー`adbe.pkcs7`）、`THPDFCMSSignOptions`レコード（レベル、署名時間、署名証明書v2の切り替え、UTCタイムスタンプ）、レベルごとに仕様に準拠したデフォルト値を返すヘルパー関数`HPDFCMSDefaultOptions(Level)`、およびオプション駆動型のCMSビルダー`HPDFCMSBuildSignedDataEx`。

互換性：v2.119.27版本的四参数 HPDFCMSBuildSignedData 签名被保留为一个轻量级包装，并输出与原始数据完全相同的字节（缺少 signing-cert-v2 ，signingTime 按照要求）。在测试中，如果调用者对 v2.119.27 CMS 捆绑包进行了哈希处理，则测试结果仍然通过。

THotPDF.SignPDFWithPFX を使用して PAdES プレースホルダーに署名する場合、以下の変更点があります。以前は、厳格な PAdES の基準を満たしていなかった署名が生成されることがありましたが、現在は、すべての呼び出しで、厳格な PAdES の基準を満たす署名が生成されるようになりました。 v2.119.27 のレガシー属性セットを使用したい場合は、HPDFCMSDefaultOptions(palLegacy_adbePkcs7) を使用して HPDFCMSBuildSignedDataEx を直接呼び出してください。

ASN.1 DER 構造は RFC 5035 §3 に準拠します。 SigningCertificateV2 SEQUENCE { certs SEQUENCE OF ESSCertIDv2 } には、SHA-256 アルゴリズム識別子が含まれます。 SHA-256 証明書ハッシュは省略され (X.690 §11.5 のデフォルト値 DER ルール)、IssuerSerial は、既存の CMSExtractIssuerAndSerial から抽出される X.509 発行者 + シリアル番号を再利用します。

ETSI EN 319 142-1 V1.2.1 第6.3条表1，以及 RFC 5035 第3条。

2026-05-23 Version 2.119.77

シンハラ語の整形機能が追加されました（フェーズ8f.8）。シンハラ語（'sinh'、U+0D80-U+0DFF）が、8番目に登録されたインド・アーリア文字体系となりました。新しいApplySinhalaReorderおよびGetSinhalaCategoryメソッドがTHotPDFに追加されました。

シンハラ語の機能：Repha をサポート (Ra=U+0DBB + Halant=U+0DCA AL-LAKUNA)。 3つのプレベース・マトラ (E=U+0DD9, EE=U+0DDA, AI=U+0DDB) を持つ — これは、3つのプレベース・マトラを持つという点で独特です。3つの分割マトラ (U+0DDC O, U+0DDD OO, U+0DDE AU) は、標準 Unicode 分解を使用します。 U+0DDD OO は、3つの部分 (E + AA + AL-LAKUNA) で構成されています。

`ApplyIndicReorder` 调度器现在可以无缝地处理僧伽罗语（IndicScripts 注册表现在是 array[0..7]）。

21つの新しいDUnitXテストが追加されました。合計187個のテストのうち、Win32およびWin64環境で187個がすべて合格しました。

Unicode 16.0 §12.11 (僧伽罗语) および OpenType 僧伽罗语字形规范。

2026-05-23 Version 2.119.76

マラーヤーラム語の整形機能が追加されました（フェーズ8f.7）。マラーヤーラム語（'mlym'、U+0D00-U+0D7F）は、7番目に登録されたインド脚本です。新しいApplyMalayalamReorderおよびGetMalayalamCategoryメソッドがTHotPDFに追加されました。

マラーラーム語の機能：Repha（Ra=U+0D30 + Halant=U+0D4D、CHANDRAKKALA）があります。I-matra（U+0D3F）は、タミル語のように後置ベースであり（デヴァナガリー/ベンガル語/グジャラート語の前置ベースとは異なります）。E/EE/AIの前置ベースがあります。3つの分割マトラ（U+0D4A O / U+0D4B OO / U+0D4C AU）があり、標準的な前置+後置分解を使用します。chillu文字（U+0D54-U+0D56、U+0D7A-U+0D7F）とDOT REPH（U+0D4E）は、子音として分類されます。

`ApplyIndicReorder` ディスパッチャがマラヤーラム語をサポートし、これにより、IndicScripts レジストリが配列[0..6]として機能するようになりました。

CRITICAL RULES — preserve verbatim, do NOT translate: - HTML tags: , , , , ,
, , ,
,
, etc. - HTML entities: ", &, <, >, , etc. - API names / identifiers: THotPDF, GetSingleSubstituteGlyph, TextOut, AddXFAPacket, RegisterUnicodeTTF, THPDFPage, AddTextField, RegisterSampledFunction, THPDFDictionaryObject, THPDFStreamObject, AddImageWithSMask, ShowImage, etc. - PDF spec references: "PDF 1.7 §12.7.6", "ISO 32000-1 8.9.5.4", "ISO 19005-1 §6.4.2", "UAX #38", "Unicode 16.0 §13.5", "ISO 14289-1", etc. - OpenType feature tags (single-quoted): 'liga', 'salt', 'aalt', 'init', 'medi', 'fina', 'isol', 'mong', 'arab', 'rlig', 'syrc', 'pres', 'cjct', 'akhn', 'rclt', 'clig', 'calt'. - Unicode block names / font names / codepoints: Arabic Extended-A, Mongolian Baiti, Noto Sans Mongolian, Devanagari, U+1800-U+18AF, U+0671, NIRUGU, LAM-ALEF, Estrangelo Edessa, Identity-H, etc. - PDF object names: /Fields, /XFA, /Filter, /WMode, /AcroForm, /Length, /MarkInfo, /StructTreeRoot, /Metadata, /Lang, /AP, /RV, /V, /DV, /DR, /MK, /AA, /SMask, /AIS, /BG, /UCR, /OP, /OPM, /SA, /RI, /FL, /TR, /CIDToGIDMap, /FontFile2, /W, /Encoding, /Default, /None, /SpotFunction, /Type, /ObjStm, etc. - Version numbers: v2.119.54, v2.84.0, v2.119.43-50, v2.55.0-v2.59.0, etc. - PDF operators: Tj, Tm, Td, T*, TL, Tf, BDC, EMC, scn, SCN. - Hex / numeric constants: $7FF8000000000000, 0x0002, U+FE70..U+FEFF, etc. - File / encoding names: CCITTFaxDecode, FlateDecode, UTF-16BE, DeviceGray, DeviceRGB, DeviceCMYK, Identity-H. Translate ONLY the descriptive English prose (verbs, adjectives, narrative sentences). Return ONLY the translation — no explanations, no markdown wrappers, no "[[N]]" tags, no leading/trailing whitespace, no extra newlines beyond what was in the input. TEXT: 21 new DUnitX tests including chillu/DOT-REPH category coverage. Total 166/166 tests pass on Win32 + Win64. 新しいDUnitXテストが21個追加され、chillu/DOT-REPHカテゴリのテストも含まれています。合計166個のテストのうち、Win32およびWin64環境で166個がすべて合格しました。
Unicode 16.0 §12.10（马拉雅拉姆语）およびOpenType马拉雅拉姆语字形规范。

2026-05-23 Version 2.119.75

カンナダ語の整形機能が追加されました（GSUBエンジンのロードマップ、フェーズ8f.6）。カンナダ語（'knda'、U+0C80-U+0CFF）は、登録された6番目のインド脚本です。新しい公開メソッドであるApplyKannadaReorderとGetKannadaCategoryが、THotPDFに追加されました。

カンナダ語には、デーヴァナガリー文字やベンガル語、グジャラート語、テルグ語と同様のRepha（Ra=U+0CB0 + Halant=U+0CCD）があります。テルグ語と同様に、カンナダ語には基本文字の上に付く母音記号（matra）はありません。カンナダ語のすべての母音記号は、基本文字の上、下、または分割された形をとります。

Unicode 16.0 规范分解将 5 个音节符号拆分： U+0CC0 II → U+0CBF (上) + U+0CD5 (后); U+0CC7 EE → U+0CC6 (上) + U+0CD5 (后); U+0CC8 AI → U+0CC6 + U+0CD6 (都上); U+0CCA O → U+0CC6 (上) + U+0CC2 (后); **U+0CCB OO 是三部分：** U+0CC6 (上) + U+0CC2 (后) + U+0CD5 (后) — 前三部分由 Phase 8f 字体塑造引擎处理。

上基音標（R3）：I（U+0CBF）、E（U+0CC6）、AU（U+0CCC）、AI長音標（U+0CD6）。下基音標（R4）：元音R/RR（U+0CC3-U+0CC4）、元音L/LL音標（U+0CE2-U+0CE3）。基音標（R5）：AA（U+0CBE）、U/UU（U+0CC1-U+0CC2）、基長音標（U+0CD5）。

`ApplyIndicReorder` 调度器可以透明地选择卡纳达语，该选择现在通过注册表（现在是 array[0..5]）进行。

テスト：21個の新しいDUnitXテストケースを追加しました。これには、5つの分割マトラケースと、専用の3つのOO検証が含まれます。合計145個のテストのうち、Win32およびWin64環境で145個がすべて合格しました。

Unicode 16.0 §12.9（卡纳达语）およびOpenType卡纳达语字形规范。

2026-05-23 Version 2.119.74

Telugu文字整形機能を追加しました（GSUBエンジンロードマップのフェーズ8f.5）。Telugu（'telu'、U+0C00-U+0C7F）は、5番目の登録されたインド文字体系となりました。`THotPDF`クラスに、新しい公開メソッドである`ApplyTeluguReorder`と`GetTeluguCategory`を追加しました。

Telugu 语言具有类似于 Devanagari、Bengali 和 Gujarati 的 Repha (Ra=U+0C30 + Halant=U+0C4D) 特性。与所有之前的 Indic 语种文字不同：没有前缀基元附加符号，每个 Telugu 语种的附加符号都是位于基元之上、基元之下或分割的。

上記の基本文字に付加される記号（R3）：AA、I、II、E、EE、O、OO、AU、および長音記号。 U+0C55。基本文字より下の記号（R4）：U、UU、母音付きR、RR（U+0C41-U+0C44）、 AIの長音記号（U+0C56）、母音付きL/LLの記号（U+0C62-U+0C63）。

U+0C48 AI 分解为 U+0C46 (E 在底线上) + U+0C56 (AI 长度标记在底线下方)，在重新排序过程中。

`ApplyIndicReorder` 调度器，无需用户干预，即可通过注册表（现在是 array[0..4]）自动选择 Telugu 字体。

テスト：17個の新しいDUnitXテストケースを追加しました。合計124個のテストのうち、Win32およびWin64で124個がすべて合格しました。

Unicode 16.0 §12.8（泰卢固语）およびOpenType泰卢固语字形规范。

2026-05-23 Version 2.119.73

タミル文字整形機能を追加しました（GSUBエンジンロードマップのフェーズ8f.4）。タミル文字（'taml'、U+0B80-U+0BFF）は、4番目の登録されたインド文字体系となりました。THotPDFクラスに、新しい公開メソッドであるApplyTamilReorderとGetTamilCategoryを追加しました。

タミル文字が他のバラモン文字系から異なる点：Rephaは使用されません（タミル文字では伝統的にRephaの視覚的な表現は形成されません）。I-matra（U+0BBF）は、他のバラモン文字系では見られない、文字の基部後に配置されます。II（U+0BC0）は、文字の基部の上に配置されます。E/EE/AI（U+0BC6-U+0BC8）は、文字の基部前に配置されます。3種類の分割されたmatraがあります（U+0BCA O = U+0BC6+U+0BBE、U+0BCB OO = U+0BC7+U+0BBE、U+0BCC AU = U+0BC6+U+0BD7）。

Halant 在 U+0BCD 处名为 PULLI，在泰米尔语中。`ApplyIndicReorder` 调度器通过注册表（现在是 array[0..3]）透明地选择泰米尔语。

テスト：20個の新しいDUnitXテストケースを追加しました。合計107個のテストのうち、Win32およびWin64環境で107個のテストがすべて合格しました。

Unicode 16.0 §12.7（タミル語）およびOpenTypeタミル語整形仕様に準拠。

2026-05-23 Version 2.119.72

グジャラート語の整形機能が追加されました（GSUBエンジンのロードマップ、フェーズ8f.3）。グジャラート語（'gujr'、U+0A80-U+0AFF）は、デーヴァナーガリー文字とベンガル文字に続いて、3番目に登録されたインド文字になります。新しい公開メソッドであるApplyGujaratiReorderとGetGujaratiCategoryが、THotPDFに追加されました。

ルールを以下のように変更しました。R1: Repha (Ra=U+0AB0 + Halant=U+0ACD)。R2: プレベース (U+0ABF I)。R3: 上ベース (U+0AC5 CANDRA E, U+0AC7 E, U+0AC8 AI)。注意: グジャラート語の上ベースは、ベンガル語のようなプレベースではありません。R4: 下ベース (U+0AC1-U+0AC4, U+0AE2-U+0AE3)。R5: ポストベース (U+0ABE AA, U+0AC0 II, U+0AC9 CANDRA O, U+0ACB-U+0ACC O/AU)。分割されたマトラは使用しません。

`ApplyIndicReorder` 调度器透明地通过 `IndicScripts` 注册表（现在是 array[0..2]）选择古吉拉特语。`BuildUnicode*FieldContent` 集成站点与 `sfIndicShaping` 配合使用，可以使古吉拉特语在零集成更改的情况下得到支持。

テスト：R3のベースを超える18個の新しいDUnitXテストケースを追加し、グジャラート語のE/AIの処理とベンガル語の違いを区別します。合計87個のテストのうち、87個がWin32およびWin64でパスしました。

Unicode 16.0 §12.6（グジャラート語）およびOpenTypeグジャラート語整形仕様に準拠。

2026-05-23 Version 2.119.71

ベンガル語の整形機能が追加されました（GSUBエンジンロードマップのフェーズ8f.2）。ベンガル語（'beng'、U+0980-U+09FF）は、デーヴァナーガリーに次いで、サポートされる2番目のインド系文字体系となります。新しい公開メソッドであるApplyBengaliReorderとGetBengaliCategoryが、THotPDFに追加されました。これらは、フェーズ8eで導入されたデーヴァナーガリーAPIと同様の機能を提供します。

ベンガル語の文字再配置ルール：R1 は Repha (Ra=U+09B0 + Halant=U+09CD)、R2 は母音記号の基本形 (I=U+09BF, E=U+09C7, AI=U+09C8 — 注意：ベンガル語では E/AI が、上記のデーヴァナガリーとは異なり、基本形に配置されます)、R4 は下基本形 (U+09C1-U+09C4, U+09E2-U+09E3)、R5 は後置基本形 (U+09BE, U+09C0, U+09D7)。ベンガル語の主要ブロックには、上基本形の母音記号はありません。

分割母音分解：`U+09CB` Oo 和 `U+09CC` AU 在重新排序过程中会扩展为其视觉组件（U+09C7 + U+09BE / U+09C7 + U+09D7），因此 GSUB 管道能够以规范的前置+后置位置识别它们。

`ApplyIndicReorder` 调度器透明地将孟加拉语代码点路由到孟加拉语条目；`BuildUnicode*FieldContent` 辅助函数，现在在 `sfIndicShaping` 设置的情况下，同时支持孟加拉语和德文脚本，而无需进行任何集成更改。

テスト：ベンガル語R1/R2/R4/R5、分解、結合文字の保持、異なる文字体系の混在、冪等性、ディスパッチャの同等性に関する18個の新しいDUnitXテストケースを追加しました。合計69個のテストのうち、Win32およびWin64環境で69個すべてが合格しました。

Unicode 16.0 §12.2（ベンガル語）およびOpenTypeベンガル語整形仕様に準拠。

2026-05-23 Version 2.119.70

Devanagari文字の完全な整形機能のアップグレード（GSUBエンジンロードマップのフェーズ8f.1）： ApplyDevanagariReorderは、v2.119.55で提供されていたR1とR2のみのサブセットではなく、5つのルール（R1 Repha + R2 pre-base + R3 above-base + R4 below-base + R5 post-base）をすべて適用するようになりました。出力の文字クラスターの順序は、音節ごとに[pre-matras] + [base + halant + nukta + bindu/visarga/modifier] + [above-matras] + [below-matras] + [post-matras] + [Repha]となります。

子音-結合符-子音の組み合わせは、ベースブロック内でグループ化されたまま維持されます。再配置は、マトラとRephaのみを対象とします。単一パスで、멱等性があります。

v2.119.69版本行为变更：对于包含上/下/基元音符号（或多重元音符号组合）的音节，PDF字节流现在反映了规范的重排序布局。GSUB/GPOS处理后的视觉渲染没有变化。仅包含R1 Repha或R2前置I-matra（v2.119.55版本）的输入，输出字节完全相同。

テスト: R3、R4、R5を個別にテストする8つの新しいDUnitXテストケースを追加しました。また、複数のマトラの順序、マトラ下での結合文字の保持、Repha文字の上付きおよび後置文字の組み合わせ、および複数のマトラにおける冪等性もテストしました。合計51個のテストのうち、Win32およびWin64環境で51個すべてが合格しました。

Unicode 16.0 §12.1 (Devanagari) および OpenType Devanagari 書体仕様に準拠。

2026-05-23 Version 2.119.69

インダス文字整形基盤（GSUBエンジンロードマップ第8f.0）：v2.119.55 / v2.119.67のデバナガリー文字並べ替え前処理を、スクリプトに依存しないディスパッチフレームワークにリファクタリングしました。新しい型`TIndicScriptInfo`、`TIndicCategoryFunc`、`TIndicFindSyllableFunc`、`TIndicReorderFunc`と、新しい`IndicScripts`レジスタにより、今後のインダス文字が関数ポインタを介して統合できるようになりました。

新しい公開メソッド `ApplyIndicReorder(Wide)` 将 `Wide` 中的每个码点分发到其对应的已注册脚本，并应用该脚本的音节重排序回调。非 Indic 内容将按字节原样传递。

`BuildUnicode*FieldContent` 辅助函数现在调用 `ApplyIndicReorder`（而不是仅适用于 Devanagari 的包装器），当 `sfIndicShaping` 位于 `FShapingFeatures` 中时。 8f.0 版本仅支持 Devanagari；后续版本 8f.2 到 8f.10 增加了孟加拉语、古吉拉特语、泰米尔语、泰卢固语、卡纳达语、马拉雅拉姆语、僧伽罗语、高棉语和缅甸语，但没有更改此集成点。

既存の`ApplyDevanagariReorder`は、v2.119.55との互換性を維持するために、Devanagari文字のみを対象とするラッパーとして引き続き利用されます。出力はv2.119.67から変更ありません。

Unicode 16.0 §12（南亚文字）およびISO 32000-1 §9.10に従って。

2026-05-22 Version 2.119.68

第8c.6段階：通过私有使用区域的合成码点映射，在生成器端实现GID级别的输出。THotPDF类添加了两个新的公共方法，允许调用者输出没有自然Unicode码点的替代GID，方法是根据需要分配合成PUA（U+E000-U+F8FF）码点。AssignSyntheticCodepointForGID (GID; out SyntheticCP): Boolean方法分配下一个可用的PUA槽，并将分配结果同步到FUnicodeCpToGid、FAcroFormUnicodeAdvances以及一个新的FUnicodeSyntheticCpForGID表，以便现有的生成器端的十六进制编码管道将合成码点作为4个十六进制数字的标记输出，消费者读取器通过/CIDToGIDMap将其解析为替代字形。GetSyntheticCodepointForGID (GID): Word方法查询已有的分配（如果未分配则返回0）。这两个方法都是幂等的，这意味着对相同GID的重复调用将返回相同的合成码点。

フォント固有のGSUB置換において、Unicodeプレゼンテーションフォームのコードポイントを持たない場合に、プロデューサー側でのエミッションが可能になります。具体的には、デバナガリーのクラスター形状（Indicの'akhn' / 'rphf' / 'pres' / 'blws' / 'psts' / 'haln'出力は、通常、フォント内部のGIDに配置されます）、スタイル代替（コードポイントを持たない'salt' / 'ss01-20'置換）、任意のリガチャ（'dlig' / 'hlig'というフォント固有のグリフ）、およびCJKの字形バリエーションシーケンス置換が含まれます。v2.119.43-50のGSUBエンジンAPIと、v2.119.50のMarkUnicodeGlyphUsedサブセッターの機能により、呼び出し元は、既存のコードポイントベースの16進数パイプラインを通じて、任意の置換GIDをエミットする、完全なプロデューサー側のシェーピングパイプラインを構築できるようになりました。

フォントの状態は、RegisterUnicodeTTFが再度呼び出されるか、BeginDocが実行されるまで保持されます（これらはどちらも、合成テーブルを含む、フォントごとのすべての状態をリセットします）。PUA範囲U+E000-U+F8FFは6400のスロットを提供し、どのフォントのGSUB置換セットにも十分です。ToUnicode CMapの逆マッピングは、呼び出し元の責任です。合成PUAコードポイントには、逆マッピングするためのソースコードポイントがないため、テキスト抽出を懸念する呼び出し元は、PDFのマークアップコンテンツでテキストを生成する際に、元のソースコードポイントを指定する/ActualTextプロパティでラップする必要があります。AssignSyntheticCodepointForGIDを呼び出さない場合、生成されるPDFはv2.119.67と同じバイト列になります（新しいメソッドはステートレスなクエリであり、明示的な割り当てを支援するものであり、自動的な副作用はありません）。このコミットにより、GSUBエンジンのロードマップの第8フェーズの機能が完了します。

2026-05-22 Version 2.119.67

Devanagari文字の並べ替えの事前処理が、自動的に適用されるようになりました（GSUBエンジンのロードマップ、フェーズ8e）。「BuildUnicode*FieldContent」の3つのヘルパー関数は、FShapingFeaturesにsfIndicShapingが含まれている場合に、v2.119.55のApplyDevanagariReorderメソッドを自動的に呼び出します。この事前処理では、入力文字列を左から右へ順に処理し、Devanagari文字に特有の2つの並べ替え（音節の先頭にあるRa-Halantの移動、およびU+093FのI-matraを音節の先頭に移動）を適用します。これにより、出力される文字コードの順序が、視覚的に読み取れる順序と一致します。その後、読み取り側のGSUBエンジンは、並べ替えられた文字コードに対して、Indicの整形チェーン（'nukt' / 'akhn' / 'rphf' / 'rkrf' / 'pref' / 'half' / 'vatu' / 'cjct' / 'pres' / 'blws' / 'abvs' / 'psts' / 'haln'）を適用し、最終的な文字グループを生成します。

変更内容は、プロデューサー側のリオーダー機能のみを提供します。プロデューサー側のGSUBチェーン適用（プロデューサーがPDF生成時にクラスタ形状を決定し、リーダーに依存しないようにする機能）は、Phase 8c.6に延期されます。これは、多くのデーヴァナーガリーのGSUB置換が、フォント固有のGIDを使用しており、Unicode Presentation Formのコードポイントに到達できないためです。一方、アラビア文字やラテン文字では、Forms-A/Forms-Bブロックがコードポイントに到達可能な置換を提供しますが、デーヴァナーガリーには同等のPresentation Formの範囲がUnicodeにありません。Phase 8c.6では、PUA（Private Use Area）の合成コードポイントのマッピングにより、デーヴァナーガリーおよびその他のインド/東南アジアのスクリプトで、フォント固有のGIDを使用する置換に対するプロデューサー側のGSUB機能が有効になります。

非デーヴァナガリー文字の内容は、`ApplyDevanagariReorder`メソッドを通過する際に、バイト単位で完全にそのまま（このメソッドはデーヴァナガリーの音節のみを処理し、他の文字範囲は変更せずにそのまま出力されます）。`sfIndicShaping`をオフにしたまま（デフォルト設定）呼び出すことで、出力はv2.119.66と同じになります。このコミットは、v2.119.55の機能層（`GetDevanagariCategory`と`ApplyDevanagariReorder`を公開メソッドとして提供）と組み合わせて、デーヴァナガリーのプロデューサ側の並べ替え機能を完了します。`sfIndicShaping`を有効にする場合、呼び出し元は事前に並べ替えを行う必要がなくなり、`BuildUnicode*FieldContent`を呼び出す前に`ApplyDevanagariReorder`を明示的に呼び出す必要もなくなりました。HotPDFが自動的に処理します。

2026-05-22 Version 2.119.66

GSUB 'rclt'（必要な文脈依存代替）の自動統合：新的 THotPDF.ApplyArabicGSUBContextualRefinement (Wide) 方法与 v2.119.63 的 ApplyArabicGSUBRefinement 方法类似，但它通过 v2.119.47 的 ApplyContextualSubst API 应用文脈依存的替换（GSUB 类型 5 / 6），而不是连字替换（类型 4）。'rclt' 编码了所需的、依赖于上下文的替换，通常由阿拉伯字体用于超出 v2.85.0 静态处理器的 Forms-B 映射的附加位置变体，以及由东南亚/印度字体用于依赖于相邻上下文的、在簇级别重新排列的形状。

可变長出力処理：`ApplyLigatureSubstitution`（N個の入力GID -> 1個の置換GID）とは異なり、`ApplyContextualSubst`はN個の入力GIDからM個の置換GIDを生成できます。コンテキストルールが適用される場合、すべての置換GIDが、逆対応マップ（FB00-FDFF + FE70-FEFF、約770個のコードポイントをスキャン）を介してUnicodeプレゼンテーション形式のコードポイントを介して到達可能である必要があります。そうでない場合、置換は行われず、入力ウィンドウは変更されずに通過します（部分的な出力はシーケンスを破損させる可能性があります）。逆対応マップの範囲が拡張され、ラテン/アルメニア/ヘブライウのプレゼンテーション形式（FB00-FB4F）と、すべてのアラビア範囲が含まれるようになりました。これにより、どのスクリプトからの`rclt`置換も出力できます。

新しいTHPDFShapingFeature列挙型メンバーsfContextualAlternatesが追加されました（既存の呼び出し元がFShapingFeaturesで算術演算を使用する場合、v2.119.59の5つのメンバーを持つ列挙型でコンパイルしても変更はありません）。この機能は、sfContextualAlternatesがFShapingFeaturesで有効になっている場合に、3つのBuildUnicode*FieldContentヘルパー関数で利用されます（オプションで、デフォルトでは無効）。これはFAutoShapeArabicとは独立しており、'rclt'はアラビア文字以外のスクリプト（ラテン文字/ヘブライ文字/インド文字）にも適用できます。v2.84.0のサブセッターでは、代替GIDがMarkUnicodeGlyphUsedを通じて処理されます。フォントに'rclt'ルールがない場合、または代替GIDにPresentation Formのコードポイントがない場合は、何もしません。sfContextualAlternatesを無効にした場合のPDF出力は、v2.119.65の出力とバイト単位で同じになります。

2026-05-22 Version 2.119.65

Latin 'liga' 標準リガチャ (GSUB エンジンロードマップフェーズ 8b): 新しい THotPDF.ApplyLatinLigatureRefinement (Wide) メソッドは、v2.119.63 の ApplyArabicGSUBRefinement と並行して動作しますが、U+FB00-U+FB4F の範囲にあるラテン文字/アルメニア文字/ヘブライ文字のアルファベット表示形式を対象とします。入力文字列を走査し、FUnicodeCpToGid を使用して並列の GID 配列を構築し、各位置で v2.119.43-50 の ApplyLigatureSubstitution API を介してフォントの GSUB 'liga' (標準リガチャ) 機能にクエリを行います。リガチャ置換が実行され、かつ置換 GID が Unicode アルファベット表示形式のコードポイントを介して到達可能である場合、元のコードポイント範囲は、置換のコードポイントで置き換えられます。この機能は、3 つの BuildUnicode*FieldContent ヘルパー (1 行、複数行、およびコンビナトリアル AcroForm /AP アピアランスストリームビルダー) に統合されており、FShapingFeatures の sfStandardLigatures で制御されます (オプションで、設定されていない場合はバイト単位で安定)。

「clig」（コンテキスト依存リガチャ）のオプションの2番目の処理：`sfContextualLigatures`も`FShapingFeatures`に含まれている場合、このメソッドは、標準のfi/fl/ffi/fflセットを超える、フォント固有のコンテキスト依存リガチャを適用するために、`liga`処理後の結果を再度走査します。各生成された代替GIDは、v2.84.0のTTFサブセッターの処理のために、`MarkUnicodeGlyphUsed`に渡されます。逆カンプマップは、約80個のコードポイント（FB00-FB4F）を線形スキャンし、置換は疎であり、コストは無視できるほどです。

ToUnicode CMap bfchar block extended from 28 to 35 entries: 7 new entries cover the Latin Alphabetic Presentation Forms FB00 (ff -> f + f), FB01 (fi -> f + i), FB02 (fl -> f + l), FB03 (ffi -> f + f + i), FB04 (ffl -> f + f + l), FB05 (ſt -> long s + t), FB06 (st -> s + t). Consumer-side text extraction (copy / paste / accessibility) now restores the original ASCII letter sequence when a Latin ligature codepoint appears in the PDF text stream. PDFs whose callers leave sfStandardLigatures off (the default) emit byte-identical to v2.119.64 output. Scope: only emits ligature substitutes reachable through Alphabetic Presentation Form codepoints — decorative / discretionary Latin ligatures with no Unicode codepoint (font-specific GIDs) cannot be emitted through this path and remain reserved for Phase 8c.6 GID-level emit.

2026-05-22 Version 2.119.64

公共代码点进位查询 API（GSUB 引擎路线图第 8c.5 阶段）：新的 THotPDF.GetCodepointAdvance (CP: Cardinal) 方法公开了 v2.76.0 的 /W 缓存，允许调用者在构建自定义的文本换行计算时，查询任何代码点的实际缩放比例，这些数据来自字体的 hmtx 表，并通过缓存的 cmap 获取。在 v2.119.32 / v2.119.58 / v2.119.60 / v2.119.62 静态连字后处理链以及 v2.119.63 GID 级别的 GSUB 优化后，该方法会返回实际连字字形的 hmtx 进位值——通常比源代码点进位值的总和更窄——以便调用者的换行预算与客户端渲染对齐。

BuildUnicodeMultilineFieldContent ヒューリスティックフォールバックの改善：v2.65 のフォールバックパス（/W キャッシュが利用できない場合に使用され、例えば RegisterUnicodeFontDict パスが RegisterUnicodeTTF パスの代わりに選択される場合）では、以前は U+2E80 以上のすべてのコードポイントをワイド（1.0 em）として扱っていました。アラビア文字の表示形式（FB50-FBFF Forms-A 文字、FC00-FDFF Forms-A リガチャ + クルアーンの FDF0-FDFD、FE70-FEFF Forms-B 基本形状 + LAM-ALEF）は、実際には狭い（主流のアラビアフォントで平均約 0.55 em）ものであり、ワイドではありません。v2.119.64 では、これらの 3 つのアラビア表示形式の範囲をヒューリスティックフォールバックの狭いパス（0.5 em）にルーティングし、これにより、v2.119.32 / v2.119.58 / v2.119.60 / v2.119.62 / v2.119.63 の後処理で生成されるアラビアリガチャが、キャッシュが有効でない場合に誤って 1.0 em の進み幅で出力されるという問題を修正します。

通常情况下，当未注册字体、缓存尚未填充、代码点超出BMP范围或代码点在字体的cmap中没有对应的字形时，该函数返回0。该函数是纯函数式，没有副作用，在RegisterUnicodeTTF成功后，可以安全地从任何上下文中调用。对于已加载字体且其/W缓存已填充，并且未使用新查询方法的PDF文件，其输出与v2.119.63版本的输出完全相同。8c.5阶段完成了GSUB引擎的路线图，实现了生产者端的自动阿拉伯语GSUB整形管道，达到了能力级别。8c.1-8c.5阶段共同实现了静态表后处理（4个连字系列）+ ToUnicode反向映射 + GID级别的GSUB优化 + 公开的字形位置查询，所有这些功能协同工作，使生产者端的阿拉伯语连字渲染与消费者端的显示在字节级别上完全一致。

2026-05-22 Version 2.119.63

GIDレベルのGSUB 'rlig'の改良処理（GSUBエンジンロードマップのフェーズ8c.2）：新しいTHotPDF.ApplyArabicGSUBRefinement (Wide)メソッドは、入力文字列を左から右へ走査し、キャッシュされたcmap（FUnicodeCpToGid）を使用して並列のGID配列を構築します。そして、各非ゼロGIDの位置で、フォントのGSUB 'rlig'（必須の合字）機能を、v2.119.43-50のApplyLigatureSubstitution APIを通じて問い合わせます。もし合字置換が実行され、かつ置換GIDがUnicodeアラビア表示形式のコードポイント（U+FB50-U+FDFF + U+FE70-U+FEFFの範囲、約690のコードポイント）を介して到達可能であれば、元のコードポイントの範囲は、置換のコードポイントで置き換えられます。置換されたグリフも、v2.84.0のTTFサブセッターの処理のために、MarkUnicodeGlyphUsedに渡されます。

v2.85.0 / v2.119.32 / v2.119.58 / v2.119.60 / v2.119.62版本之后，将功能集成到三个`BuildUnicode*FieldContent`辅助函数中，这些函数位于静态的、基于代码点的后处理链中（LAM-ALEF / YEH-HAMZA / Allah / Bismillah）。该功能补充了静态表，通过选择特定于字体的“rlig”规则，而这四个硬编码的字体系列中没有包含这些规则。典型的例子包括波斯语/乌尔都语/信德语/库尔德语字体（Vazirmatn, Markazi Text, Lateef, Scheherazade, Amiri）中的上下文变体，这些变体映射到Unicode显示形式，而这些形式超出了LAM-ALEF / YEH-HAMZA / Allah / Bismillah集合。该功能仅在`FAutoShapeArabic`为true 并且 `sfArabicGSUB` 不在 `FShapingFeatures` 中时才运行（互斥保护了v2.119.59的“调用方驱动”路径），并且加载的字体必须具有GSUB表。

変更範囲：GIDs が cmap を介してプレゼンテーションフォームのコードポイントから到達可能な置換のみが出力されます。フォント固有の GSUB 置換で、任意の GID に配置されるもの（コードポイントの逆参照マップがないもの）は、この方法では出力できません。これらは、Phase 8c.5 以降で予約されている、完全な GID レベルでの出力パイプラインが必要です。逆の cmap は、置換の試行ごとに約 690 のコードポイントを線形スキャンするため、実際には置換はまれであるため、コストは無視できます。ロードされたフォントに GSUB の 'rlig' コンテンツがない PDF、または置換にプレゼンテーションフォームのコードポイントがない PDF の場合、出力は v2.119.62 と同じになります（この場合、方法は防御的な無操作です）。この変更により、GSUB エンジンのプロデューサ側の自動アラビア文字整形パイプラインは、ハードコーディングされた静的テーブルチェーンを超えた、フォントを意識したリガチャ折りたたみ機能を実現します。

2026-05-22 Version 2.119.62

Bismillah phrase-level ligature post-pass (GSUB engine roadmap Phase 8c.4): the v2.85.0 producer-side Arabic shaper now folds the 22-codepoint canonical Bismillah phrase "بسم الله الرحمن الرحيم" ("In the name of God, the Most Gracious, the Most Merciful") into a single U+FDFD ARABIC LIGATURE BISMILLAH AR-RAHMAN AR-RAHEEM codepoint. Runs FIRST in the post-pass chain (before LAM-ALEF / YEH-HAMZA / Allah folds) so the full phrase is detected before the الله sub-phrase gets folded by the v2.119.60 Allah post-pass. Each letter position matches the base codepoint or any of its v2.85.0 Forms-B shaped variants (R-joining letters 3 variants each, D-joining 5 variants each); the three space positions require U+0020 exactly. Phrase-level detection on the canonical un-vowelled spelling.

ToUnicode CMap が拡張され、28 番目の bfchar エントリが追加されました。これにより、U+FDFD が元の 22 文字のシーケンス (BEH + SEEN + MEEM + SPACE + ALEF + LAM + LAM + HEH + SPACE + ALEF + LAM + REH + HAH + MEEM + NOON + SPACE + ALEF + LAM + REH + HAH + YEH + MEEM) にマッピングされるようになりました。クライアント側のテキスト抽出（コピー/ペースト/アクセシビリティ）では、単一の合字ではなく、元の 22 文字のフレーズが復元されるようになりました。これにより、4 つの静的テーブル合字ファミリー（LAM-ALEF / YEH-HAMZA / Allah / Bismillah）におけるラウンドトリップ動作が完了しました。

Known limitations (deliberate scope reductions): tatweel (U+0640) between letters not matched; harakat / diacritics between letters not matched (canonical fold targets un-vowelled Bismillah); non-breaking space U+00A0 or multiple spaces between words not matched (only single ASCII U+0020); alternative spellings (الرحمٰن with superscript alef) not matched; phrase must appear exactly without trailing modifiers. False-positive risk is essentially zero because the canonical 22-codepoint sequence is uniquely Bismillah by intent. Other Quranic honorifics (FDFA SALLALLAHOU ALAYHE WASALLAM, FDFB JALLAJALALOUHOU) and single-word ligatures (FDF3 AKBAR / FDF4 MOHAMMAD / FDF5 SALAM / etc.) remain out of scope because those source words also appear as ordinary Arabic terms in non-religious text and would generate false positives.

2026-05-22 Version 2.119.61

ToUnicode CMap reverse-mapping for Arabic ligatures (GSUB engine roadmap Phase 8c.3): the v2.83.0 RegisterUnicodeTTF Adobe-Identity-UCS CMap is now extended with 27 bfchar entries that override the bfrange identity mapping for every ligature codepoint emitted by the v2.85.0 producer-side Arabic shaper post-pass chain. Each entry restores the source codepoint sequence on consumer-side text extraction, fixing the limitation where copy / paste from PDF readers previously returned a single ligature character (e.g., "ﷲ" for Allah) rather than the original source word ("الله"). Bfchar takes precedence over bfrange per Adobe CMap and CIDFont Files Specification.

対応範囲：8つのLAM-ALEFエントリ（U+FEF5-U+FEFC）（v2.119.32、必須の連結字、4種類のALEFバリアント×2種類の形式）→ LAM + ALEF / ALEF MADDA / ALEF HAMZA ABOVE / ALEF HAMZA BELOWのソースペア；18つのYEH-HAMZAファミリーエントリ（U+FBEA-U+FBFB）（v2.119.58、初期形式FBF8とFBFBが含まれており、自動後処理では生成されないが、呼び出し元は直接使用できます）→ YEH-HAMZA + ALEF / AE / WAW / U / OE / YU / E / ALEF MAKSURAのソースペア；1つのAllahエントリ（U+FDF2）（v2.119.60）→ ALEF + LAM + LAM + HEHの4つのコードポイントのソースシーケンス。この範囲で、コピー/ペースト/アクセシビリティの往復操作が、3つの静的テーブル連結字ファミリーで完了します。

非アラビア語内容の場合、バイト数が安定します。`bfchar` ブロックは、非圧縮の PostScript テキストを約 700 バイト分 CMap ストリームに追加し、通常は `FlateDecode` によって約 150〜200 バイトに圧縮されます。アラビア語コンテンツのない PDF ファイルでも、同じ `/ToUnicode` ストリームの構成が使用されます。この拡張機能は、同じ間接的な `FlateDecode` ストリームオブジェクト内で追加されます。Adobe Reader、Foxit、PDF.js、Apple Preview などのクライアント側のリーダーはすべて、`bfchar` の優先順位を `bfrange` より高く設定し、逆マッピングを正しく適用します。27 エントリのブロックは CMap テキストにハードコードされており、PDF ごとのカスタマイズは不要です。今後の Phase 8c.4 では、U+FDFD の「Bismillah」リガチャに対応する追加の `bfchar` エントリが追加されます。

2026-05-22 Version 2.119.60

Allah ligature static post-pass: the v2.85.0 producer-side Arabic shaper now folds the four-codepoint sequence ALEF + LAM + LAM + HEH (الله in standard Arabic) into the single codepoint U+FDF2 ARABIC LIGATURE ALLAH ISOLATED FORM after the v2.119.32 LAM-ALEF and v2.119.58 YEH-HAMZA post-passes finish. Same model as the two earlier ligature post-passes: detect the source sequence in any combination of raw and shaped forms, emit a single codepoint output, trust the font to have the ligature glyph at the Unicode-defined cmap entry. This is the first slice of the GSUB engine roadmap Phase 8c (producer-side automatic Arabic GSUB shaping pipeline) — codepoint-level ligature folding for the most prevalent Arabic religious ligature.

Source-letter form matching covers all valid combinations after the v2.85.0 walker has shaped the sequence: ALEF in raw U+0627 or isolated FE8D or final FE8E form (R-joining, no init / medi); LAM in raw U+0644 or any of the four shaped forms FEDD-FEE0 (D-joining, full 4 positional forms); HEH in raw U+0647 or any of the four shaped forms FEE9-FEEC (D-joining). A typical standalone "الله" word emerges from the walker as FE8D + FEDF + FEE0 + FEEA (ALEF isol + LAM init + LAM medi + HEH final), which folds to FDF2. PDFs without the Allah codepoint sequence emit byte-identical to v2.119.59 output.

Known limitations of codepoint-level ligature folding: (1) Output is the isolated form FDF2 only — Unicode does not define final / initial / medial forms for the Allah ligature, but in practice Allah is almost always rendered standalone, so the single FDF2 codepoint suffices for visual rendering. (2) Consumer-side text extraction (copy / paste / accessibility) yields the single character "ﷲ" rather than the four-character word "الله" because the ToUnicode CMap has not yet been extended to reverse-map FDF2 to its 4-codepoint source. A future Phase 8c.3 installment will add the bfchar reverse mapping. (3) Font dependency: the loaded TTF / OTF must have a cmap entry mapping U+FDF2 to its Allah glyph; mainstream Arabic fonts (Noto Sans Arabic, Amiri, Scheherazade, Lateef, Markazi Text, Tahoma / Times New Roman Arabic) all include it. Other Quranic ligatures (FDF0 / FDF1 / FDF3-FDFB Allah-family honorifics, FDFD Bismillah) plus GID-level GSUB integration for font-specific substitutions are reserved for future Phase 8c.2-8c.4 installments.

2026-05-22 Version 2.119.59

プロデューサー側の整形パイプラインのオプション機能（GSUBエンジンのロードマップ、フェーズ8a）：新しいTHPDFShapingFeature列挙型とTHPDFShapingFeaturesセット型は、プロデューサー側のテキスト整形統合の計画された機能フラグをモデル化します。この列挙型には、sfArabicGSUB（このリリースで実装済み）、sfStandardLigatures（フェーズ8b、将来）、sfContextualLigatures（フェーズ8b、将来）、sfStylisticAlternates（フェーズ8d、将来）、およびsfIndicShaping（フェーズ8e、将来）という5つのメンバーがあります。THotPDFは、デフォルト値が[]（すべての機能が無効）のTHPDFShapingFeatures型のShapingFeaturesプロパティを獲得しました。v2.119.32-58の呼び出し元は、このプロパティをデフォルトのままにした場合、バイト単位で同一の出力を確認できます。

sfArabicGSUB 充当一个互斥锁，用于防止 v2.85.0 版本中的静态表阿拉伯语字形生成器。当 sfArabicGSUB 包含在 ShapingFeatures 中时，三个 BuildUnicode*FieldContent 辅助函数（单行、多行和组合 AcroForm /AP 外观流构建器）将完全跳过 _ApplyArabicShaping — 不会执行 v2.85.0 版本中的四位置代码点重写，也不会执行 v2.119.32 版本中的 LAM-ALEF 后处理，也不会执行 v2.119.58 版本中的 YEH-HAMZA + 元音后处理。调用者负责通过 v2.119.43-50 版本中的 GSUB 引擎 API 来控制阿拉伯语字形选择（使用 SetGSUBScript ('arab') + GetSingleSubstituteGlyph，针对 'init' / 'medi' / 'fina' / 'isol' 特征标签 + MarkUnicodeGlyphUsed，用于 v2.84.0 版本的子集化）。结合 sfArabicGSUB，现在，使用 Noto Sans Arabic / Amiri / Scheherazade / Markazi Text / 类似阿拉伯语字体的调用者，可以在生成时直接驱动完整的字形 GSUB 阿拉伯语字形生成，而无需依赖静态表的回退机制。

Companion Arabic capability API: two new public methods GetArabicJoiningClass (CP) and GetArabicPosition (Wide, Index) mirror the v2.119.53 GetSyriacJoiningClass / v2.119.54 GetMongolianJoiningClass pattern, exposing the internal joining-class table and 4-position contextual walker the static shaper uses. Callers driving Arabic GSUB shaping manually no longer need to re-derive joining-class data per codepoint — they can reuse the cumulative v2.85.0 / v2.119.35 / v2.119.52 / v2.119.57 table that already covers basic Arabic (U+0600-U+06FF), Arabic Supplement (U+0750-U+077F), and Arabic Extended-A (U+08A0-U+08FF). With this slice landed, the user's two-item request "Forms-A FBEA-FBFB 装饰类合字 (v2.119.58) + Producer-side 自动 Arabic GSUB shaping pipeline (this release)" is fulfilled at the capability + opt-in framework layer. Full producer-side automatic GSUB application inside TextOut / BuildUnicode*FieldContent (auto cmap-to-GID + per-position GSUB substitute + substitute GID emit, with no caller code) remains reserved for the deeper Phase 8c integration commits.

2026-05-22 Version 2.119.58

YEH-HAMZA + 母音字母连字后处理：v2.85.0版本的阿拉伯语整形器现在，在4位步进器和v2.119.32版本的LAM-ALEF后处理阶段，将编码在U+FBEA-U+FBFB范围内的8个连字对折叠为单个连字代码点。该模型和集成方式与LAM-ALEF相同（强制静态表替换，每个连字输出2个形式）。涵盖的组合有：YEH-HAMZA + ALEF -> FBEA/FBEB（标准阿拉伯语/波斯语/乌尔都语），YEH-HAMZA + AE U+06D5 -> FBEC/FBED（克什米尔语/维吾尔语），YEH-HAMZA + WAW -> FBEE/FBEF（标准阿拉伯语），YEH-HAMZA + U U+06C7 -> FBF0/FBF1（维吾尔语/哈萨克语/吉尔吉斯语），YEH-HAMZA + OE U+06C6 -> FBF2/FBF3（相同），YEH-HAMZA + YU U+06C8 -> FBF4/FBF5（相同），YEH-HAMZA + E U+06D0 -> FBF6/FBF7（相同），YEH-HAMZA + ALEF MAKSURA -> FBF9/FBFA（标准阿拉伯语）。

YEH-HAMZA 在原始形式 U+0626 或其任何 v2.85.0 的变形中被匹配（FE89 isol, FE8A final, FE8B init, FE8C medial）；随后的元音字母以原始形式或其 v2.119.57 Forms-A 变形（FBD7-FBD8 用于 U, FBD9-FBDA 用于 OE, FBDB-FBDC 用于 YU, FBE4-FBE7 用于 E）或 v2.85.0 Forms-B 变形（FE8D-FE8E 用于 ALEF, FEED-FEEE 用于 WAW, FEEF-FEF0 用于 ALEF MAKSURA）进行匹配。最终形式的选择（基数 + 1）遵循 LAM-ALEF 规则：当 YEH-HAMZA 被变形为 FE8A final 或 FE8C medial 形式（即，它前面是双连接字母）时，则输出连字以其最终形式；否则输出孤立形式。

この後処理では、分離された最終形（2形式の出力）のみが出力されます。Unicodeで定義されている初期形であるFBF8（YEH-HAMZA + E）およびFBFB（ウイグル語のYEH-HAMZA + ALEF MAKSURA）は生成されません。これらの3形式のバリアントが必要な場合は、ApplyContextualSubstを介してフォントの'rlig' / 'clig'連鎖コンテキストGSUBルックアップを呼び出す必要があります。他のアラビア文字の合字領域（Allah U+FDFA / FDFB、FC00-FDC7の装飾的な合字）は、GSUB 'rlig' / 'dlig'によって処理され、静的なテーブルシェーパの範囲外です。YEH-HAMZAの後に、サポートされている8つの母音文字のいずれかが続くPDFでは、v2.119.57と同じバイト列が出力されます。この新しい後処理は、特定の2つのコードポイントのシーケンスに対してのみ実行されます。

2026-05-22 Version 2.119.57

Persian / Urdu / Sindhi / Kashmiri / Uyghur / Kazakh / Kyrgyz Arabic Extended letter coverage: the v2.85.0 producer-side Arabic shaper joining-class table now spans the entire U+0672-U+06D5 range per Unicode 16.0 ArabicShaping.txt, closing the "Persian/Urdu Form-B 扩展" work-item that was deferred when v2.119.35 shipped the 9-letter Persian/Urdu core and v2.119.52 added the ALEF WASLA / NOON GHUNNA / HEH variants. About 80 letters are added to the joining-class table covering REH / DAL / SEEN / SAD / TAH / AIN / FEH / QAF / KAF / GAF / LAM / NOON / HEH / WAW / YEH variants — so adjacent letters now pick correct positional forms regardless of which Arabic Extended-A letter sits next to them.

新たに分類された26文字のうち、さらに15文字は、U+FB52-U+FBFCの範囲で静的なプレゼンテーションフォームAエントリを持ち、フォントのGSUBシェーパを必要とせずに、静的なテーブルシェーパによって直接マッピングされます。これには、15個のD-結合4形式文字（TTEHEH U+067A → FB5E-FB61、BEEH U+067B → FB52-FB55、TEHEH U+067F → FB62-FB65、BEHEH U+0680 → FB5A-FB5D、NYEH U+0683 → FB76-FB79、DYEH U+0684 → FB72-FB75、TCHEHEH U+0687 → FB7E-FB81、VEH U+06A4 → FB6A-FB6D、PEHEH U+06A6 → FB6E-FB71、NG U+06AD → FBD3-FBD6、NGOEH U+06B1 → FB9A-FB9D、GUEH U+06B3 → FB96-FB99、RNOON U+06BB → FBA0-FBA3、HEH DOACHASHMEE U+06BE → FBAA-FBAD、これは標準のウルドゥー語の「h」文字です。また、E U+06D0 → FBE4-FBE7はカザフ/キルギスのアラビア文字、さらに11個のR-結合2形式文字（DAHAL U+068C → FB84-FB85、DDAHAL U+068D → FB82-FB83、DUL U+068E → FB86-FB87、KIRGHIZ OE U+06C5 → FBE0-FBE1、OE U+06C6 → FBD9-FBDA、U U+06C7 → FBD7-FBD8、YU U+06C8 → FBDB-FBDC、KIRGHIZ YU U+06C9 → FBE2-FBE3、VE U+06CB → FBDE-FBDF、YEH BARREE U+06D2 → FBAE-FBAF、これはウルドゥー語の語末の「yeh」です。YEH BARREE WITH HAMZA ABOVE U+06D3 → FBB0-FBB1）。

HEH DOACHASHMEE および YEH BARREE という2つの文字は、特に注意が必要です。なぜなら、これらの文字の Forms-A スロット (FBAA-FBAD および FBAE-FBAF) が、v2.119.52 のバグによって誤って U+06C2 HEH GOAL WITH HAMZA ABOVE および U+06C3 TEH MARBUTA GOAL に割り当てられていたためです。v2.119.56 ではこれらの誤ったマッピングが修正され、v2.119.57 ではこれらのスロットが正しい文字にバインドされることで、監査ログはクリーンになり、この混同は完全に解決されました。Unicode 16 で Presentation Forms-A エントリを持たない U+0672-U+06D5 の範囲の文字 (約 50 個の追加のコードポイントで、主に REH / DAL / SEEN / SAD / TAH / AIN / FEH / QAF / KAF のバリエーションで、あらかじめエンコードされた形状を持たないもの) は、依然として結合クラス分析に参加し、近傍の文字が正しく形状を調整されます。これらの文字自体は生のコードポイントとして通過し、v2.119.43-50 の GSUB エンジンにおけるフォントの GSUB ルックアップテーブルに依存して、独自の形状を選択します。78018 行でコンパイルされ、これらの新しいコードポイントを含まない PDF ファイルは、v2.119.56 とバイト単位で同一です。

2026-05-22 Version 2.119.56

アラビア文字の整形に関するバグを修正しました。v2.119.52では、ウルドゥー語/シンドゥー語地域で使用される2つの文字のアラビアプレゼンテーションフォームAのマッピングが正しくありませんでした。U+06C2 HEH GOAL WITH HAMZA ABOVEは、実際にはU+06BE HEH DOACHASHMEEのコードポイント範囲であるFBAA-FBADにマッピングされていました。そのため、ウルドゥー語の「Goal-Heh-with-Hamza」のグリフが、標準のウルドゥー語の「Heh-Doachashmee」のグリフとして表示されていました。同様に、U+06C3 TEH MARBUTA GOALは、実際にはU+06D2 YEH BARREEのコードポイント範囲であるFBAE-FBAFにマッピングされていました。そのため、「Teh-Marbuta-Goal」がウルドゥー語の語末の「Yeh-Barree」として表示されていました。Unicode 16.0によると、U+06C2とU+06C3のどちらにも、あらかじめエンコードされたプレゼンテーションフォームAのエントリはありません。どちらも変更せずに、そのままのコードポイントとして処理する必要があります（ユーザー側のリーダーは、フォントのcmapとGSUBによる整形によって、これらを正しく表示します）。

修正：在 v2.85.0 版本中，阿拉伯语排版器的 _ArabicShape Presentation Forms-A_ 查找表中的两个错误条目已被删除。现在，U+06C2 和 U+06C3 将直接传递，并以未修改的状态输出。来自 v2.119.52 版本的连接类条目（U+06C2 对应 D，U+06C3 对应 R）仍然保留，以便相邻的字母在这些字符出现在单词中时，仍然可以正确地选择位置形式。此修复仅影响包含 U+06C2 或 U+06C3 且启用了 AutoShapeArabic 的 PDF 文件；不包含这两个代码点的 PDF 文件与 v2.119.55 的输出完全相同。配套的 v2.119.57 版本扩展了 Forms-A 的覆盖范围，包括更多的波斯语/乌尔都语/信德语/喀什米尔语/维吾尔语/哈萨克语/吉尔吉斯语字母，包括真正采用 Forms-A 编码的 HEH DOACHASHMEE 和 YEH BARREE，而 v2.119.52 中的错误将它们混淆了。

2026-05-22 Version 2.119.55

デーヴァナガリー文字の整形機能：THotPDFクラスに、デーヴァナガリー文字の整形に対応した2つの新しい公開メソッドが追加されました。これらのメソッドは、アラビア文字、シリア文字、モンゴル文字で使用される4位置の結合クラスウォーカーでは対応できない、デーヴァナガリー文字の整形パラダイムを扱います（v2.85.0 + v2.119.32-54）。GetDevanagariCategory (CP)メソッドは、Unicode 16.0 §12.1およびIndicSyllabicCategory.txtに従って、簡略化されたデーヴァナガリー文字の音節カテゴリを返します（0 = その他、1 = 子音、2 = 自立母音、3 = マトラ、4 = ヴィラーマ、5 = ヌクタ、6 = ビンドゥ、7 = ヴィサルガ、8 = ダンダ、9 = 数字、10 = ZWJ、11 = ZWNJ、12 = 修正）。このテーブルは、U+0900-U+097Fの完全なデーヴァナガリー文字ブロックをカバーし、U+0978-U+097Fのマルワリ、シンド、ヴェーダの拡張も含まれます。

ApplyDevanagariReorder (Wide) 从左到右遍历输入字符串，并将 Devanagari 重排预处理应用于遇到的每个 Devanagari 音节，返回一个已重排的 Unicode 字符串，可供 cmap + GSUB 使用。非 Devanagari 内容（拉丁文、数字、标点符号和其他脚本）保持字节不变。实现了两种重排方式（在实际 Devanagari 字符形状处理中占主导地位的两种方式）：(1) Repha — 如果音节以 Ra (U+0930) + Halant (U+094D) + 辅音开头，则将 (Ra, Halant) 对移动到音节的末尾，以便字体的 'rphf' GSUB 特征将其替换为视觉上附加在音节右上方 Repha 字形；(2) 预底 I-matra — U+093F 移动到音节的开头（在任何 Repha 移除之后），以便从左到右的 GSUB 处理将其置于辅音簇之前，以匹配其视觉渲染顺序。

呼び出しパイプライン：論理順のテキストに対して`ApplyDevanagariReorder`を適用し、`SetGSUBScript ('deva')`を設定し、並べ替えられたコードポイントを走査し、`GetSingleSubstituteGlyph`と`ApplyLigatureSubstitution`、および`ApplyContextualSubst`を使用して、GSUB機能（'nukt' / 'akhn' / 'rphf' / 'rkrf' / 'half' / 'vatu' / 'cjct' / 'pres' / 'blws' / 'abvs' / 'psts' / 'haln'）を適用します。その後、結果のGIDをPDFテキストストリームにエミットし、同時に`MarkUnicodeGlyphUsed (GID)`を呼び出します（v2.84.0のサブセット化機能）。フェーズA（v2.119.52 Arabic Extended-A）、フェーズB（v2.119.53 Syriac）、フェーズC（v2.119.54 Mongolian）、およびフェーズD（v2.119.55 Devanagari Indic）がすべて実装されたことで、「モンゴル語/シリア語/デバナガリー語の整形」に関するギャップが完全に解消されました。対象外：デバナガリー語以外のインド脚本（ベンガル語、タミル語、テルグ語、グジャラート語—それぞれに独自のカテゴリデータと並べ替えルールがあります）、Rephaを超える並べ替えルール、および`TextOut` / `BuildUnicode*FieldContent`内でのプロデューサ側の自動デバナガリー語整形（GSUBエンジンのロードマップの第8フェーズのために予約されています）。

2026-05-22 Version 2.119.54

モンゴル文字の整形機能：THotPDFクラスに公開された2つの新しいメソッドにより、モンゴル文字（U+1800-U+18AF）の結合クラスのルックアップと、4位置の文脈分析が可能になり、呼び出し元はプロデューサ側のモンゴル文字の整形を制御できます。GetMongolianJoiningClass (CP) は、Unicode 16.0 §13.5で定義されたモンゴル文字の結合クラス（0 = 結合しないU、2 = 両方向結合D、4 = 透明/バリエーション選択子）を、任意のコードポイントに対して返します。このテーブルは、基本的なモンゴル文字に加えて、Todo、Sibe、満州語、およびAli Gali文字の拡張（U+1820-U+1878 + U+1887-U+18A8 + ALI GALI DAGALGA U+18A9 + 満州語 ALI GALI LHA U+18AA）をカバーし、NIRUGU (U+180A)、3つのフリーバリエーションセレクタFVS1-FVS3 (U+180B-U+180D)、およびAli Gali BALUDA / THREE BALUDAの母音記号（U+1885-U+1886）を透明として分類します。GetMongolianPosition (Wide, Index) は、周囲のテキストを透明な記号をスキップしてトラバースし、0ベースのIndexにある文字に対して、0 = 単独、1 = 終端、2 = 先頭、または3 = 中間を返します。

Syriacと同様に（v2.119.53）、モンゴル語にはUnicodeにプリエンコードされたプレゼンテーションフォームはありません。モンゴル語に対応するすべてのフォント（Mongolian Baiti、Noto Sans Mongolian、Noto Serif Mongolianなど）は、OpenType GSUBルックアップを使用して、'init'、'medi'、'fina'、'isol'の機能で位置情報を制御します。したがって、v2.119.54は、v2.119.53と同様に、機能のみを提供するモデルに従います。呼び出し元は、位置情報を出力し、v2.119.43-50のGSUBエンジンAPI（'mong'スクリプトのSetGSUBScript、適切な位置機能タグに対するGetSingleSubstituteGlyph、v2.84.0のサブセッターのMarkUnicodeGlyphUsed）を使用して、整形されたGIDを生成し、それを直接PDFテキストストリームに書き込みます。

モンゴル語は、そのネイティブの書字モードで縦書きで記述されます。この機能は、視覚的な方向に関係なく、論理的なコードポイント順序（コードポイントストリーム内の前置/後置）で動作します。実際の縦書きのレンダリングは、PDFの生成時に`/WMode 1`（縦書き）またはフォントマトリックスの回転によって処理されますが、シェーパによって処理されるものではありません。Free Variation Selectors（FVS）の「透明」という分類は、FVSが文字の後に続く場合でも、この機能が位置情報に基づいて正しい形式を解決することを意味します。フォントのGSUBルックアップは、'fina'、'medi'、'init'、'isol'の機能に基づいて、入力ストリームにFVSが含まれる場合に、自動的にFVSに条件付けされたバリアントを選択します。デバナガリー（インド）のシェーピングは、UAX #38（ヴィラーマ/子音クラスター/プレベースの並べ替え）に必要なインドの並べ替えの事前処理があるため、今後のバージョンで実装される予定です。これは、アラビア文字/シリア文字/モンゴル文字で使用される4位置のシェーパとは一致しません。TextOut / BuildUnicode*FieldContent内での自動モンゴル語シェーピングは、GSUBエンジンのロードマップのフェーズ8で実装される予定です。

2026-05-22 Version 2.119.53

シリア文字の整形機能：THotPDFクラスに公開された2つの新しいメソッドにより、シリア文字（U+0700-U+074F）の結合クラスのルックアップと、4位置の文脈分析が可能になり、呼び出し元はプロデューサ側のシリア文字の整形を制御できます。GetSyriacJoiningClass (CP) は、Unicode 16.0のSyriacShaping.txtの結合クラス（0 = 非結合、1 = 右結合、2 = 両方向結合、4 = 透明/NSM）を任意のコードポイントに対して返します。このテーブルは、基本ブロック内の35個のシリア文字に加え、ペルシャおよびソグドの拡張（U+072D-U+072Fのペルシャ文字ベト/ガマル/ダラット、U+074D-U+074Fのソグド文字ザイン/カフ/フェ）をカバーし、上付きアルファ（U+0711）とシリア文字の結合記号（U+0730-U+074A）を透明として分類します。GetSyriacPosition (Wide, Index) は、周囲のテキストを透明な記号をスキップして調べ、0番目のインデックスの文字に対して、0 = 単独、1 = 終端、2 = 先頭、または3 = 中間を返します。

アラビア語とは異なり、アラビア語には事前にエンコードされたプレゼンテーションフォームB（U+FE70-U+FEFF）とフォームA（U+FB50-U+FBFF）ブロックがあり、これによりHotPDFは直接コードポイントを形状付きのバリアントに書き換えることができます。一方、シリア語ブロックにはUnicodeに事前にエンコードされたプレゼンテーションフォームがありません。シリア語に対応するすべてのフォント（Estrangelo Edessa、Serto Jerusalem、East Syriac Adiabene、Noto Sans Syriacなど）は、OpenType GSUBルックアップを使用して、'init'、'medi'、'fina'、'isol'の機能を通じて位置情報を決定します。したがって、v2.119.53では、この機能層のみが提供されます。呼び出し元は、v2.119.43-50のGSUBエンジンAPI（'syrc'のSetGSUBScript、適切な位置情報機能タグに対するGetSingleSubstituteGlyph、v2.84.0のサブセッターのMarkUnicodeGlyphUsed）を使用して、位置情報を出力と組み合わせ、形状付きのGIDを生成し、それを直接PDFテキストストリームに送信します。

アラフの終端形適用範囲：Unicode §9.3 では、シリア文字フォントがアラフの終端グリフを置き換えるために使用する、2つのコンテキスト依存の終端機能 ('fin2' は DALATH / RISH の後、'fin3' は FINAL LAMADH の後に適用) について説明されています。v2.119.53 では、アラフ (U+0710) を基本的な右結合文字として分類し、0 (孤立) または 1 (終端) のみを返します。'fin2' / 'fin3' の区別が必要な場合は、フォントの連鎖コンテキストルックアップを、それらの機能タグを使用して ApplyContextualSubst で実行する必要があります。モンゴル文字とデヴァナガリー文字 (インド文字) の整形は、今後のバージョンで実装される予定です。モンゴル文字は、フリーバリエーションセレクターと母音調和を使用し、デヴァナガリー文字は UAX #38 に従って、整形前の順序変更が必要です。どちらもシリア文字のような 4 位置ウォーカーには対応していません。TextOut / BuildUnicode*FieldContent 内の自動シリア文字整形は、GSUB エンジンのロードマップのフェーズ 8 で実装される予定です。

2026-05-22 Version 2.119.52

アラビア文字の整形機能の拡張：v2.85.0で導入された、プロデューサー側の静的アラビア文字整形機能が、アラビア拡張Aに残りの文字（ALEF WASLA U+0671、NOON GHUNNA U+06BA、HEHのバリエーション U+06C0-U+06C3）、アラビア補完ブロックU+0750-U+077F（ハウサ語、ウォロフェ語など、アフリカで使用されるアラビア文字）、およびアラビア拡張Aの新しい領域U+08A0-U+08FF（クルアーンアラビア語 + ウォロフェ語/ハウサ語の拡張文字 + クルアーンの結合記号）をサポートするようになりました。結合クラスはUnicode 16.0のArabicShaping.txtから取得され、v2.85.0の4位置分析中に適用されるため、隣接する文字が、隣接するアラビア文字の種類に関係なく、正しいinit/medi/fina/isolの形式を選択します。

アラビア文字のうち、アラビア表示形式Aブロック（U+FB50-U+FBFF）に事前エンコードされた静的な表示形式を持つ文字は、OpenType GSUBシェーパを必要とせずに、直接それらの形式にマッピングされます。具体的には、ALEF WASLA は FB50/FB51（右結合、2つの形式）、NOON GHUNNA は FB9E/FB9F（Unicodeではデュアル結合ですが、実際には2つの事前エンコードされた形式のみ；init/medi は isol に適切に変換）、HEH WITH YEH ABOVE は FBA4/FBA5（右結合、2つの形式）、HEH GOAL は FBA6/FBA7/FBA8/FBA9（デュアル結合、4つの形式）、HEH GOAL WITH HAMZA ABOVE は FBAA/FBAB/FBAC/FBAD（デュアル結合、4つの形式）、TEH MARBUTA GOAL は FBAE/FBAF（右結合、2つの形式）にマッピングされます。これに、v2.119.32 で導入された必須の LAM-ALEF リガチャー後処理と、v2.119.35 で提供されたペルシャ語/ウルドゥー語のコア9文字セットと組み合わせることで、静的なシェーパは、フォントの GSUB テーブルに依存せずに、現代アラビア語、ペルシャ語、ウルドゥー語、シンド語、パシュトゥー語、クルド語、ウイグル語、クルアーン語、およびアフリカのアラビア語（ハウサ語、ウォロフェ語など）のテキストをほぼすべてカバーします。

アラビア語補完（U+0750-U+077F）および新しいアラビア語拡張A文字領域（U+08A0-U+08C7）には、あらかじめエンコードされた静的な表示形式がありません。これらの文字の結合クラスエントリにより、近傍文字が正しく整形されますが、文字自体は生のコードポイントとして残り、独自の配置整形には、GSUBに対応したフォント（または、呼び出し元によって駆動されるv2.119.43-50のGSUBエンジンAPI）に依存します。アラビア語拡張Aのクルアーンの組み合わせ記号領域（U+08CA-U+08E1、U+08E3-U+08FF）は、透過型（T-結合）として分類されており、近傍文字の配置解析ではこれらがスキップされます。これは、既存のU+064B-U+065Fのハラカートの処理と一致しています。これらの拡張文字を含まないテキストは、v2.119.51の出力とバイト単位で同じです。モンゴル語/シリア語/デヴァナガリーの整形（アラビア語とは異なる整形モデル）は、今後の改訂で実装される予定です。

2026-05-22 Version 2.119.51

XFA（XML Forms Architecture）のプロデューサー側のコンテナサポート：PDF 1.7 §12.7.6 および §12.7.8 では、AcroForm が静的な /Fields 配列に加えて、またはその代わりに /XFA エントリを持つことができます。新しい THotPDF.AddXFAPacket (PacketName, XMLBytes) メソッドは、名前付きの XFA パケットを登録します。一般的な名前には、'template'（フォームレイアウトとスクリプト）、'datasets'（データバインディング）、'config'（ビューア構成）、'connectionSet'、'localeSet'、'stylesheet'、'xfdf'、'xmpmeta'、'signature'、および 'sourceSet' があります。登録された各パケットは、EndDoc で FlateDecode で圧縮されたストリームとして保存され、/XFA 配列は、登録順序でパケット名を表す PDF 文字列とストリーム参照を交互に含み、これによりレイアウトがバイト単位で決定的に再現されます。THotPDF.ClearXFAPackets および THotPDF.XFAPacketCount メソッドは、API の機能を補完します。

HotPDF仅提供容器级别的支持，它不会解析XFA XML，也不会实现XFA动态布局引擎，不会执行XFA模板中的FormCalc或JavaScript，并且不会验证模板结构。调用者需要自行编写XFA XML（通常使用Adobe LiveCycle Designer或根据XFA 3.3规范手动编写），HotPDF会直接输出字节数据。具有XFA引擎的应用程序（例如旧版Acrobat/Reader、FormsCentral以及某些自助服务终端产品）会渲染表单；而没有XFA引擎的应用程序（例如2017年及以后的Adobe Reader DC以及大多数开源阅读器）如果文档是混合AcroForm + XFA工作流程，则会显示备用AcroForm字段。

PDF/A および PDF/X 準拠のチェック機能を追加しました。ISO 19005-1 §6.4.2 / ISO 19005-2 §6.4.2 / ISO 19005-3 §6.4.2 では、XFA フォームの使用を明示的に禁止しています（動的なレイアウトエンジンは、完全に再現可能ではありません）。ISO 15930 のプリプレスワークフローでは、インタラクティブフォームを完全に拒否します。`AddXFAPacket` は、`PDFACompliance` または `PDFXCompliance` が空でない場合に、関連する仕様への参照とともに即座にエラーを発生させます。重複したパケット名はエラーとなります。`PacketName` が空の場合、または `XMLBytes` が空の場合もエラーとなります。`RequirePDFVersion (pdf15)` を使用すると、ドキュメントのバージョンが自動的に引き上げられます。`/Fields` に少なくとも 1 つのエントリがある場合、または少なくとも 1 つの XFA パケットが登録されている場合に、`AcroForm` ディクショナリが生成されます。v2.119.51 より前のバージョンでは、パケットを登録しない場合、`/AcroForm` の出力はバイト単位で同じままです。

2026-05-22 Version 2.119.50

TTFサブセッターにおけるGSUB置換グリフの処理：新的THotPDF.MarkUnicodeGlyphUsed (GID: Word)により、cmapにそのグリフに対応するコードポイントが存在するかどうかに関係なく、v2.84.0のEndDocサブセッターにグリフが登録されます。v2.84.0のこの機能は、cmapを介してFUnicodeUsedCpsから使用されたグリフのセットを派生させます。したがって、以前はGSUBによって導入されたすべての置換グリフ（スタイル代替、リガチャ、コンテキストバリアント、Phase 1-6クエリAPIのすべての出力）は、サブセッターに認識されず、読み取りアプリケーションは代わりに「.notdef」をレンダリングしていました。現在、GetSingleSubstituteGlyph / GetMultipleSubstituteGlyphs / GetAlternateGlyph / ApplyLigatureSubstitution / ApplyContextualSubst / ApplyReverseChainedContextualSubstによって返されたGIDをPDFテキストストリームに送信した後、呼び出し元は、送信された各GIDに対して1回だけMarkUnicodeGlyphUsed (GID)を呼び出し、それを埋め込みサブセットに含めます。

このヘルパー関数は冪等性を持っています（同じGIDで繰り返し呼び出しても何もしません）、また、防御的にも設計されています（GIDがFUnicodeNumGlyphs以上の場合、静かに無視されます。また、RegisterUnicodeTTFを呼び出す前に呼び出された場合は、何もしません）。さらに、この関数は_BuildSubsetTTF内のv2.84.0の複合グリフ処理機能と連携しており、呼び出し元は上位レベルの置換GIDのみをマークすればよく、複合コンポーネントは既存の_TTFWalkCompositeClosureによって自動的に取り込まれます。このセットは、初回呼び出し時に遅延的に割り当てられ、RegisterUnicodeTTFが呼び出されるたびに（空の、nil）、他のサブセットの状態と同様にリセットされます。フェーズ9が実装されたことで、フェーズ1〜7のすべてのGSUBクエリAPIを、埋め込みフォントから置換グリフが失われることなく、サブセットの生成と安全に組み合わせることができます。

2026-05-22 Version 2.119.49

OpenType GSUB スクリプト/言語システム選択API：THotPDFクラスに新たに公開された5つのメソッドにより、呼び出し元はGSUBルックアップを特定のスクリプトと言語に固定できるようになりました。以前は、DFLTスクリプト/デフォルトの言語システムが使用されていました。SetGSUBScript ('latn' / 'arab' / 'cyrl' / 'hani' / 'kana' / 'deva' / 'beng' / 'taml' / など) を使用して、OpenTypeスクリプトタグを選択します。デフォルトでは空文字列で、v2.119.43-48の基準設定が維持されます（'DFLT'を優先し、それ以外の場合は最初のスクリプトを使用します）。SetGSUBLanguage ('ENG ' / 'TUR ' / 'AZE ' / 'JAN ' / 'KOR ' / 'ARA ' / など、末尾に4バイトのスペースを追加) を使用して、OpenType言語タグを選択します。空文字列は、スクリプトのデフォルトの言語システムです。これらの設定はGSUBクエリ全体で保持され、RegisterUnicodeTTF ('', nil) を呼び出すとクリアされます。

新しい列挙ヘルパーにより、ロードされたフォントが提供する情報を確認できます。`GetGSUBScripts`: `TGSUBStringArray` は、`ScriptList` の順序で、すべてのスクリプトタグを返します。`GetGSUBLanguages (ScriptTag)` は、指定されたスクリプト内のすべての言語タグを返します（スクリプトにデフォルトの `LangSys` がある場合、インデックス 0 には '' というプレースホルダーがあります）。`GetGSUBFeatures (ScriptTag, LangTag)` は、`LangSys` の `featureIndices` の順序で、(スクリプト、言語) の組み合わせによって提供されるすべての機能タグ（例：'liga', 'salt', 'aalt', 'ss01' ～ 'ss20'）を返します。空の `ScriptTag` / `LangTag` は、置換 API と同じ DFLT-優先 / デフォルトの `LangSys` のフォールバックを使用するため、呼び出し元は `GetGSUBFeatures ('', '')` を呼び出して、最初にスクリプトリストを検査することなく、デフォルトの機能タグを列挙できます。

厳密な優先順位とフォールバックの選択: `SetGSUBScript` がタグに設定されている場合、ロードされたフォントがそのタグをサポートしていない場合、その後の GSUB クエリは空の結果を返します（または何も行いません）。エンジンは DFLT に自動的にフォールバックしません。これにより、呼び出し元は選択したスクリプトが利用できないことを明確に認識できます。`SetGSUBLanguage` が認識されないタグに設定されている場合、OpenType 仕様の推奨に従って、そのスクリプトのデフォルトの `LangSys` にフォールバックします。既存の 7 つの GSUB 置換メソッド（`GetSingleSubstituteGlyph`、`GetMultipleSubstituteGlyphs`、`GetAlternateGlyphCount`、`GetAlternateGlyph`、`ApplyLigatureSubstitution`、`ApplyContextualSubst`、`ApplyReverseChainedContextualSubst`）は、公開インターフェースが変更されず、バイト単位で同一のままです。内部ヘルパー関数 `_GSUBFindFeatureLookups` には、すべての呼び出し元が現在ルーティングする 2 つの追加パラメータが追加されました。`Script` / `LangSys` API と、LookupType 1～8 のマトリックスが実装されたことで、GSUB エンジンは機能のみを使用する場合に機能が完全に揃っています。残りのロードマップのフェーズ（自動シェーピングパイプラインと TTF サブセッターの統合）は、新しいクエリインターフェースではなく、プロデューサー側の統合を対象としています。

2026-05-22 Version 2.119.48

OpenType GSUB リバースチェーンコンテキストシングル置換 (LookupType 8): 新しい THotPDF.ApplyReverseChainedContextualSubst (const InputGIDs; StartIndex; FeatureTag; out OutGID): Boolean が、最後に実装された GSUB ルックアップタイプです。Type 8 は、入力グリフの Coverage インデックスによって選択される 1:1 のシングル置換であり、その特徴は、呼び出し元がマルチグリフの範囲に対して、REVERSE スキャン順序で適用する必要があることです (終端 → 開始)。これは、各置換がまだ置換されていない FUTURE のコンテキストに依存する可能性があるためです。このヘルパー関数は、単一ポイントの適用関数であり、呼び出し元がリバーススキャンループを制御します。Coverage Format 1 + 2、LookupFlag (入力、バックトラック、およびルックアヘッドのすべてがスキップを考慮)、および拡張 (LookupType 7) はすべてサポートされています。

典型使用场景：某些阿拉伯语/亚述语/N'Ko语/印度语语境变体，其最终形式取决于后续字形的特定形状。一些字体也将其用于区分拉丁语序列。与LookupType 5/6不同，Type 8没有嵌套查找机制，因为替换是内在的一对一关系。如果没有匹配项，则返回False，OutGID = InputGIDs[StartIndex]（尽力匹配v2.119.43 GetSingleSubstituteGlyph的约定）。

v2.119.48 版本中，为 THotPDF 上的每个 OpenType GSUB LookupType（1 到 8）添加了专用的公共功能，用于关闭 LookupType 矩阵。脚本/语言系统选择 API、自动整形管道集成以及 TTF 字体子集器自动提取替换字体的功能，仍保留在第 7-9 阶段；调用者仍然需要负责将选择的替换字体标记到嵌入的字体子集中，并自行驱动反向扫描循环。

2026-05-22 Version 2.119.47

OpenType GSUB 上下文替换 + 链式上下文替换（LookupType 5 + 6）：新的 THotPDF.ApplyContextualSubst (const InputGIDs; StartIndex; FeatureTag; var OutGIDs; out ConsedLen): Boolean 是一个单一的入口点，涵盖了所有三种子表格式的 LookupType 5（仅输入上下文）和 LookupType 6（回溯/输入/预览上下文）。这些格式包括：Format 1（字形 ID 序列）、Format 2（ClassDef 类序列）和 Format 3（Coverage 表序列，这是大多数现代字体使用的标准形式）。标准用法包括 'rclt'（必需的上下文替代，用于阿拉伯语的位置形式 init/medi/fina/isol，当字体通过 GSUB 驱动它们时）、'clig'（上下文连字）、'calt'（上下文替代），以及 Indic 文本的整形功能 'pres' / 'blws' / 'psts' / 'half' / 'pstf' / 'cjct'。

SequenceLookupRecord 階層的なルックアップディスパッチャ：コンテキストルールが一致すると、SequenceLookupRecord の各エントリが、一致した入力サブシーケンス内の特定の場所で、階層的なルックアップを実行します。新しい _GSUBApplyNestedLookup ヘルパーは、GSUB LookupList を再開し、Extension ラッパーを透過的に解決し、Single (Type 1) / Multiple (Type 2) / Alternate (Type 3, 最初の代替) / Ligature (Type 4) アプライアにディスパッチします。ディスパッチャは、アクティブな MatchPositions[] インデックスを追跡するため、後続の SequenceLookupRecord エントリは、以前の複数の置換によって 1→N に展開された場合や、リガチャ置換によって N→1 のグリフが周囲に縮小された場合でも、正しい作業位置を参照し続けることができます。階層的な LookupType 5 / 6 / 8 (再帰的なコンテキスト) は、意図的に後回しにされます。ほとんどの実際のフォントでは、階層的なルックアップは Type 1 / 4 に関連付けられています。

一致が見つかった場合、メソッドはTrueを返し、InputGIDs[StartIndex..StartIndex+ConsumedLen-1]を置き換えるべき出力グリフシーケンスも返します。OutGIDsの長さは、ネストされた1→NまたはN→1のルックアップが実行された場合、ConsumedLenと異なる場合があります。ConsumedLenは、コンテキストルールが吸収した入力全体の範囲であり（重要なグリフ間のLookupFlagでスキップされたマークを含む）、通常、スキャンループの呼び出し元はConsumedLenだけ進み、OutGIDsを出力します。一致が見つからない場合は、False、空のOutGIDs、ConsumedLen = 1を返します。これは、v2.119.43-46ヘルパー関数と同じ、安全な何もしない動作です。LookupFlag（フェーズ4）は、コンテキストマッチ全体を通して適用され、バックトラック、入力、先読みの処理において、無視対象としてマークされたすべてのグリフをスキップします。この範囲では、スクリプト/言語システムはDFLTのデフォルト値のまま固定され、選択APIはフェーズ7の範囲です。

2026-05-22 Version 2.119.46

OpenType GSUB 扩展查找表（LookupType 7）：GSUB 引擎现在可以透明地解压扩展替换子表。这是一种纯粹的间接层，OpenType 规范为字体定义了这种机制，以处理那些实际替换子表超出 LookupList 中 Offset16 范围的超大型字体。所有 v2.119.43-45 公共 API（GetSingleSubstituteGlyph / GetMultipleSubstituteGlyphs / GetAlternateGlyphCount / GetAlternateGlyph / ApplyLigatureSubstitution）都会自动遵循 32 位的 Offset32 间接引用，以访问真实的 LookupType 1 / 2 / 3 / 4 子表。这是一个二进制布局的更改，它解决了大型 CJK / Indic OpenType 字体（例如 Noto Sans CJK、Noto Sans Devanagari 等）的问题，这些字体的 GSUB 表超过 64 KB，并且其查找表长期以来都隐藏在 LookupType 7 包装器中；以前，这些字体在 HotPDF 中看起来没有功能。

OpenType GDEF（字形定義）テーブルの解析：RegisterUnicodeTTFは、GDEFテーブルが存在する場合、フォントのGDEFテーブルをキャッシュするようになりました。3つのGDEFサブテーブルがLookupFlagの適用ロジックを制御します。GlyphClassDefは、各GIDを基本（1）、合字（2）、マーク（3）、コンポーネント（4）のいずれかに分類します。MarkAttachClassDefは、すべてのマーク字形にアタッチメントクラスを付与します。MarkGlyphSetsDef（v1.2以降）は、マーク字形の名前付きセットを宣言します。ClassDefのフォーマット1（startGlyphID + classValueArray）とフォーマット2（ソートされたclassRangeRecords）の両方が実装されています。GDEFのv1.0、v1.1、v1.2のヘッダーがすべてサポートされています（v1.3のitemVariationStoreは無視されます）。GDEFテーブルのないフォントは、v2.119.43-45のデフォルトの動作（「どの字形も無視されない」）に戻り、これにより、GDEFがないフォントを使用している呼び出し元に対して、バイト単位で同じ出力が維持されます。

OpenType GSUB LookupFlag の設定が反映されるようになりました。現在、GSUB のすべての公開 API が、各 Lookup テーブルの LookupFlag (および、LookupFlag.useMarkFilteringSet が設定されている場合のオプションの末尾の markFilteringSet uint16) を読み取り、無視対象としてマークされた入力グリフをスキップします。仕様で定義されたフラグビットが有効になります。具体的には、0x0002 は ignoreBaseGlyphs (GDEF.GlyphClassDef クラス 1 をスキップ)、0x0004 は ignoreLigatures (クラス 2 をスキップ)、0x0008 は ignoreMarks (クラス 3 をスキップ)、0x0010 は useMarkFilteringSet (名前付きの MarkGlyphSet 内のマークのみが対象)、そして上位バイトの markAttachmentType (要求された MarkAttachClassDef クラスを持つマークのみが対象) です。特に、リガチャ置換 (LookupType 4) の場合、これが重要になります。アラビア語の 'rlig' またはインドの 'akhn' リガチャで、構成要素がマークグリフで区切られている場合 (例: LAM + Fatha + ALEF) 、LookupFlag.ignoreMarks が設定されている場合でも、正しく一致するようになります。また、返される ConsumedCount にはスキップされたマークが含まれるため、呼び出し元のスキャンループは、吸収されたすべての入力グリフをスキップして進みます。ビット 0x0001 (rightToLeft) は GPOS に固有であり、GSUB のルックアップでは引き続き無視されます。

変更内容は以下の通りです。フォントにGSUBテーブルがない場合、呼び出し元が4バイト以外のタグを渡した場合、フォントのDFLTスクリプトで広告されていない機能を使用した場合、サブテーブルでカバーされていないGIDの場合、およびLookupFlagを無視した入力グリフの場合、すべてv2.119.43-45の安全な動作を行います。5つの公開APIのインターフェースはバイト単位で安定しており、内部のルックアップ処理では、拡張機能の適用、LookupFlagの適用、およびGDEFの分類が行われます。スクリプト/言語システム選択API、自動整形パイプラインの統合、およびTTFサブセッターによる代替グリフの自動取得は、今後のバージョンで実装される予定です。

2026-05-22 Version 2.119.45

OpenType GSUB連字置換（LookupType 4）：新的THotPDF.ApplyLigatureSubstitution (const InputGIDs: 字符数组; StartIndex; FeatureTag; out OutGID; out ConsumedCount): Boolean 将一个多字形组件序列折叠成单个连字字形。常用的用户包括 'liga'（标准连字 - fi / fl / ffi / ffl）、'clig'（上下文连字）、'dlig'（可选连字）、'hlig'（历史连字）、'rlig'（强制连字 - 例如阿拉伯语LAM-ALEF及其类似字形，当字体通过GSUB进行字形塑造时），以及Indic脚本的连字特征（'akhn'、'pres'、'blws'、'psts'）。调用者传递一个post-cmap字形ID序列和一个基于0的起始位置；如果完全匹配，则辅助函数返回True，OutGID = 连字替换字形，ConsumedCount = 消耗的输入组件总数（实际上>= 2）。如果没有匹配，则返回False，OutGID = 0，ConsumedCount = 1，以便调用者可以前进一步并继续扫描。该实现遵循OpenType的约定，即连字集条目通常按最长优先排序，以便具有重叠前缀的字体（例如，一个三组件'ffi'连字和两个组件'ff'连字）可以获得更长的匹配。与v2.119.43/.44辅助函数相同的防御性机制：空/非4字节标签、没有GSUB、未声明的特征、StartIndex超出范围，以及在指定位置没有找到LookupType 4子表，所有这些情况都返回安全的无操作（False / OutGID = 0 / ConsumedCount = 1）。LookupFlag标记跳过、GDEF GlyphClassDef集成、文本输出时的自动应用以及TTF子集器自动提取连字字形，这些功能保留用于未来的修订。

2026-05-22 Version 2.119.44

OpenType GSUB 複数置換 (LookupType 2): 新しい THotPDF.GetMultipleSubstituteGlyphs (InputGID, FeatureTag, var OutGIDs) は、1つの入力グリフを、置換グリフのシーケンスとして返します。この機能の主要な用途は、'ccmp' グリフ合成/分解機能であり、これは、あらかじめ合成されたラテン文字を、ベース文字とそれに続く結合文字に分割し、後続の文字位置調整を可能にします。この処理は、v2.119.43 の GetSingleSubstituteGlyph と同様の DFLT スクリプト/デフォルト言語システム/機能リスト/ルックアップリストのパスをたどり、要求された機能に関連付けられたすべての LookupType 2 サブテーブルを InputGID に対して適用し、最初に一致したものが採用されます。 OutGIDs は、呼び出し元が事前にクリアする必要がないように、初期化時にリセットされます。仕様で許可されている空のシーケンス (glyphCount = 0、Unicode 標準のグリフ削除) は、Result = True で、Length(OutGIDs) = 0 として報告され、これにより、呼び出し元は入力グリフをシーケンスから削除できます。

OpenType GSUB 替代字形替换（LookupType 3）：两个新的方法公开了用于样式特征的完整替代字形循环。THotPDF.GetAlternateGlyphCount (InputGID, FeatureTag) 返回字体为 InputGID 在 FeatureTag 下提供的替代字形的数量，而 THotPDF.GetAlternateGlyph (InputGID, FeatureTag, AlternateIndex) 返回请求的基于 0 的索引处的替代字形。常用的功能包括 'aalt'（访问所有替代字形）、'salt'（样式替代字形）、'titl'（标题字形），以及 'ss01' 到 'ss20'（样式集 1-20），当与 LookupType 3 配合使用时，而不是 LookupType 1。在 v2.119.43 版本中，GetSingleSubstituteGlyph 会静默地跳过这些子表，因此之前使用 'aalt' 的调用者只能看到 LookupType 1 的传递式替换。这两个功能允许调用者显式地遍历装饰性字形循环（不同的 'a' / 'g' / '7' 形状）、标题字形变体和样式集替代字形。如果 AlternateIndex 超出范围或为负数，则返回 InputGID 不变，以便调用者可以安全地进行探测。

両方のヘルパー関数は、v2.119.43 と同じ安全対策を適用します。具体的には、GSUB テーブルのないフォント、4 バイト以外のタグを渡す呼び出し元、フォントの DFLT スクリプトで広告されていない機能、および LookupType 2 / 3 サブテーブルでカバーされていない GID の場合、安全な何もしない動作 (Multiple の場合は False + 空の OutGIDs、Alternate の場合は 0 / InputGID) を返します。このバージョンでは、機能のルックアップチェーンで見つかった LookupType 1 / 4-8 サブテーブルは、エラーを発生させずにスキップされます。LookupFlag によるフィルタリング、GDEF GlyphClassDef の統合、スクリプト / LangSys 選択 API、自動シェーピングパイプラインの統合、および TTF サブセッターによる選択された代替グリフの自動取り込みは、今後のバージョンで実装される予定です。呼び出し元は、引き続き、選択したグリフを埋め込みフォントのサブセットにマークする必要があります。

2026-05-22 Version 2.119.43

OpenType GSUB 样式替代查找：新的 THotPDF.GetSingleSubstituteGlyph (InputGID, FeatureTag) 函数，它遍历字体的 GSUB ScriptList / FeatureList / LookupList 链，在 DFLT 脚本的默认 LangSys 下，应用所有与请求的特征相关的 LookupType 1 (单字替换) 子表，并返回替换后的字形 ID。最常见的样式替代特征标签包括 'salt' (样式替代)、'ss01' 到 'ss20' (样式集 1-20)、'aalt' (访问所有替代字形)、'titl' (标题替代字形)、'subs' / 'sups' (下标 / 上标)、'frac' (分数) 和 'ordn' (序数)；支持任何包含 LookupType 1 子表的 4 字节 OpenType 特征标签。Coverage Format 1 (排序的字形数组，使用二分查找) 和 Format 2 (范围记录) 都被支持。单字替换的 Format 1 (增量) 和 Format 2 (替换数组) 都已实现。RegisterUnicodeTTF 现在缓存 GSUB 表的偏移量/长度，与 cmap 一起，以便在查询时避免重新扫描表目录。对于没有 GSUB 表的字体，或者调用者传递的 4 字节标签是字体 DFLT 脚本未声明的，以及不在查找 Coverage 中的 GID，都将返回未更改的 InputGID，因此该 API 可以安全地作为一种最佳努力的替换或直通方式调用。在特征的查找链中遇到的 LookupType 2-8 子表，将在本次更新中静默地跳过——多重替换/替代替换/连字替换/上下文链以及自动整形管道集成，将在未来的版本中实现。

2026-05-22 Version 2.119.42

AcroForm /DR リソースは、複数の Unicode フォントをサポートするようになりました。v2.56.0 以降、SetFormUnicodeFontDict は、AcroForm の /DA デフォルトとして使用される、ユーザーが指定したフォントのみを追跡します。そのため、フィールドごとに異なるスクリプトが必要な多言語フォーム（1 つの PDF 内でアラビア文字、CJK 文字、ラテン文字を使用するなど）では、/DR /Font ディクショナリを手動で作成する必要がありました。新しい THotPDF.RegisterAcroFormFont (LogicalName, FontDict) 関数は、任意の論理名で追加の Unicode フォントを登録し、フィールドごとの /DA 文字列（/ 12 Tf）で使用できるようにします。また、登録されたフォントは、v2.56.0 のデフォルトフォントとともに、AcroForm の /DR /Font ディクショナリにエミットされます。登録順序は維持されるため、生成される /DR は決定論的です。SetFormUnicodeFontDict のデフォルトまたは以前に登録されたフォントとの名前の衝突が発生した場合、問題のある名前でエラーが発生します。空の論理名または nil の FontDict の場合も同様のエラーが発生します。SetFormUnicodeFontDict ('', nil) を使用してリセットすると、追加フォントの登録もクリアされるため、クリーンな状態から Unicode ワークフローを開始できます。これは、すべての PDF/A および PDF/X レベルで許可されています。複合 Unicode フォントは、インタラクティブなスクリプトではなく、構造的なフォームメタデータです。

2026-05-22 Version 2.119.41

PDF 1.7 §14.8.4 表 333 定义的标准结构类型枚举：新的 THPDFStandardStructureType 枚举列出了约 40 个由规范定义的结构角色，并根据其 PDF 角色分组（分组：Document / Part / Art / Sect / Div / BlockQuote / Caption / TOC / TOCI / Index / NonStruct / Private；块级：H / H1-H6 / P / L / LI / Lbl / LBody / Table / TR / TH / TD / THead / TBody / TFoot；行内级：Span / Quote / Note / Reference / BibEntry / Code / Link / Annot；Ruby + Warichu：Ruby / RB / RT / RP / Warichu / WT / WP；插图：Figure / Formula / Form）。两个单元级辅助函数将枚举转换为与规范完全匹配的 PDF 名称：StandardStructureTypeToName (T) 返回用作结构元素 `/S` 键的区分大小写的名称，IsStandardStructureType (Name) 测试任意 AnsiString 是否与标准集匹配，以便调用方可以预先检查自定义角色名称，并在需要时将其通过 AddStructRoleMap 路由。一个新的 AddStructureElement 枚举重载直接接受 THPDFStandardStructureType，从而消除了开放字符串重载中的拼写错误/大小写敏感性问题（例如，'Para' 与 'P'、'Lbody' 与 'LBody'），同时转发到相同的基本实现。现有的基于 AnsiString 的重载保持字节相同，以便使用自定义或 RoleMap 路由名称的调用方。

2026-05-22 Version 2.119.40

構造要素属性設定器：新たに3つのヘルパー機能が追加され、v2.88.0の/Altおよび/ActualText、およびv2.95.0の/IDに関連する、各要素のPDFテキスト属性を埋めます。THotPDF.SetStructureElementLanguage (Elem, BCP-47 Lang)は、PDF 1.7 §14.9.2の/Langを書き込み、この要素以下のコンテンツのドキュメント全体のデフォルト言語を上書きします。これは、別の言語での引用や、異なる文字体系が混在するセクションなど、一般的な使用例です。THotPDF.SetStructureElementExpansionText (Elem, ExpansionText)は、§14.9.5の/Eを書き込みます。これは、スクリーンリーダーが略語の代わりに読み上げる、略語の展開（例：「NASA」→「National Aeronautics and Space Administration」）であり、コンテンツ抽出によって取得される値です。THotPDF.SetStructureElementTitle (Elem, Title)は、§14.7.5.2の/Tを書き込みます。これは、構造ツリー内の同じ役割を持つ要素を区別するための、人間が読めるタイトルです（Acrobatのタグペインでは、/Tが役割名の横に表示されます）。これら3つはすべて、空の値の場合には何もしない単純な設定関数であり、nil-Elemの場合にはエラーが発生し、キーが構造メタデータであるため、すべてのPDF/AおよびPDF/Xレベルで使用できます。

2026-05-22 Version 2.119.39

AcroForm 表单字段触发器功能完善：三个新的辅助程序加入 AttachFieldKeyStrokeAction (v2.119.37)，以关闭 PDF 1.7 §12.7.5.3 表 246。THotPDF.AttachFieldFormatAction 安装 /AA /F（格式事件，当字段的显示值需要重新格式化后触发——常见的用途是应用货币、日期或千位分隔符掩码，通过 AFNumber_Format / AFDate_FormatEx）。THotPDF.AttachFieldValidateAction 安装 /AA /V（验证事件，在用户提交新值后触发——常见的用途是进行范围检查或通过 event.rc := false 进行正则表达式验证）。THotPDF.AttachFieldCalculateAction 安装 /AA /C（计算事件，当任何依赖字段发生变化时触发，顺序由 Catalog /AcroForm /CO 计算顺序决定——常见的用途是汇总总计或计算税款）。这四个包装器都共享相同的 FFormFields /T 查找，并且具有幂等的“最后一次调用生效”的替换语义，以及 PDF/A + PDF/X JavaScript 保护。在同一个 /AA 字典中的其他触发器键（包括 /E /X /D /U /Fo /Bl 注释触发器以及这三个兄弟表单字段触发器）保持不变。内部重构：AttachFieldKeyStrokeAction 现在委托给一个共享的 _InstallFieldTriggerJSAction 辅助程序；现有的 v2.119.37 调用者将看到字节完全相同的异常消息。

2026-05-22 Version 2.119.38

RegisterUnicodeTTF 现在可以从加载的字体的 cmap 格式 12 子表中捕获补充多语言平面 (SMP，U+10000-U+10FFFF) 码位到字形的映射。在之前的版本中，SMP 条目会被静默地忽略，因为码位到字形的查找是一个 BMP 尺寸的数组。 v2.119.38 添加了一个并行稀疏列表 (FUnicodeCpToGidSMP)，该列表与 BMP 数组并行填充。新的公共方法 GetUnicodeGlyphForCodepoint(Cp) 返回任何 Unicode 码位（最多 U+10FFFF）的字形 ID（对于高于 BMP 的码位，会使用二分查找 SMP 列表），如果码位在加载的字体的 cmap 中没有映射，则返回 0（.notdef）。这仅是一个功能增强：生成器端的十六进制编码管道、/CIDToGIDMap 流以及 ToUnicode CMap 仍然以 BMP 为基础，因此，要将 SMP 字符写入 PDF 文本流，调用方仍然需要自行发出 UTF-16BE 代理对。全面的、支持代理对的文本流输出将在未来的版本中实现。仅支持格式 4 的字体将获得一个空的 SMP 列表，这符合预期。

2026-05-22 Version 2.119.37

新しいAcroFormキー入力トリガーヘルパー：`THotPDF.AttachFieldKeyStrokeAction(FieldName, JavaScriptBody)` 通过其 `/T` 值定位指定的表单控件，并安装一个 `/AA /K` JavaScript 动作，以便 PDF 阅读器在文本输入期间的每次按键时触发该脚本。常见用途包括实时输入验证（数字/日期/正则表达式）、输入掩码以及由另一个字段的编辑触发的计算字段更新。此辅助程序是幂等的：重复调用会替换 `/K` 条目，同时保留任何其他触发器键（例如 `/F` 格式、`/V` 验证、`/C` 重新计算、`/Bl` 模糊、`/Fo` 焦点等），这些键已存在于同一 `/AA` 字典中。无论 PDF/A 的哪个级别（ISO 19005-1 §6.6.1，-2/-3 §6.5.1）或 PDF/X 的哪个级别（ISO 15930 预印制），都禁止 JavaScript 动作，因此如果任何合规性标志不为空，则此辅助程序将立即引发错误，并提供相关的规范引用。此功能基于 PDF 1.7 §12.6.3 触发事件字典以及 §12.7.5.3 表 246 表单字段的 `/K` 键。

2026-05-22 Version 2.119.36

`BeginTaggedContent` 现在接受四个可选的 PDF 1.7 §14.8.4 表 322 标记内容序列属性（`Lang` / `Alt` / `ActualText` / `ExpansionText`），并将它们作为单个内联 BDC 属性字典一起输出，与现有的 MCID 条目一起。`Lang` 携带 BCP-47 自然语言标签，用于文本朗读器和支持语言的文本提取；`Alt` 是非文本或装饰性文本的替代描述；`ActualText` 是内容提取和复制粘贴中使用的替换文本，用于代替可见的字形序列（对于连字和特殊字形至关重要，因为可见字符与底层的语义文本不同）；`ExpansionText` 包含用于扩展缩写的 `/E` 键。如果参数为空，则跳过相应的条目，因此内联字典仅包含调用者显式填充的键，并且旧的两个参数调用方式与 v2.119.35 的输出完全相同。PDF 字符串字面量转义（括号和反斜杠）是自动进行的；对于非 ASCII 负载（例如 CJK `ActualText`、Indic `Alt` 等），调用者需要预先将字节编码为 UTF-16BE，并带有 U+FEFF BOM，并将结果打包到 `AnsiString` 参数中。还公开了匹配的低级页面流 API `BeginMarkedContentMCIDProps`，供需要直接控制 BDC 但不需要高层 `StructElem` 结构的调用者使用。

2026-05-22 Version 2.119.35

Arabic Extended-A 核心 9 个字母的波斯语/乌尔都语子集现在参与到 v2.85.0 版本中的生产者端四位置整形器中。启用 AutoShapeArabic 后，以下字母会映射到其 U+FB50-U+FBFF Arabic Presentation Forms-A 字形，使用的连接上下文算法与基本阿拉伯语块相同：PEH U+067E、TCHEH U+0686、JEH U+0698、KEHEH U+06A9、GAF U+06AF、FARSI YEH U+06CC（波斯语核心），以及 TTEH U+0679、DDAL U+0688、RREH U+0691（乌尔都语后置核心）。双连接字母会显示完整的孤立/最终/初始/中间集合；右连接字母（JEH / DDAL / RREH）仅显示孤立/最终，这符合阿拉伯语整形模型。其他 Arabic Extended-A 字母（ALEF WASLA U+0671、NOON GHUNNA U+06BA、HEH 变体 U+06C0-U+06C3、完整的阿拉伯语补充 U+0750-U+077F）仍然保持不变，并将推迟到未来的版本。非波斯语/乌尔都语的阿拉伯文本与 v2.119.34 的输出完全相同。

2026-05-22 Version 2.119.34

PDFの名前の処理において、PDFオブジェクトのインポートまたはコピー時に、ISO 32000-1の#XXエスケープシーケンスをデコードするようになりました。リソース名、スポットカラー名、構造ロール名、および/PANTONE#20216#20CVCのようなその他の名前オブジェクトは、意図されたバイト値でHotPDFを通過し、以前のように二重のエスケープ文字付きの数値記号でコピーされることはありません。

2026-05-22 Version 2.119.33

PDFの日付処理が、より厳密にISO 32000-1の日付文字列ルールに準拠するようになりました。ドキュメント情報、XMPから取得した日付、および署名タイムスタンプでは、現在時刻を自動的に置き換える代わりに、呼び出し元が提供するTDateTimeを使用します。一方、パーサーは、ローカルの日付/時刻フィールドを破損することなく、標準的なオプションの日付フィールドとタイムゾーンのサフィックスを受け入れます。

PDFインポートフィルタの処理において、明示的なASCIIHexDecode、ASCII85Decode、およびRunLengthDecodeヘルパーが追加され、LZWDecodeのデフォルトのEarlyChange値が、PDFのデフォルト値である1に一致するように変更されました。これにより、レガシーPDFストリームフィルタを使用しているインポートまたはコピー元のページとの互換性が向上します。

2026-05-21 Version 2.119.32

アラビア文字のLAM-ALEFの必須リガチャ化処理が、v2.85.0のレンダリングエンジンに組み込まれました。AutoShapeArabicが有効な場合、U+0644 LAM（そのままの形式またはその4つの形状形式FEDD-FEE0）の後に、4つのALEFのバリエーション（MADDA U+0622、HAMZA-above U+0623、HAMZA-below U+0625、プレーン U+0627。そのまままたは形状化後の形式）が続く場合、U+FEF5-U+FEFCブロックからの単一のリガチャグリフに変換されます。LAMが最終形（FEDE）または中間の形（FEE0）に形状化されているかどうかに基づいて、連結形と分離形のリガチャが選択されます。他のアラビア文字の必須リガチャ（Allah U+FDFBおよび装飾的な敬称リガチャ）は、引き続きフルGSUBエンジンが必要であり、静的なテーブル形状化モデルの範囲外です。LAM-ALEF以外のテキストと、AutoShapeArabicが無効な場合の動作は、v2.119.31の出力と同一です。3つのAcroForm Unicode /APヘルパー（単一行、複数行、コンビネーション）は、共通の_ApplyArabicShapingエントリーポイントを通じて、この変更を自動的に継承します。

2026-05-21 Version 2.119.31

新しいDevExpress ExpressPrintingシステムのエクスポートアダプター：`dxHotPDFExportReportLinkToFile` / `dxHotPDFExportReportLinkToStream`は、任意の`TBasedxReportLink`（cxGrid、cxRichEdit、cxScheduler、cxPivotGridなどの印刷可能なコンポーネントと`TdxComponentPrinter`を接続する抽象リンクファミリー）を受け取り、各レンダリングされたページをDevExpress独自の`dxPSExportToPDF`エミッターの代わりにHotPDF経由で処理します。このアダプターは、DevExpressの内部エクスポートループを模倣しています。具体的には、レポートを再構築し、各ページに対して、`TMetafileCanvas`上にページを描画し、それをHotPDFに`ShowEnhancedMetafile`で出力します。オプションには、タイトル、作成者、件名、キーワード、PDFバージョン、圧縮、レンダリングDPIなどが含まれます。FastReport、QuickReport、ReportBuilderアダプターと同様に、このアダプターにもメタファイルブリッジの制限があります。AcroFormフィールド、アウトライン、PDF/A/PDF/Xのサポートはありません。このアダプターは`Lib/Addons/DevExpress/`ディレクトリにあり、メインの`HotPDF*.dpk`には含まれていません。

2026-05-20 Version 2.119.30

新しいレポートビルダーデバイスクラス：`TppHotPDFDevice`は`TppGraphicsDevice`を継承しており、`TppReport.PrinterDevice`または`TppPublisher.Device`に割り当てられると、レポートビルダーの標準的なパブリッシャー→デバイスのチェーンに組み込まれます。各ページは一時的な`TMetafileCanvas`（`BeforeRenderPage`で作成され、`AfterRenderPage`で最終化される）にレンダリングされ、`TMetafile`としてキャプチャされ、HotPDFのEMFインポーター（`HPDFEmf.ShowEnhancedMetafile`）を介して処理されます。プロパティには、タイトル、作成者、件名、キーワード、PDFバージョン、圧縮レベル、および圧縮設定が含まれます。`SetOutputStream`メソッドは、PDFバイトを呼び出し元が提供する`TStream`に送信します。FastReport/QuickReportアダプターと同様のメタファイルブリッジの制限があります。AcroFormフィールド、アウトライン、およびPDF/A/PDF/Xのサポートはありません。このアダプターは`Lib/Addons/ReportBuilder/`ディレクトリにあり、メインの`HotPDF*.dpk`には含まれていません。

2026-05-20 Version 2.119.29

新しいQuickReportエクスポートフィルタ：`TQRHotPDFExportFilter`は`TQRExportFilter`を継承しているため、既存の`MyReport.ExportToFilter(MyFilterInstance)`ワークフローに統合できます。このアダプタは、QuickReportがすでに`QRPrinter.PageList`にキャッシュしているページごとのメタファイルを収集し、HotPDFのEMFインポーター（`HPDFEmf.ShowEnhancedMetafile`）に渡します。プロパティでタイトル、著者、件名、キーワード、PDFバージョン、圧縮レベル、圧縮設定が可能です。`SetOutputStream`メソッドは、PDFのバイトデータをディスクではなく、呼び出し元が提供する`TStream`に送信します。このアダプタは、FastReportアダプタと同様のメタファイルブリッジの制限があります。AcroFormフィールド、アウトライン、PDF/A/PDF/Xのサポートはありません。このアダプタは`Lib/Addons/QuickReport/`ディレクトリにあり、メインの`HotPDF*.dpk`には含まれていません。

2026-05-20 Version 2.119.28

新しいFastReport 4 / FastReport VCLエクスポートアダプター：`TfrxHotPDFExport`は`TfrxCustomExportFilter`を継承しているため、FastReportのコアを変更することなく、通常の`MyReport.Export(MyExportInstance)`ワークフローに統合されます。このアダプターは、各準備されたページをHotPDFのEMFインポーター（FastReportの`TfrxPreviewPages.DrawPage → TMetafileCanvas → HotPDF.ShowEnhancedMetafile`経由）に渡し、FastReportの標準レイアウトエンジンによってレンダリングされたベクトルおよびラスターのページコンテンツを、オブジェクトごとのコードを生成することなく保持します。プロパティを通じて、タイトル、作成者、件名、キーワード、PDFバージョン、圧縮レベル、レンダリングDPIを制御できます。制限事項：AcroFormフィールド、アウトライン、PDF/A / PDF/X機能はありません（これらはオブジェクトごとの生成パイプラインが必要で、将来のバージョンで実装予定です）。このアダプターは`Lib/Addons/FastReport4/`に同梱されており、メインの`HotPDF*.dpk`には含まれていません。ユーザーは、対応するFastReportパッケージとともに、このアダプターを独自のプロジェクトに追加する必要があります。

2026-05-20 Version 2.119.27

THotPDF.SignPDFWithPFX(InputPDFPath, OutputPDFPath, PFXFilePath, Password) 实现了基于 PFX 的全新端到端 PDF 签名功能。该函数加载已包含 AddSignedSignatureField 占位符的未签名 PDF 文件，解析 PFX / PKCS#12 文件，构建完整的 CMS SignedData (RFC 5652)，并将签名后的 PDF 文件写入，所有操作在一个调用中完成。此外，还提供了一个基于 TStream 的重载版本，以支持内存中的工作流程。PDF 的 /Contents 预算必须足够大，以容纳 CMS DER 十六进制数据；默认的 8192 字节可以覆盖 1024 / 2048 位的 RSA 密钥。仅支持 PBES2 + AES-256-CBC 格式的 PFX 文件（v2.119.26 PKCS#12 解析器的限制）。

新しいHPDFCMSユニット：CMS SignedDataビルダー。HPDFCMSBuildSignedDataは、ContentInfoからSignedData、そしてSignerInfoを構築し、id-dataによる分離されたコンテンツ、contentType、messageDigest、およびsigningTime（RFC 5652 §5.4に従ってDER昇順にソート）で属性を署名します。IssuerAndSerialNumberは、X.509証明書から抽出された署名者識別子であり、RSA + SHA-256の署名アルゴリズムを使用し、X.509証明書を[0]の暗黙的な証明書でラップします。また、ストリーミングされた二窓ダイジェストのためのHPDFCMSSHA256ByteRangesと、/Contentsプレースホルダーの挿入のためのHPDFCMSBytesToHexも提供します。これは、HPDFASN1 (v2.119.23)、HPDFRSA (v2.119.24)、HPDFCrypt拡張機能 (v2.119.25)、およびHPDFPFX (v2.119.26)で開始された、内部の署名スタックを完了するものです。

2026-05-20 Version 2.119.26

新しいHPDFPFXユニット：PKCS#12/PFXコンテナパーサー。OpenSSL 3.0以降、Windows 11以降のcertutil、およびmacOSのKeychain Accessから.pfx/.p12ファイルを読み込み、PBES2（PBKDF2-HMAC-SHA-256 + AES-256-CBC）で暗号化されたSafeBagペイロードを復号し、X.509証明書のDER形式データとRSA秘密鍵のパラメータを抽出します。結果として得られるTHPDFPFXKeyMaterialレコードには、CertDER、Modulus、PublicExponent、PrivateExponentが含まれており、これにより、下流のCMS/署名コードが直接利用できます。パスワードが間違っている場合、PKCS#7のパディング解除エラーによって検出されます。古いPBE-SHA1-3DESファイルの場合、`-keypbe AES-256-CBC -certpbe AES-256-CBC`オプションを使用して再エクスポートすることを推奨します。

2026-05-20 Version 2.119.25

新しい暗号化機能を追加しました。AES-256 の逆置換（AES256DecryptBlock + AES256CBCDecryptPKCS7 + AES256CBCDecryptNoPad、FIPS-197 §5.3、既存の暗号化機能の補完）、HMAC-SHA-256（RFC 2104）、および PBKDF2-HMAC-SHA-256（RFC 8018 §5.2）が含まれます。これらの機能は、RFC 4231 の HMAC ベクトルおよび標準的な PBKDF2-SHA-256 の出力結果に対して検証されています。さらに、v2.119.23 の ASN.1 デコーダーと v2.119.24 の RSA 機能と合わせて、最新の（OpenSSL ≥ 3.0 / Windows 11 以降）PKCS#12 / PFX ファイルで使用される PBES2-AES-256 SafeBag デクリプションに必要な暗号化基盤が完成しました。

2026-05-20 Version 2.119.24

新しいHPDFRSAモジュール：多精度整数演算、RSAモジュラー指数演算、およびPKCS#1 v1.5 EMSAエンコーディング。実世界の2048/4096ビットRSAキーで署名できる十分な大きさです。v2.119.23で追加されたASN.1デコーダと合わせて、今後のライブラリ内PFXベースのPDF署名パイプラインに必要な暗号化プリミティブがすべて揃いました。現時点では、ユーザー向けのAPIではまだこれを使用していません。これは、PKCS#12およびCMSレイヤーが実装されるのを待っている内部インフラストラクチャです。

2026-05-20 Version 2.119.23

新しいHPDFASN1ユニット：これは、ASN.1のサブセットをデコードするためのコンパクトなBER/DERデコーダで、HotPDFが必要とするPKCS#12キーストア、X.509証明書、およびCMS/PKCS#7署名データコンテナの読み取りに使用されます。THPDFASN1Node（解析されたタグ-長-値記述子）、THPDFASN1ParseNode / ParseAt、Content / ToInteger / ToBigInt / ToOID / ToStringアクセッサ、およびFirstChild / NextSibling / Childrenイテレータを公開します。DERの厳格なサブセットを反映し、不定長のBER形式および高いタグ番号（>= 31）のエンコーディングを明示的に拒否します。これは、今後のリリースで導入される、ライブラリ内のPFX署名パイプラインのための内部インフラストラクチャであり、現時点ではユーザー向けのAPIはこれに依存していません。

2026-05-20 Version 2.119.22

THPDFPage.AddPolylineAnnotation および AddPolygonAnnotation に、完全なメタデータに対応した新しいオーバーロードが追加されました。これらのオーバーロードは、THPDFCurrPoint 頂点の配列と、オプションの THPDFPolyExtras レコードを受け入れます。この追加レコードでは、ISO 32000-1 §12.5.6.9 で規定されているオプション項目（/IC：内部色、/BE：雲のような境界線（/besSolid または /besCloudy で指定、/I：強度）、/IT：意図（PolyLineDimension、PolyLineFlight、PolygonCloud、PolygonDimension）、および /LE：線の終端スタイル（PolyLine の場合））を公開します。ゼロ初期化されたレコードを使用するには、HPDFDefaultPolyExtras() を使用してください。新しいオーバーロードでは、少なくとも 2 つの頂点が指定されていることを検証し、意図に応じてドキュメントのバージョンを自動的に更新します（PDF 1.5 / 1.6 / 1.7）。以前のインターリーブされた Single オーバーロードは、変更なしで引き続きコンパイルできます。

2026-05-20 Version 2.119.21

新しいライン注釈機能：`AddLineAnnotation` に、オプションの PDF 1.6/1.7 §12.5.6.7 表 175 のエントリを制御する `THPDFLineExtras` レコードを受け取る、3 つ目のオーバーロードが追加されました。これには、/IC（塗りつぶされた矢印、ひし形など）、/LL（リーダーラインの長さ）、/LLE（リーダーの拡張）、/LLO（リーダーのオフセット、PDF 1.7）、/Cap（キャプションフラグ、/CP（配置：/Inline または /Top、PDF 1.7）+ /CO（キャプションのオフセット）、および /IT（意図：LineArrow / LineDimension）が含まれます。`HPDFDefaultLineExtras()` を使用して、ゼロ初期化されたレコードから開始します。新しいオーバーロードは、ドキュメントのバージョンを自動的に PDF 1.6（または /LLO、/CP、/CO が要求された場合は PDF 1.7）に引き上げます。以前の 2 つのオーバーロードは、引き続きバイト単位で同一の出力を生成し、呼び出し元が実際に要求するエントリのみが書き込まれます。

2026-05-20 Version 2.119.20

THPDFButtonAction 现在包含 baShow（与 baHide 镜像，它会发出 /H false 以重新显示隐藏的控件）和 baImportData（/S /ImportData /F 文件名，用于在单击时加载 FDF 表单数据，符合 ISO 32000-1 §12.7.5.4）。baShow 在 PDF/A 和 PDF/X 标准中是允许的；而 baImportData 则在 ISO 19005-1 §6.6.1 和 ISO 15930 预印制标准中均被禁止。

新しい多重フィールドの非表示/表示機能が追加されました：`THPDFPage.AddPushButtonWithHideAction(FieldName, Caption, Targets, Hide, Rectangle, Flags)`。この関数は、ターゲットとなるフィールド名の配列と、明示的な非表示フラグを受け取り、これにより、1回のクリックで複数のウィジェットの表示/非表示を切り替えることができます。ターゲットフィールドの配列が空の場合、エラーが発生します。PDF/AとPDF/Xの両方で、この機能（ウィジェットの表示/非表示のみ）を使用できます。

2026-05-20 Version 2.119.19

新しいSubmitForm /Flagsユーザーコントロール：THPDFPage.AddPushButtonWithSubmitAction(FieldName, Caption, URL, Rectangle, SubmitFlags)により、ISO 32000-1 §12.7.5.2の表237で定義されたすべてのフラグセットが、新しいTHPDFSubmitFormFlags型を通じて利用できるようになりました。呼び出し元は、sffExportFormatHTML、sffXFDF、sffSubmitPDF（送信形式）、sffGetMethod（HTTP GETとPOST）、sffIncludeAnnotations、sffSubmitCoordinates、sffCanonicalFormat、sffIncludeNoValueFields、sffIncludeAppendSaves、sffExclNonUserAnnots、sffEmbedFormなど、以前のbaSubmitURLパスでハードコーディングされていた/Flags 0（FDF + POST）を置き換えることができます。既存のAddPushButtonWithAction(.., baSubmitURL, ..)は、バイトレベルでの互換性のために、引き続き/Flags 0を生成します。 baSubmitURLと同様に、PDF/Aでは許可され、PDF/Xではブロックされます。

2026-05-20 Version 2.119.18

拡張されたプッシュボタンアクションタイプ：THPDFButtonAction には、baNamed と baHide が追加されました。baNamed は、/S /Named /N アクションを生成します (ISO 32000-1 §12.6.4.11)。これは、標準のナビゲーションコマンドである NextPage、PrevPage、FirstPage、LastPage (PDF/A では、ISO 19005-1 §6.6.1 によると、これらすべてが許可されています) および、Print や SaveAs などの Acrobat 拡張機能に適しています。baHide は、/S /Hide /T /H true アクションを生成します (§12.6.4.10)。これにより、ボタンがクリックされたときに、名前付きのフォームフィールドが非表示になります。これらのアクションタイプは、PDF/A および PDF/X で許可されています。baJavaScript、baResetForm、baSubmitURL のみ、既存の準拠要件を維持します。

2026-05-20 Version 2.119.17

新しい名前付き参照先レジスタ：`THotPDF.RegisterNamedDestination(Name, PageIndex, FitMode, ...)` は、カタログの `/Names` および `/Dests` 名前ツリー (ISO 32000-1 §12.3.2.3) にシンボリックな参照先を登録します。これにより、`GoTo` / `GoToR` アクションやアウトラインの `/Dest` エントリは、ページ番号を直接記述する代わりに、名前で参照先を参照できるようになり、ページ挿入/削除/並べ替えによる参照の不安定化を防ぎます。新しい `THPDFDestinationFitMode` 列挙型は、仕様で定義されているすべての8つの適合モード (XYZ, Fit, FitH, FitV, FitR, FitB, FitBH, FitBV) をカバーします。このメソッドは、`Name` が空の場合、`PageIndex` が範囲外の場合、および `Name` が重複している場合にエラーを発生させます。必要に応じて、ドキュメントのバージョンを自動的に PDF 1.2 に引き上げます。 PDF/A / PDF/X の制限はありません。ナビゲーション支援機能は、すべてのプロファイルで仕様上許可されています。

2026-05-20 Version 2.119.16

新しい注釈機能：/LE 行末スタイル：THPDFPage.AddLineAnnotation に、行の開始/終了スタイルを受け入れるオーバーロードが追加されました。新しい THPDFLineEndingStyle 列挙型により、ISO 32000-1 §12.5.6.7 の表 176 で定義されているすべてのスタイルが利用可能です。スタイルには、None、Square、Circle、Diamond、OpenArrow、ClosedArrow、Butt、ROpenArrow、RClosedArrow、Slash が含まれます。これにより、Adobe Acrobat や Foxit などの環境で、線注釈を適切な矢印、寸法マーカー、またはポインターとしてレンダリングできるようになり、ホスト側で手動で矢印の頭を作成する必要がなくなりました。以前の 4 パラメータのオーバーロードは、引き続き同じ動作で利用可能です。

2026-05-20 Version 2.119.15

THPDFDocOutlineObject が、Color、Bold、および Italic プロパティを公開するようになりました (ISO 32000-1 §12.3.3 表 153 /C および /F)。アウトラインパネルで、ブックマークを色付きで表示したり、太字またはイタリックで強調表示したりできるようになり、章のグループ化、未完了または注意が必要なセクションの強調、およびブランドスタイルの統一に役立ちます。色のデフォルトは clNone (何も出力されないため、以前の出力とバイト単位で同じ) であり、Bold と Italic のデフォルトは false です。AddChild を呼び出した後にプロパティを設定すると、ライブのアウトライン辞書がその場で更新されます。Color を clNone に戻すか、Bold と Italic を両方とも false に設定すると、/C および /F エントリが削除されます。

2026-05-20 Version 2.119.14

THotPDF 现在提供了 RegisterDocumentJavaScript(Name, Body) 函数，用于创建新的文档级别命名 JavaScript 注册表。每个注册的条目都序列化到 Catalog /Names /JavaScript 命名树（ISO 32000-1 §7.7.4.4 + §12.6.4.16），作为一个间接的 /S /JavaScript /JS 字典。表单控件操作和文档打开操作可以通过查看器的 JavaScript 引擎（Acrobat、Foxit），通过名称调用注册的函数。这对于在许多控件中共享验证、格式化或计算辅助程序库非常有用，而无需在每个 /A 操作字典中重复 JavaScript 源代码。此方法在任何 PDFACompliance 级别（ISO 19005-1 §6.6.1）和任何 PDFXCompliance 级别（ISO 15930 预印工作流程）下都会引发错误，并且会拒绝空 Name / Body 以及重复的 Name 注册。

2026-05-20 Version 2.119.13

新しいページサムネイルのサポート：THPDFPageは、SetPageThumbnail(ImageIndex)とClearPageThumbnailを公開しています。PDFビューア（Acrobat、Foxit、ブラウザビューア）は、ページ内の/Thumbエントリ（ISO 32000-1 §12.3.4）を使用して、ページをラスター化せずに、ナビゲーション領域に事前に作成されたプレビューを表示します。これは、特に画像が多く含まれるアーカイブにおいて、ビューア自体のラスター化エンジンが遅い場合に役立ちます。ヘルパー関数は、AddImage / AddImageFromFileで登録された画像を再利用します。これにより、呼び出し元はダウンサンプリングされたプレビュービットマップを準備し、1回の呼び出しで添付できます。SetPageThumbnail(-1)またはClearPageThumbnailは、以前に添付されたサムネイルを削除します。範囲外の画像インデックスの場合、説明的な例外が発生します。

2026-05-20 Version 2.119.12

PDF/A 準拠の修正：`AddPushButtonWithAction` 関数において、`baJavaScript` または `baResetForm` アクションが、どの PDFACompliance レベル (PDF/A-1/2/3) で使用された場合でも、例外が発生するようになりました。ISO 19005-1 §6.6.1 / ISO 19005-2 §6.5.1 / ISO 19005-3 §6.5.1 は、すべての PDF/A レベルにおいて、JavaScript、ResetForm、および ImportData アクションの使用を禁止しています。`baSubmitURL` (SubmitForm)、`baURI`、および `baNone` は、PDF/A 環境下では引き続き許可されています。SubmitForm は、§6.6.1 で許可されているアクションのリストに含まれています。以前は、PDFACompliance が有効になっている場合でも、ボタンウィジェットに禁止されたアクションが含まれることがありましたが、v2.119.5 の修正は、Catalog /AA とドキュメントレベルの OpenAction のパスのみを対象としていました。

PDF/X 準拠の修正：`AddPushButtonWithAction` 関数现在在任何 `PDFXCompliance` 级别下，当使用 `baJavaScript`、`baResetForm` 或 `baSubmitURL` 操作类型时，都会引发异常。ISO 15930 预印制工作流程中，禁止使用交互式脚本、表单修改以及向外部端点提交表单。

2026-05-20 Version 2.119.11

PDF/A 準拠の修正：PDF/A 注釈の種類の制限が強化されました。`AddScreenAnnotation`、`Add3DAnnotation`、および `AddRichMediaAnnotation` は、`PDFACompliance` がどのレベルでも有効になっている場合にエラーを発生させます (PDF/A-1/2/3)。ISO 19005-1 §6.5.2 / ISO 19005-2 §6.6.1 / ISO 19005-3 §6.6.1 は、すべての PDF/A レベルで、Screen、3D、および RichMedia (マルチメディア / Adobe 拡張レベル 3) 注釈のサブタイプを禁止しています。同様の制限は `PDFXCompliance` の下でも適用され、ISO 15930 のプリプレスワークフローでは、マルチメディアのサブタイプが拒否されます。

PDF/A-1 準拠の修正：`AddWatermarkAnnotation` と `AddRedactAnnotation` は、`PDFACompliance` が PDF/A-1 に設定されている場合に例外を発生するようになりました。ウォーターマーク (PDF 1.6) とリダクト (PDF 1.7) は、PDF/A-1 のベースとなる PDF 1.4 と互換性のない、PDF 1.4 以降の注釈サブタイプです (ISO 19005-1 §6.5.2)。PDF/A-2 および PDF/A-3 (PDF 1.7 ベース) は、引き続き両方の注釈タイプをサポートしています。

2026-05-20 Version 2.119.10

PDF/A 準拠の修正：`AddImageWithSMask` および `AddImageWithSMask32` は、`PDFACompliance` が PDF/A-1 に設定されている場合に例外を発生するように変更されました。ISO 19005-1:2005 の §6.4 では、すべての透明効果が禁止されています。イメージの `/SMask` ストリームは、ソフトマスクによる透明度合成を有効にします。イメージを背景色に事前に合成し、その結果を `AddImage()` に渡すか、透明度をサポートするために PDF/A-2 以降を使用してください。PDF/A-2 および PDF/A-3 では、イメージのソフトマスクによる透明度が引き続き許可されています。

2026-05-20 Version 2.119.9

PDF/A 準拠の修正：`SetTransparencyGroup` と `SetTransparencyGroupICC` は、`PDFACompliance` が PDF/A-1 に設定されている場合に例外を発生させます。ISO 19005-1:2005 の §6.4 では、すべての透明度効果が禁止されています。ページレベルの透明度グループ（ページ内の `/Group /S /Transparency` ディクショナリ）は、ページ全体の透明度合成モデルを有効にし、これは §6.4 の直接的な違反です。PDF/A-2 および PDF/A-3 では、ページ透明度グループは引き続き許可されています。

2026-05-20 Version 2.119.8

PDF/A 準拠の修正：RegisterHalftoneState は、PDFACompliance が有効であり、カスタムのハーフトン辞書が提供された場合に例外を発生させます (つまり、HTDefaultName = false の場合)。ISO 19005-1:2005 §6.2.9 および ISO 19005-2:2011 / ISO 19005-3:2012 §6.3.7 では、ExtGState /HT に対しては、/Default という名前の文字列のみが許可されています。カスタムのハーフトン辞書 (タイプ 1、5、6、10、16) は禁止されています。HTDefaultName=True を指定してデフォルトのハーフトンにリセットする操作は、すべての PDF/A レベルで引き続き機能します。

PDF/A 準拠の修正：RegisterSoftMaskState は、PDFACompliance が PDF/A-1 に設定され、カスタムのソフトマスク辞書が提供された場合（SMaskDict パラメータ）に、例外を発生させます。ISO 19005-1:2005 の §6.4 では、すべての透明効果が禁止されています。/SMask に null 以外の値を設定すると、ソフトマスクによる透明効果が有効になります。ソフトマスクをリセットするために SMaskNone=True を指定することは引き続き許可されています。PDF/A-2 および PDF/A-3 では、ソフトマスクによる透明効果は引き続き許可されています。

2026-05-20 Version 2.119.7

PDF/A 準拠の修正：`AddDocumentAttachment`（カタログの`/Names`、`/EmbeddedFiles`を介したドキュメントレベルのファイル埋め込み）は、`PDFACompliance`が有効で、PDF/A-1またはPDF/A-3の場合にエラーを発生させるようになりました。ISO 19005-1:2005の§6.1.11では、PDF/A-1の場合、ドキュメントのNames辞書における`/EmbeddedFiles`キーの使用は明示的に禁止されています。PDF/A-3の場合、必要なカタログの`/AF`配列と`/AFRelationship`キーを含めるために、添付ファイルは`AddPDFA3AssociatedFile()`を通じて登録する必要があります（ISO 19005-3:2012の付録Eを参照）。PDF/A-2では、添付ファイル自体がPDF/Aに準拠している場合に限り、ドキュメント添付を許可します。

2026-05-20 Version 2.119.6

PDF/A 準拠の修正：PDF 標準フォント（Arial、Helvetica、Times New Roman、Courier New、Symbol、ZapfDingbats）を StandardFontEmulation オプションを有効にして使用する場合、PDFACompliance が有効になっていると、詳細な例外が発生します。ISO 19005-1:2005 §6.3 および ISO 19005-2:2011 / ISO 19005-3:2012 §6.3 では、すべてのフォントを準拠ファイルに埋め込む必要があります。標準フォントのエミュレーションでは、埋め込まれていないフォントへの参照が生成され、これは §6.3 の直接的な違反です。ユーザーは、StandardFontEmulation を false に設定するか、PDF/A 出力のために実際のフォントファイルを使用して RegisterUnicodeTTF() を使用する必要があります。

PDF/A 準拠の修正：非標準フォントは、PDFACompliance が有効になっている場合、フォント埋め込みプロパティの設定に関係なく、常に埋め込まれるようになりました。フォント埋め込みを無効にする最適化は、PDF/A モードでは、§6.3 の「すべてのフォントを埋め込む」という要件を満たすために、通知なく上書きされます。

2026-05-20 Version 2.119.5

PDF/A 準拠の修正：JavaScript アクションとカタログレベルの /AA (追加アクション) が、PDFACompliance が有効になっている場合にブロックされるようになりました。ISO 19005-1:2005 の §6.6.1/§6.6.2 および ISO 19005-2:2011 / ISO 19005-3:2012 の §6.5.1/§6.6.2 では、すべての JavaScript アクションの種類が禁止されており、カタログ辞書内の /AA キーも禁止されています。現在、任意の PDFACompliance 値で SetActionScript を呼び出すと、詳細な例外が発生します。二次的な対策として、EndDoc 内の OpenAction JavaScript とカタログ /AA の出力パスも、PDFACompliance が有効になっている場合に、無効化され、非準拠のキーが内部パスを介して書き込まれないようにします。

2026-05-20 Version 2.119.4

PDF/A 準拠の修正：AcroForm の "/NeedAppearances" が、PDFACompliance が有効になっている場合、AutoFormAppearances の設定に関わらず、常に false に設定されるようになりました。ISO 19005-1:2005 §6.9 および ISO 19005-2:2011 / ISO 19005-3:2012 §6.4 では、このキーが準拠ファイルでは存在しないか、false である必要があります。以前は、AutoFormAppearances が無効になっているにもかかわらず PDFACompliance が有効になっている場合、/NeedAppearances が true に設定され、準拠していないファイルが生成されていました。

2026-05-20 Version 2.119.3

PDF/A 準拠の修正：埋め込み CIDFont のサブセットにおいて、PDFACompliance が有効な場合、フォント記述子に /CIDSet ストリームが含まれるようになりました。ISO 19005-1:2005 §6.3.5 および ISO 19005-2:2011 / ISO 19005-3:2012 §6.2.11 では、CIDFont のサブセットには、埋め込みフォントプログラムに含まれる CID 値を示す /CIDSet ビットストリームが含まれている必要があります。HotPDF では、CID が Unicode コードポイントと等しい Identity-H エンコーディングを使用しているため、CIDSet はドキュメントで使用されているコードポイントのセットから直接構築されます。このビットストリームは FlateDecode で圧縮され、既存のフォント記述子に間接ストリームオブジェクトとして追加されます。これにより、以前に検出されていなかった、すべての PDF/A レベルにおける問題が修正されました（以前のコンプライアンス監査では、これが既に実装されていると誤って記載されていました）。

2026-05-20 Version 2.119.2

PDF/A-2 および PDF/A-3 準拠の修正：注釈の表示辞書（/AP /N）が、リンクおよびポップアップ以外の注釈タイプ（テキスト注釈、自由テキスト、線、四角形、円、スタンプ、ファイル添付）に対して、PDFACompliance が PDF/A-2 または PDF/A-3 レベルに設定されている場合に、自動的に生成されるようになりました。ISO 19005-2:2011 §6.3.3 および ISO 19005-3:2012 §6.3.3 では、そのような注釈すべてに少なくとも 1 つの表示辞書（N エントリ形式の XObject）が必要です。構造上の要件を満たすために、最小限の空のフォーム XObject が生成されます。ほとんどの PDF ビューアは、/AP ストリームの内容に関係なく、標準注釈タイプに対して独自の組み込みレンダリングを使用します。リンクおよびポップアップ注釈は、規格によって明示的に除外されており、変更はありません。この要件は PDF/A-1 には適用されません（ISO 19005-1 §6.5.3 では、/AP が存在する場合にのみ形式が制限され、その存在自体は制限されていません）。

2026-05-20 Version 2.119.1

PDF/A 準拠の修正：すべてのウィジェット以外の注釈タイプ（テキスト注釈、スタンプ、線、図形、ハイパーリンク、GoTo リンク、GoToR リンク、URI リンク）について、PDFACompliance が有効になっている場合、自動的に `/F` プリントフラグ（ビット 3 = 1、値 4）が設定されるようになりました。ISO 19005-1:2005 §6.5.3 および ISO 19005-2:2011 / ISO 19005-3:2012 §6.3.2 は、すべての注釈辞書に `/F` キーが含まれており、その中にプリントビットが設定されていることを規定しています。以前は、ウィジェット注釈（フォームフィールド）のみにこのフラグがありましたが、他のすべての注釈タイプではこのフラグが省略されており、その結果、生成されるファイルが規格に準拠していませんでした。

PDF/A-1 準拠の修正：オプションコンテンツグループ（レイヤー）は、`PDFACompliance` が PDF/A-1 レベル（'A' または 'B'）に設定されている場合に、現在ブロックされます。ISO 19005-1:2005 §6.1.13 では、カタログ辞書内の `/OCProperties` キーは禁止されています。PDF/A-1 環境で `RegisterOptionalContentGroup` を呼び出すと、オプションコンテンツが必要な場合は、PDF/A-2 以降を使用するように指示する詳細な例外が発生します。また、`EndDoc` での `/OCProperties` の出力も制限されており、OCG が登録された場合でも、意図しない非準拠を防止します。

2026-05-20 Version 2.119.0

ETSI EN 319 142-2 V1.2.0 §6.2 に従って、XAdES-in-PDF コンテナをサポートします (B/C/D シリーズの 3 番目のクロージャ)。呼び出し元が提供する XAdES で署名された XML バイトを PDF 埋め込みファイルとして埋め込み、Filespec をカタログの /AF 配列に登録し、呼び出し元が指定した PDF 2.0 の列挙に基づいて /AFRelationship を設定します。これはプロデューサ側のラッパーのみであり、実際の XAdES 署名の構築 (XML-DSig + ETSI EN 319 132-1 の修飾プロパティ + RFC 3161 タイムスタンプを xades:UnsignedSignatureProperties に埋め込む) は、呼び出し元の XML 暗号化ライブラリの責任です (Apache Santuario、.NET SignedXml、libxmlsec、XAdES 拡張機能付きの Saxon など)。

新しいメソッド `THotPDF.AddXAdESAssociatedFile(FileName, XMLBytes, Description, MimeType, Relationship)` が追加されました。デフォルト値は、`MimeType` が `'application/xml'` (ASiC-E アーカイブの場合は `'application/vnd.etsi.asic-e+zip'` も一般的) で、`Relationship` が `'Source'` (XAdES で署名された XML がドキュメントの主要なコンテンツ) です。このメソッドは、間接的な Filespec ディクショナリを返します。これにより、呼び出し元は追加のメタデータを添付したり、カスタムカタログエントリからクロスリファレンスを作成したりできます。

PDF/A に依存しない：v2.108 の `AddPDFA3AssociatedFile` とは異なり（これは PDFACompliance='3*' が必要）、このヘルパーには PDF/A の制限はありません。XAdES-in-PDF は、PAdES Part 2 V1.2.0 §6 に従って、独自のプロファイルファミリーです。

`_EscapePDFNameBytes` 函数中的一个关键错误已修复（PDF 1.7 ISO 32000-1 §7.3.5 + 表 2）。之前的转义仅将范围在 [0x21..0x7E] 之外的字节以及 `#` 字符进行转换；PDF 规范要求将分隔符 (`/ ( ) < > [ ] { } %`) 在名称内部以 `#XX` 的形式转义，但之前未进行转义，而是保持字面值。因此，像 `/Subtype /application/xml` 这样的名称，会被严格的解析器解析为两个独立的名称标记（`/application` 后跟 `/xml`），从而导致嵌入文件的 `/Subtype` 识别失败。 v2.119 版本现在按照规范转义所有 10 个分隔符；非分隔符名称（绝大多数 HotPDF 的输出）保持与之前相同的字节值。 PDF/A-3 附录 E (v2.108) 中的 MIME 类型现在可以正确输出（`/application#2Fxml` 而不是错误的 `/application/xml`）。

PAdES B/C/Dシリーズが、3つのコミットで完了しました。v2.117（パート2 §5に従ったE-BES / E-EPES / E-LTV拡張プロファイル）+ v2.118（ISO 32000-1 §12.7.5.5およびパート2 §4.2.6に従ったシード値）+ v2.119（パート2 §6.2に従ったXAdES-in-PDFおよび区切り文字のエスケープ修正）。v2.109からv2.116と組み合わせることで、HotPDFは、基本プロファイル、拡張プロファイル、ドキュメントのタイムスタンプ、DSS検証情報、ESIC拡張、シード値による署名制約、およびXAdES-in-PDFコンテナを含む、PAdESのすべてのプロデューサ範囲をカバーします。

Win32 および Win64 でクリーンなコンパイルが完了しました。v2.108 から v2.118 までのベースラインをすべて再コンパイルしましたが、変更はありませんでした。新しいテストスイート smoke_pades_xades に、2 つの成功パス (XAdES で署名された XML ファイルを `/AFRelationship` および `/Source` として、ASiC-E アーカイブを `/Data` として使用) と、4 つの失敗パス (FileName が空、XMLBytes が空、MimeType が空、Relationship が無効) が追加されました。Python 検証ツールは、`/Subtype /application#2Fxml` および `/Subtype /application#2Fvnd.etsi.asic-e+zip` の両方の形式を含む、すべてのファイル仕様をエンドツーエンドで検証します。v2.108 の PDF/A-3、PAdES、および PDF/X のテストをすべて再実行し、クリーンな結果が得られました。

2026-05-20 Version 2.118.0

PAdES シード値は、ISO 32000-1 §12.7.5.5 および ETSI EN 319 142-1 V1.2.1 §5.5、さらに ETSI EN 319 142-2 V1.2.0 §4.2.6 (B/C/D シリーズのステップ 2/3) に準拠します。署名フィールドに添付されたシード値 (SV) 辞書は、その特定のフィールドについて、閲覧側の署名ツールが選択できる内容を制限します。具体的には、どのハンドラを使用するか、どのサブフィルタを使用するか、どのダイジェスト方法を使用するか、取り消し情報が必須かどうか、および必要な最小限の PDF バージョンを規定します。

新しい `THotPDF.AttachPAdESSeedValue(FieldName, SubFilters, DigestMethods, ForceSubFilter, ForceDigestMethod, AddRevInfo, MinPDFVersion, ForceMinPDFVersion)` メソッドが追加されました。このメソッドは、AcroFormのフィールドリスト内で指定された名前の署名フィールドを検索し（事前に `AddPAdESSignatureField` または `AddDocumentTimestampSignature` を呼び出して作成されている必要があります）、呼び出し元が指定した制約を含む `/SV` サブ辞書を関連付けます。

Seed Value エントリが出力されます（表 234 に示す通り）。

`/Type /SV`

`/SubFilter`：名前の配列 — 例：[/ETSI.CAdES.detached]

`/DigestMethod`：名前の配列 — 例：[/SHA256 /SHA384 /SHA512]

`/AddRevInfo`：ブール値 — 署名ツールは、CMS に OCSP/CRL を含める必要があります。

`/V`：数値 — 最小 PDF バージョン（例：1.7）

`/Ff`：整数ビットフラグ（表 235） — 各 Force* パラメータは、対応するビットを設定します。したがって、署名ツールは、この制約を必ず守る必要があります（ビット 2 = SubFilter を強制、ビット 3 = V を強制、ビット 6 = AddRevInfo を強制、ビット 7 = DigestMethod を強制）。

仕様への準拠に関する制限：PAdESパート2 V1.2.0 §4.2.6では、署名ツールがPAdESプロファイルを違反するようなシード値を設定することを禁止しています（例：PKCS#1 SubFilterを指定する）。HotPDFは、プロデューサ側でこれを強制適用しません。呼び出し元は、仕様で許可された値のみ（SubFilterの場合は`'adbe.pkcs7.detached'`または`'ETSI.CAdES.detached'`、DigestMethodの場合はSHA-256+）を渡す責任があります。ヘルパーのドキュメントコメントには、この制限について明示的に記載されています。

Win32 および Win64 でクリーンなコンパイルが完了しました。v2.108 から v2.117 までのベースラインをすべて再コンパイルしましたが、変更はありませんでした。新しい smoke テスト smoke_pades_seedvalue は、PAdES-B-T フィールドを作成し、完全な Seed Value の制約を付加します (SubFilter は ETSI.CAdES.detached に制限され、DigestMethod は SHA256/384/512 に制限され、AddRevInfo は true に設定され、MinPDFVersion は 1.7 に設定され、すべての強制ビットが設定されます)。Python 検証ツールは、/SV サブ辞書を走査し、各エントリの形状を検証します。また、"不明な FieldName" の拒否処理もテストします。

シリーズのステップ3（バージョン2.119）：パート2 V1.2.0 §6に記載されている、XAdES形式のPDFコンテナにより、B/C/Dシリーズが完了します。プロデューサ側では、これはHotPDFの既存のEmbeddedFile、Catalog、および/AF機能（PDF/A-3ヘルパー、バージョン2.108）の簡易ラッパーであり、さらに、PAdESパート2 V1.2.0 §6.2.2でXAdES署名されたXMLペイロードに期待される/AFRelationshipの意味を含んでいます。

2026-05-20 Version 2.117.0

ETSI EN 319 142-2 V1.2.0 §5 (B/C/Dシリーズのステップ1/3) に定義されている、PAdES拡張プロファイル。パート1の基本設定 (V1.2.1 §6 B-B / B-T / B-LT / B-LTA) は、固定されたCMS属性の組み合わせを定義します。一方、パート2 §5では、より柔軟なCMS属性のオプションを提供する「拡張」プロファイル (E-BES / E-EPES / E-LTV) のファミリーを定義しており、これは、基本設定では実現できない、例えば、複数のポリシーを持つ企業環境での展開や、PAdESエンベロープ内のカスタムCAdESプロファイルなど、柔軟性を必要とする場合に役立ちます。

`AddPAdESSignatureField` プロファイルパラメータは、既存の4つの基本名に加えて、さらに3つの追加値をサポートします。

`'E-BES'`：基本的な、かつ曖昧性のない署名証明書バインディング。署名証明書のESS属性を介して行われます（PAdESエンベロープ内のCAdES-BES相当）。デフォルトのコンテンツサイズは16 KBです。

`'E-EPES'`：E-BESに加えて、明示的な署名ポリシー識別子を署名属性として含めます。デフォルトのサイズは16 KBですが、通常、ポリシーOIDと修飾子バイトを格納するために、呼び出し元は18〜20 KBを渡します。

`'E-LTV'`：CMS属性を使用した柔軟な証明書チェーンと、取り消し情報を埋め込んだ長期検証を行います。自動的にサイズを20 KB以上に拡張します（B-LTと同様）。

ベースラインプロファイルと拡張プロファイルの両方で、生成側のワイヤー形式は同一です。これらすべてが、SubFilter `ETSI.CAdES.detached`、同じ `/ByteRange` + `/Contents` のパターン、および同じ DSS + ESIC の仕組み（v2.110 / v2.116）を使用します。レベルの違いは、呼び出し元の暗号化ライブラリによって生成される CMS 署名属性の構成にのみ存在します。プロファイル文字列は、検証診断とデフォルトの `/Contents` の制限値のみが異なります。HotPDF は、CAdES-BES、CAdES-EPES、および CAdES-T を PDF 辞書自体にエンコードしません。

PAdESヘルパーのドキュメントコメントを更新し、パート2 V1.2.0 §4.2で説明されている、呼び出し元の責任を明確にしました。具体的には、SHA-256+ハッシュの選択（SHA-1の段階的廃止）、Sigフィールドごとの単一のSignerInfo、RFC 5755属性証明書の非サポート、およびE-EPES要件である、署名ポリシー識別子を含む署名属性について説明しています。呼び出し元のドメインに関する項目は、引き続きプロバイダーの範囲外ですが、APIインターフェースにおける契約は明確になりました。

Win32 および Win64 でクリーンなコンパイルが完了しました。v2.108 から v2.116 までのベースラインをすべて再コンパイルしましたが、変更はありませんでした。`smoke_pades_signature` が 3 つの新フィールド (SigEBES / SigEEPES / SigELTV) で拡張され、各新しいプロファイル値を、自動サイズ調整 / 明示的な予算 / デフォルト予算のパスを通じて検証しています。Python 検証ツールは、すべての 7 つのフィールドを検証するように拡張され、カタログ ESIC 拡張機能を検証します (v2.116 で引き続き適用)。

B/C/Dシリーズのステップ2：v2.118では、シード値（PDF 1.7 §12.7.5.5 + ETSI EN 319 142-1 V1.2.1 §5.5 + Part 2 V1.2.0 §4.2.6）が追加され、PAdESの署名フィールドが、署名時にクライアント側のリーダーが遵守する必要がある、ハンドラ/SubFilter/digest-methodの制約を宣言できるようになりました。ステップ3：v2.119では、Part 2 V1.2.0 §6に従って、XAdES-in-PDFコンテナのサポートが追加されました（XAdESで署名されたXMLをEmbeddedFileとして埋め込み、Catalog /AFを関連付けます）。

2026-05-20 Version 2.116.0

PAdES已根据最新的ETSI规范版本和eIDAS实施决定进行更新：ETSI EN 319 142-1 V1.2.1（2024-01，已发布）+ ETSI EN 319 142-2 V1.2.0（2025-03，草案，包括附加配置文件 + 扩展配置文件 + XAdES-in-PDF）+ ETSI TS 119 142-3 V1.1.1（2016-12，PAdES-DTS文档时间戳）+ EU 2015/1506（公共部门认可）。HotPDF v2.109 - v2.111的基础版本（B-B / B-T / B-LT / B-LTA + 独立时间戳）继续满足相同的传输格式；此版本修复了新规范版本暴露的两个生产端问题。

DSS辞書 `/Type "DSS"` エントリ（EN 319 142-1 V1.2.1 §5.4.2.2）。`/Type` エントリはオプションですが、存在する場合、`/DSS` という名前でなければなりません。HotPDFは、厳格な検証ツールが`/Type`を確認する前に辞書の他の部分を解析する際に、構造をすぐに認識できるように、このエントリを積極的に出力するように変更されました。

ESIC拡張辞書（TS 119 142-3 §5.1、推奨）。新しい`EnsurePAdESESICExtensions`メソッドは、PAdESヘルパーが呼び出されるたびに、以下の内容をカタログに冪等的に書き込みます：`<< /Extensions << /ESIC << /BaseVersion /1.7 /ExtensionLevel 1 >> >> >>`. 検証ツール（Adobe Acrobatのプレフライト機能、EU DSS、callas pdfaPilot）は、このエントリを使用して、ドキュメントがPDF 1.7 + ESICレベル1拡張機能を宣言するPAdESコンテナであることを識別します。

`EnsurePAdESDSS` 往返路径中的关键错误已修复。在 v2.116 之前，辅助程序在每次调用时都会通过 `Catalog.GetIndexedItem(FindValue('DSS'))` 重新解析 DSS 字典，该方法返回存储在目录中的间接链接 `THPDFLink`，而不是实际的 DSS 字典。强制转换为 `THPDFDictionaryObject` 会静默地错误地类型转换指针，导致后续的每个 `AddPAdESDSSCertificate` / `AddPAdESDSSOCSP` / `AddPAdESDSSCRL` / `AddPAdESDSSVRI` 调用在第一次调用后静默地跳过数组的推送（数组引用解析为 null，`FindValue` 返回 -1，如果索引小于零则提前退出）。 v2.116 的修复程序将实际字典引用缓存在 `FPAdESDSSDict` 字段中，以便后续调用直接访问缓存。现在，`smoke_pades_dss` 测试可以正确地输出 2 个证书 + 1 个 OCSP + 1 个 CRL + 1 个 VRI 条目（以前，只有第一个证书会进入 /DSS，而 /OCSPs 和 /CRLs 数组为空）。

PAdESヘルパーのドキュメントコメントを更新しました。この更新は、パート2 V1.2.0 §4.2で示された、呼び出し元の責任に関するものです。具体的には、SHA-1の廃止（CMSではSHA-256+を使用するよう呼び出し元に推奨）、PDF署名あたりのSignerInfoは1つのみ（パート2 §4.2.1 h / パート1 §4.1 a）、RFC 5755の属性証明書は使用しない（パート2 §4.2 g）、PAdES-DTSドキュメントにはVRI辞書を含めない（TS 119 142-3 §6.3 h — DSSで十分）といった内容が含まれます。HotPDFのプロデューサ側の内部形式は、これらのすべての制約を設計上満たしていますが、コメントは、CMS構築ライブラリを使用する呼び出し元が何をすべきかを伝えています。

Win32 および Win64 でクリーンなコンパイルが完了しました。`smoke_pades_signature`、`smoke_pades_dss`、`smoke_pades_doctimestamp` およびそれらの検証器はすべて正常に動作します。検証器の拡張機能：`smoke_pades_dss` は、`/Type /DSS` およびカタログ `/Extensions /ESIC /BaseVersion /1.7 /ExtensionLevel 1` をアサートします。`smoke_pades_doctimestamp` は、同じ ESIC 拡張機能をアサートし、ページを垂直方向に反転させたゼロ領域の `/Rect` (`[0 H 0 H]`、ここで H はページ高さ) を受け入れます。監査ドキュメントと技術ドキュメントを更新し、EN 319 142-1 V1.2.1 / Part 2 V1.2.0 / TS 119 142-3 / EU 2015/1506 を参照するようにしました。

2026-05-20 Version 2.115.0

PDF/X (ISO 15930) 生产线系列结束（4/4）：根据 ISO 15930-1:2001 / ISO 15930-3:2002 / ISO 15930-7:2010 + ISO 32000-1 §12.5.6 / §12.6.4，禁止使用注释和动作类型。PDF/X 打印工作流程仅消耗可见的可打印内容；多媒体注释、嵌入文件和交互式操作在印刷过程中都无法使用，因此，预检工具（如 Adobe Acrobat、Enfocus PitStop、callas pdfaPilot）会拒绝包含这些内容的文档。

禁止使用的注释类型（在任何 PDF/X 兼容模式下都会被拒绝，兼容模式包括 X-1a、X-3 和 X-4）：

FileAttachment — 印刷设备不会处理嵌入的文件

Sound — 多媒体内容不适用于印刷工作流程

Movie — 原因同上，不适用于印刷工作流程

现在，每个入口点（AddFileAttachmentAnnotation、AddSoundAnnotation、AddMovieAnnotation）在任何 PDF/X 配置文件下被调用时，都会引发与规范章节相关的错误，并显示 PDF/X 兼容模式的值。

禁止的操作类型（在任何 PDF/X 兼容模式下均被拒绝）：Launch、JavaScript、SubmitForm、ImportData、Movie、Sound、ResetForm。印刷预处理工作流程不应触发任何外部程序，PDF 文件仅由印刷机/RIP 处理，绝不执行。 `AddLaunchLink` 现在在所有 PDF/X 配置文件下都会引发错误（其他操作在 HotPDF 中未作为公共 API 暴露，因此会自动满足）。

PDF/Xシリーズの開発が完了しました。v2.112（オプション機能、XMP識別情報、トラップ/名前）+ v2.113（出力意図、ICC GTS_PDFX）+ v2.114（透明度の制限、ページボックスの強制）+ v2.115（注釈/アクションの禁止）。業界標準の3つのプロファイル（X-1a:2001、X-3:2002、X-4:2010）に対応しています。ユーザーは引き続き、ページレベルでのプリプレスコンテンツを作成します（適切なCMYK設定、v2.84 TTFサブセッターによるフォント埋め込み、トリミングボックスの寸法をデザインに合わせて設定、必要に応じてブリードボックス）。構造的な準拠機能はすべて実装されています。

Win32およびWin64のクリーンコンパイルが完了しました。v2.108からv2.114までのベースラインをすべて再コンパイルしましたが、変更はありませんでした。`smoke_pdfx_optin`が拡張され、4つの新しい拒否テスト（`TestRejectFileAttachmentAnnot`、`TestRejectSoundAnnot`、`TestRejectMovieAnnot`、`TestRejectLaunchAction`）が追加されました。各テストは、3つのPDF/Xプロファイルのうちのいずれかを使用して禁止されたタイプを生成し、正常に拒否されることを確認します。現在、合計で11のシナリオをテストしています。これには、3つの正常な出力と8つの拒否パスが含まれます。

このグループでは、PAdES (ETSI EN 319 142、v2.109 - v2.111、3件のコミット。B-B / B-T / B-LT / B-LTA およびスタンドアロンのタイムスタンプがすべてサポートされています) と PDF/X (ISO 15930、v2.112 - v2.115、4件のコミット。X-1a / X-3 / X-4 のプロデューサ側の構造コンプライアンス機能がすべて実装されています) という、並行して開発されている複数のバージョンシリーズが終了しました。

2026-05-20 Version 2.114.0

PDF/X (ISO 15930) プロデューサーシリーズ、パート3/4：透明度の制限と、ISO 15930-1:2001 / ISO 15930-3:2002 / ISO 15930-7:2010 および ISO 32000-1 §14.11.2 に基づく PageBox の適用。このパートは、各ページに適用される2つの独立した制限事項を対象としており、制限の分割は、v2.103 PDF/A-1 の透明度とページ機能のパターンを反映しています。

透明度チェック（§7.5）：RegisterExtGState 関数は、PDFXCompliance が 'X-1a' または 'X-3' の場合に、塗りつぶしの透明度（/ca）が 1 未満、線の透明度（/CA）が 1 未満、またはブレンドモードが {Normal, Compatible} の範囲外の場合にエラーとなります。PDF/X-1a (ISO 15930-1:2001) および PDF/X-3 (ISO 15930-3:2002) は、PDF 1.3 をベースとしており、これは PDF 1.4 の透明度機能よりも前のバージョンです。PDF/X-4 (ISO 15930-7:2010、PDF 1.6 をベース) は、透明度を明示的に許可しているため、X-4 の場合、このチェックは実行されません。診断ツールは、原因を説明し、透明度が必要な場合は PDF/X-4 へのアップグレードを推奨します。

ページボックスの適用（§14.11.2）：新しいメソッド`EnsurePDFXPageBoxes`は、すべてのページを処理し、`/TrimBox`または`/ArtBox`の少なくとも一方が存在することを要求します。`MediaBox`だけでは不十分です。なぜなら、`MediaBox`はデザインキャンバスを表しますが、印刷店が必要とする最終的なページの寸法を表すものではないからです。ページボックスが欠落している場合、1を起点とするページインデックス、仕様のセクションへの参照、および推奨される`SetTrimBox`の呼び出し形式とともにエラーが発生します。`EndDoc`のPDFXComplianceゲートは、`OutputIntent`チェックの後、自動的に`EnsurePDFXPageBoxes`を呼び出します。

一般的な呼び出しパターンは次のとおりです。PDFXCompliance、Trapped、およびAddPDFXOutputIntentを設定した後、ドキュメント内のすべてのページで、`CurrentPage.SetTrimBox(Left, Bottom, Right, Top)` を使用して、仕上がり製品の寸法に一致させる必要があります（例：US Letterの場合は 0 0 612 792、A4の場合は 0 0 595 842）。トリミング領域（BleedBox）の設定は推奨されますが、必須ではありません。

Win32 および Win64 でクリーンなコンパイルが完了しました。v2.108 から v2.113 までのベースラインはすべて再コンパイルされ、変更はありません。`smoke_pdfx_optin` には、次の機能が追加されました。3 つのプロファイルすべてで `SetTrimBox` を呼び出すと、正の値が生成されます。`TrimBox` が存在しない場合の拒否パスが実装されました。X-1a の透明度に関する拒否パスが追加されました ( `RegisterExtGState` で `ca=0.5` を指定するとエラーが発生します)。X-4 の透明度許可に関する正のパスが実装されました (同じ呼び出しで成功し、`ExtGState` が登録されます)。Python 検証器は、すべての `/Type /Page` ディクショナリを走査し、各ページに `/TrimBox` または `/ArtBox` の少なくとも 1 つが存在することを検証します。

PDF/X関連の機能：v2.115では、禁止されたアクションタイプ（JavaScript、Launch、SubmitForm、ImportData、Movie、Sound）、禁止された注釈タイプ（Movie、Sound、FileAttachment、Screen）、およびAcroForm/XFAの拒否機能が追加されました。これらの機能は印刷ワークフローには不要であり、一般的なプレフライトツールでは重大なエラーとして検出されます。

2026-05-19 Version 2.113.0

PDF/X (ISO 15930) プロデューサーシリーズのパート2/4：ISO 15930-1:2001 §6.2.2、ISO 15930-3:2002 §6.2.2、ISO 15930-7:2010 §6.2 および ISO 32000-1 §14.11.5 に従って、OutputIntent と ICC プロファイルの一貫性を強制します。すべての PDF/X プロファイルには、少なくとも 1 つの "/Type /OutputIntent /S /GTS_PDFX" エントリが含まれており、これはターゲットの印刷条件を指定し、"/DestOutputProfile" ICC プロファイルストリームを提供します。印刷所はこの情報を使用して、PDF の色を印刷機/紙/インクの組み合わせに合わせて調整します。

新しいヘルパー関数 `AddPDFXOutputIntent(OutputConditionIdentifier, Info, ICCProfileStream, NumComponents, AlternateCS)` は、v2.102 の PDF/A ラッパーと同様の機能を提供しますが、`GTS_PDFA1` ではなく `GTS_PDFX` サブタイプを生成します。この関数は、`ICCProfileStream` が null でないこと、および `OutputConditionIdentifier` が空でないことを検証します。また、プロファイルを埋め込むために `RegisterICCProfile` を呼び出し（`NumComponents` に一致する `/Alternate` フォールバックカラー空間を自動的に処理します）、`AddOutputIntent` を呼び出して `OutputIntent` ディクショナリを構築します。

PDFX準拠設定時、`EnsurePDFXOutputIntent`は`OutputIntents`配列を走査し、少なくとも1つのエントリが`/S /GTS_PDFX`と`/DestOutputProfile`を持つことを要求します。エントリがない場合は、登録された識別子（シートオフセット印刷の場合はFOGRA39、北米ウェブ印刷の場合はCGATS TR 001 SWOP、アジア市場の場合はJapan Color 2001 Coated）の提案とともにエラーが発生します。

一般的なPDF/Xワークフロー: 1) `Doc.PDFXCompliance := 'X-4'`, 2) `Doc.Trapped := 'False'`, 3) CMYK ICCプロファイルストリーム（FOGRA39 / SWOP / など）をTStreamにロードします。4) `Doc.AddPDFXOutputIntent('FOGRA39 (ISO 12647-2:2004)', '', ICCStream, 4, 'DeviceCMYK')`を実行します。5) コンテンツをデザインします。6) `Doc.EndDoc`が、カタログの/OutputIntents配列からリンクされたOutputIntentを生成します。消費者のプレフライトツール（Adobe Acrobat、Enfocus PitStop、callas pdfaPilotなど）が、カラーマネジメントの設定を検証します。

Win32およびWin64のクリーンコンパイルが完了しました。v2.108、v2.109、v2.110、v2.111、v2.112のベースラインをすべて再コンパイルしましたが、変更はありませんでした。`smoke_pdfx_optin`（元々はv2.112）を拡張し、各プロファイルのエミット（X-1a → FOGRA39 CMYK、X-3 → SWOP CMYK、X-4 → sRGB RGB）で、偽のICCプロファイルを登録し、`AddPDFXOutputIntent`を追加しました。また、`OutputIntent`が欠落している場合にエラーを発生させる拒否パスを追加しました。Python検証ツールを拡張し、すべての辞書を走査し、`/Type /OutputIntent /S /GTS_PDFX`エントリと`/DestOutputProfile`がエミットされていることを確認します。

PDF/X関連の修正：v2.114では、透過処理の制限が追加されました（X-1aおよびX-3では、ExtGStateの塗りつぶし/線のアルファ値が1未満の場合、およびBM非正規の場合にエラーが発生します。X-4では、透過処理が許可されます）。また、ページボックスの適用が強化されました（§14.11.2に従い、すべてのページにTrimBoxまたはArtBoxが必要です）。v2.115では、禁止されている操作（/annot、/XFA）に関する制限が追加されました。これには、Movie、Sound、FileAttachment、Screen、JavaScript、Launch、SubmitForm、ImportData、およびXFAが含まれており、これらは印刷ワークフローには適さないため、拒否されます。

2026-05-19 Version 2.112.0

PDF/X（ISO 15930）印刷预处理功能的开发已开始。PDF/X是ISO家族中用于向商业印刷商发送已准备好的PDF文件的标准；X-1a（严格的CMYK + 专色）、X-3（ICC管理的颜色）和X-4（PDF 1.6的透明度 + ICCN）是业界广泛使用的三种配置文件。v2.112是第一部分，包含可选属性和身份元数据。完整的审计报告以及4个版本的开发计划已存档于.superpowers/specs/2026-05-19-pdfx-compliance-audit.md。

THotPDFクラスの新しい`PDFXCompliance: AnsiString`プロパティは、`''`（無効、デフォルト）、`'X-1a'`（ISO 15930-1:2001）、`'X-3'`（ISO 15930-3:2002）、または`'X-4'`（ISO 15930-7:2010）のいずれかの値を設定できます。空でない値を設定すると、HotPDFが構造的に満たすことができる、そのプロファイルに関連するすべてのプロデューサー側の要件が自動的に有効になります。

新しい `Trapped: AnsiString` プロパティ (PDFXCompliance の下で必須) は、`'True'`、`'False'`、または `'Unknown'` を受け入れます。PDF/X ファミリーでは、この DocInfo エントリが必須であり、印刷店は PDF がすでにトラップ処理されているか、プレプレスでトラップ処理が必要かどうかを知ることができます。これは、ISO 32000-1 §14.11.6.1 に従って、PDF の /Name (文字列ではない) として出力されます。例: `<< /Trapped /False >>`。

XMPメタデータの識別：このパケットは、``を仕様に正確に一致する文字列（`PDF/X-1:2001`、`PDF/X-3:2002`、または`PDF/X-4`）に設定し、(X-1a + X-4の場合) ``を完全なプロファイル名（`PDF/X-1a:2001`または`PDF/X-4:2010`）に設定して、`xmlns:pdfx="http://ns.adobe.com/pdfx/1.3/"`を広告します。Adobe Acrobatのプレフライト機能、Enfocus PitStop、callas pdfaPilotは、このドキュメントをPDF/Xの候補として認識します。

ドキュメントの検証：不明なプロファイル値を拒否し、空または認識されない「Trapped」値を拒否し、タイトルを必須とし、PDFのバージョンをプロファイルの必須最小バージョンに自動的に引き上げます（X-1a/X-3の場合、PDF 1.3、X-4の場合、PDF 1.6）。暗号化とPDFXコンプライアンスは互換性がありません。`EnableEncrypt`（または`ActivateProtection := True`）を呼び出すと、エラーが発生し、PDF/Xワークフローではパスワード処理なしですべてのオブジェクトを検査する必要があることを示す明確な診断が表示されます。

呼び出し元は引き続き、出力意図、ICCプロファイル、トリムボックス/アートボックス、有効なプリプレスカラー空間、正しいフォント埋め込み（およびX-1a/X-3の場合の透過性の回避）を行い、完全なPDF/X準拠を実現します。v2.113からv2.115までの修正により、これらの問題が解決されます。v2.113では、`AddPDFXOutputIntent`（必須の/GTS_PDFX意図）が追加されました。v2.114では、透過性の制限とページボックスの適用が追加されました。v2.115では、禁止されたアクション/アノテーション/XFAの制限が適用され、この一連の修正が完了しました。

Win32 および Win64 でクリーンなコンパイルが完了しました。v2.108、v2.109、v2.110、v2.111 のベースラインをすべて再コンパイルしましたが、変更はありませんでした。新しいテストスイート smoke_pdfx_optin は、3 つの PDF ファイル (プロファイルごとに 1 つ) を生成し、XMP 名前空間、GTS_PDFXVersion、GTS_PDFXConformance、DocInfo /Trapped /Name、無効なプロファイル、空の Trapped、不明な Trapped、および暗号化の競合に関するテストを実行します。

PAdESシリーズの注記：v2.109、v2.110、v2.111は、B-B、B-T、B-LT、B-LTAの形式と、独立したタイムスタンプの使用ケースを対象としています。元々計画されていたv2.112（独立したETSI.RFC3161タイムスタンプのみのPDF）は、v2.111で導入された`AddDocumentTimestampSignature`機能により、内部署名なしで新しいドキュメントに適用できるため、実質的に実装済みです。したがって、PAdESシリーズは3つのコミットで完了し、v2.112はPDF/Xに再割り当てされます。ETSI EN 319 142-1の基本プロファイルはすべてサポートされています。

2026-05-19 Version 2.111.0

PAdES プロデューサーシリーズ、パート 3/4：PAdES-B-LTA ドキュメントのタイムスタンプ署名機能を追加しました。これは、ISO 32000-1 §12.8.5 および ETSI EN 319 142-1 §5.7 に準拠しています。ドキュメントタイムスタンプは、長期検証署名が完了した後に適用される別の署名であり、LT 状態ファイル全体（元の署名 + DSS）を対象とし、長期保存に必要な情報が、公証された時点で存在したことを証明します。これは、EU の規制に準拠した長期保存に必要なアーカイブプロファイルです。

新しい `THPDFPage.AddDocumentTimestampSignature(FieldName, ContentsBytes)` ヘルパー機能を追加しました。通常の PAdES 署名とは異なり、ドキュメントタイムスタンプには以下のような特徴があります。

サブフィルターは `/ETSI.RFC3161` (RFC 3161 TimeStampToken、CAdESではありません)。

領域がゼロのウィジェット矩形 (タイムスタンプには目に見える表示がなく、純粋に暗号化されたメタデータのみが含まれます)。

`/Reason`、`/Location`、`/ContactName` は含まれません (これらは TST の署名属性に格納され、署名辞書には含まれません)。

デフォルトの `/Contents` バイト数は 16 KB です (呼び出し元は、1 KB までの小さい値を指定できます。完全な RFC 3161 TST と証明チェーンは通常、4 ～ 8 KB です)。

プロデューサの範囲はワイヤ形式で終了します。ヘルパーは、タイムスタンプ固有のSubFilterを持つ`/Type /Sig`プレースホルダー辞書を作成し、`/ByteRange`と`/Contents`の区切り文字を付加します。これにより、`PreparePDFForSigning`と`InsertSignatureHex`による後処理が可能になります。呼び出し元は、信頼できるタイムスタンプ認証局（TSA、例：DigiCert / GlobalSign / FreeTSAのHTTP POST）から実際のRFC 3161 TSTバイトを取得し、それを挿入します。一般的なPAdES-B-LTAアーカイブワークフローは次のようになります。1) PAdES-B-LTベースの署名を出力します（v2.109）、2) カタログの`/DSS`を証明書チェーンとOCSP/CRLで埋めます（v2.110）、3) インクリメンタルな更新として保存します、4) LT状態のバイトの上にドキュメントタイムスタンプフィールドを追加します（v2.111）、5) バイト範囲に基づいてTSAからTSTを要求します、6) TSTバイトを挿入します。

Win32 および Win64 でクリーンなコンパイルが完了しました。v2.108、v2.109、v2.110 のベースラインをすべて再コンパイルしましたが、変更はありませんでした。新しい smoke テスト `smoke_pades_doctimestamp` は、新しいヘルパーを使用して、PAdES-B-LT の 'SigInner' フィールドと 'DocTS' ドキュメントタイムスタンプフィールドを生成します。Python 検証ツールは、内部署名に `/SubFilter /ETSI.CAdES.detached` が設定されていることを確認し、タイムスタンプウィジェットの `/Rect` はゼロ領域であり、タイムスタンプの `/V` ディクショナリには `/SubFilter /ETSI.RFC3161` が設定されており、`/Reason`、`/Location`、`/ContactName` は存在せず、`/Contents` は 16 KB のプレースホルダー (16 進数で 32768 文字) です。

残りのPAdES機能：v2.112（可选），增加了独立的ETSI.RFC3161时间戳PDF文件（不包含CAdES内部签名，仅为纯时间戳文档容器）。

2026-05-19 Version 2.110.0

PAdES producerシリーズ、パート2/4：ISO 32000-2 §12.8.4.3 および ETSI EN 319 142-1 §5.6 に基づいた、Document Security Store (DSS) 辞書サポート。PAdES-B-LT (および B-LTA) では、検証に関連する情報（証明書チェーン、OCSP応答、CRLなど）をPDF自体に埋め込む必要があります。これにより、署名が元の署名時間から長い期間後に、外部のPKIサーバーを必要とせずに検証できるようになります。

THotPDF 增加了以下新功能：

`EnsurePAdESDSS` — 惰性地创建 Catalog /DSS 间接字典，其中包含其 /Certs、/OCSPs、/CRLs 数组以及一个空的 /VRI 子字典；后续调用将返回现有的字典。

`AddPAdESDSSCertificate(CertDERBytes)` — 将 DER 编码的 X.509 证书作为间接流附加到 /DSS /Certs；返回间接流对象，以便在 VRI 引用中使用。

`AddPAdESDSSOCSP(OCSPDERBytes)` — 类似地，用于将 OCSP BasicOCSPResponse 附加到 /DSS /OCSPs。

`AddPAdESDSSCRL(CRLDERBytes)` — 类似地，用于将证书撤销列表附加到 /DSS /CRLs。

`AddPAdESDSSVRI(SigContentsHexSHA1, Certs, OCSPs, CRLs)` — 创建一个基于签名 /Contents 字节的大写十六进制 SHA-1 值（规范要求的键格式）的每个签名的 VRI 条目；每个条目包含 /Cert、/OCSP 和 /CRL 数组，这些数组引用上方创建的间接流。

プロデューサの範囲はファイル形式のところで終了します。呼び出し元は、最終的な署名済みコンテンツのSHA-1値を計算し、PKIツールから取得したDERエンコードされた証明書、OCSP応答、およびCRLを提供します。一般的なワークフローは次のとおりです。まず、PAdES-B-Tベースの署名（バージョン2.109）を作成し、次に、長期検証のために、証明書、OCSP応答、およびCRLをDSSに追加し、検証情報を特定の署名にリンクするVRIエントリを添付します。

Win32 および Win64 でクリーンなコンパイルが完了しました。v2.108 および v2.109 を基準としたすべてのコンポーネントを再コンパイルしましたが、変更はありませんでした。新しいテスト `smoke_pades_dss` は、PAdES-B-LT 署名フィールドを作成し、DSS に 2 つの証明書、1 つの OCSP、および 1 つの CRL を追加し、テスト用の 16 進ダイジェストを含む VRI エントリを追加します。Python 検証ツールは、DSS 辞書の構造を検証します。具体的には、カタログ内の `/DSS` 参照、`/Certs`、`/OCSPs`、`/CRLs` 配列のカウント、VRI キーのマッチング、および VRI エントリの証明書/OCSP/CRL 参照が、最上位の DSS 配列と一致することを確認します。

残りのPAdES機能：v2.111实现了PAdES-B-LTA文档的时间戳签名（第二个Sig字段，SubFilter为ETSI.RFC3161，覆盖整个LT文件）；v2.112（可选）添加了独立的仅包含时间戳的PDF文件。

2026-05-19 Version 2.109.0

PAdES (ETSI EN 319 142) デジタル署名生成機能の開発を開始しました。v2.109では、既存のISO 32000-1 §12.8の署名基盤（AddSignedSignatureFieldヘルパーのv2）をラップする高レベルの機能を追加し、PAdESで必要なSubFilterをハードコードし、準拠プロファイルを検証します。完全な監査と4つのバージョンを含むロードマップは、.superpowers/specs/2026-05-19-pades-compliance-audit.mdにアーカイブされています。

新しい `THPDFPage.AddPAdESSignatureField(FieldName, Rect, Profile, Reason, Location, ContactName, ContentsBytes, Flags)` ヘルパー機能を追加しました。Profile パラメータは、ETSI EN 319 142-1 で定義されたベースラインレベルを選択します。'B-B' (基本的な CAdES、タイムスタンプなし)、'B-T' (RFC 3161 準拠の信頼できるタイムスタンプ付き、EU 法令で使用する場合の最低限の要件)、'B-LT' (長期検証のための DSS 検証情報付き)、または 'B-LTA' (アーカイブ用のドキュメントタイムスタンプ署名付き) が選択可能です。これらすべてで SubFilter は 'ETSI.CAdES.detached' を使用し、profile パラメータによって診断情報とデフォルトの /Contents バイト数が異なります。その他の profile 文字列は、ETSI で定義されている列挙子に従います。

自動調整されたコンテンツサイズ：PAdES-B-B および B-T のデフォルトは 16 KB です（呼び出し元はより小さい値を指定できます。ただし、v2.108 から引き継いだ 64 バイトの最小値を強制します）。PAdES-B-LT は、20 KB の最小サイズで自動調整されます（CAdES + 証明書チェーン + OCSP/CRL データ）。呼び出し元が指定したより大きな値はそのまま適用されます。ヘルパー関数は、最小値を引き上げることだけを行います。

Producerの範囲：このラッパーは、`/Type /Sig`プレースホルダー辞書を作成し、`/SubFilter /ETSI.CAdES.detached`、`/Reason`、`/Location`、`/ContactName`、`/M`（署名日）を設定し、`/ByteRange`と`/Contents`の区切り文字を付加します。実際のCMS/CAdESバイト、RFC 3161によるタイムスタンプ取得、OCSP/CRLの収集、およびDSS辞書の構築は、呼び出し元の責任となります。これらは、PDFプロデューサーの範囲外にある外部の暗号化ライブラリ（OpenSSL、Bouncy Castle、Windows CAPIなど）が必要です。

Win32 および Win64 でクリーンなコンパイルが完了しました。新しい smoke テスト `smoke_pades_signature` は、4 つの PAdES 署名フィールド (B-B / B-T / B-LT / B-LTA) を生成し、無効なプロファイル値がエラーを発生させることを確認します。Python 検証ツールは、AcroForm の `/SigFlags` が 3 であることを検証し、各ウィジェットが `/FT /Sig` と `/V` (間接参照) を持ち、それが `/Type /Sig` の辞書であり、その `/SubFilter` が `/ETSI.CAdES.detached` であることを確認します。また、`/Contents` のプレースホルダーの 16 進数表現の長さが、期待される (自動調整された) バイト数と一致することを確認します。

今後のPAdES機能追加計画：v2.110では、PAdES-B-LT検証情報（証明チェーン＋OCSP/CRL）用のカタログ/DSS（ドキュメントセキュリティストア）辞書作成機能を追加します。v2.111では、PAdES-B-LTAアーカイブ用のスタンドアロンドキュメントタイムスタンプ署名フィールドを追加します。v2.112（オプション）では、ETSI.RFC3161タイムスタンプのみのPDFを追加します。

2026-05-19 Version 2.108.0

PDF/A-2 および PDF/A-3 プロデューサー機能の改善（4/4）：ISO 19005-3 付属 E の関連ファイル。新しい高レベルのヘルパー関数 `AddPDFA3AssociatedFile(FileName, MimeType, Description, Relationship, FileBytes)` を使用すると、任意のファイル（XML 請求書、ソーススプレッドシート、JSON メタデータなど）を PDF/A-3 ハイブリッドコンテナに添付し、セクション E.4 の `/AFRelationship` セマンティクスに従って、カタログの `/AF` 配列に登録できます。

ハイブリッドコンテナワークフロー：典型的な使用例は、ZUGFeRD形式のPDF/A-3インボイスです。この形式では、人間が読めるインボイスの表示はPDFページのストリームに格納され、機械が読み取れるXMLソースが関連ファイルとして一緒に含まれます。`/AFRelationship`キーは、添付ファイルが可視コンテンツとどのように関連しているかを消費者に伝えます。値は以下の通りです：`'Source'`（元のデータ）、`'Data'`（PDFで可視化される生データ）、`'Alternative'`（代替表現）、`'Supplement'`（補足資料）、`'Unspecified'`（上記に該当しない）。

仕様の制限：`AddPDFA3AssociatedFile` 在 `PDFACompliance` 值不是 PDF/A-3 时会引发错误（附录 E 仅适用于第 3 部分），并提供诊断信息，建议使用 `AddFileAttachmentAnnotation` 用于 PDF/A-2，并指出 PDF/A-1 §6.1.11 明确禁止附加文件。如果 `FileName` 或 `MimeType` 为空，则会引发错误；如果 `Relationship` 值无效，则会引发错误，并参考规范 §E.4 中的枚举。

エミッション構造：間接的なEmbeddedFileストリームは、/Type /EmbeddedFile、/Subtype 、/Params <>、およびファイルバイトを含みます。間接的なFilespec辞書は、/Type /Filespec、/F、/UF（どちらも=ファイル名）、オプションの/Desc、/EF <>、および/AFRelationship（付録Eキー）を含みます。カタログの/AF配列は、最初の添付時に遅延して作成され、その後の呼び出しで追加されます。返されたFilespec辞書により、呼び出し元は必要に応じて、追加のオプションキー（例：/CIチェックサム/情報）を付加できます。

Win32およびWin64環境でのクリーンコンパイルが完了しました。新しいテストスイート`smoke_pdfa3_associated`は、実際のXMLインボイスを`/AFRelationship`ソースとして添付したPDF/A-3Bハイブリッドインボイスを生成し、その後、3つの拒否シナリオを実行します。具体的には、PDF/A-1、PDF/A-2、および無効な`/AFRelationship`に対する拒否処理を確認します。Python検証器は、`Filespec`と`EmbeddedFile`の辞書構造（`Type / F / UF / Desc / AFRelationship / EF F UF / EmbeddedFile Type / Subtype #2F escape / Params Size`）を検証します。

PDF/A-2 および PDF/A-3 のプロデューサー機能は、監査機能を完全に強化しました (v2.105 のオプション機能と XMP、v2.106 では注釈/アクションの利用を禁止、v2.107 では §6.1.13 の実装制限、v2.108 では付録 E の関連ファイル)。 PDF/A-1 (v2.101-104) および PDF/UA-1 (v2.94-v2.100) はすでに厳格な準拠状態であり、HotPDF は現在、PDF/A-1/2/3 および PDF/UA-1 のアーカイブ/アクセシビリティ機能に関するプロデューサーの全範囲を、最初から最後までサポートしています。

2026-05-19 Version 2.107.0

PDF/A-2 および PDF/A-3 プロデューサーシリーズのセクション 3/4：ISO 19005-2 §6.1.13 および ISO 19005-3 §6.1.13 の実装制限を適用します。PDF/A-1 §6.1.13 は大幅に緩く（文字列の長さの上限が厳密に設定されていない）、新しいチェックは、PDFACompliance が PDF/A-2 以降（'2*' または '3*'）の場合にのみ有効になります。

新しい公開メソッド `EnsurePDFAImplementationLimits` は、ドキュメントの呼び出し元が制御する値を、仕様で定められた上限値と比較します。具体的には、`Doc.Title`、`Author`、`Subject`、`Keywords`、`Lang` の文字列は、それぞれ 32767 バイト以下でなければなりません。また、各ページの `MediaBox` の寸法は、[3..14400] の範囲内になければなりません。`EndDoc` を呼び出すと、`PDFACompliance` が PDF/A-2/3 に設定されている場合に、検証が自動的に実行されます。また、呼び出し元は、ビルド中に直接検証を実行して、早期に問題を検出することもできます。

監査レポートに記載されている、自然に制限される範囲は以下の通りです。整数範囲は(-2³¹..2³¹-1)、実数範囲は(±3.403×10³⁸、ほぼゼロは≥1.175×10⁻³⁸)、名前の長さは≤127バイト、間接オブジェクトの数は≤8388607、q/Qのネストは≤28、DeviceNの色数は≤32、CIDは≤65535です。HotPDFのエミッションパスは、これらの制限を超えないように設計されており、これはHotPDFが制御するプロデューサー側のデータ構造に依存しているためです。バリデータは、呼び出し元から提供される文字列とページ境界に焦点を当てています。なぜなら、それらが現実世界の呼び出し元が突破できる唯一の制限だからです。

XFAフォーム（§6.4.2）：HotPDF不会生成AcroForm /XFA或Catalog /NeedsRendering。这些条件在PDF/A-1/2/3中自然满足，具体内容已在审计报告中记录，以防止未来的扩展功能重新引入这些元素。

.notdef グリフ（PDF/A-2 の §6.2.11.8）：仕様では、テキスト表示オペレーターが .notdef を参照することを禁止しています。HotPDF のフォント処理では、呼び出し元が登録済みの Unicode TTF フォントを使用する場合（v2.74-v2.86 のパス）、この問題を回避します。これは、プロデューサーがすべてのコードポイントを実際のグリフにマッピングするか、登録を拒否するためです。生のテキスト出力パスについては、呼び出し元が責任を負います。詳細は監査レポートに記載されています。

XMP名前空間（§6.6.2）：规范禁止在XMP数据包头中使用字节/编码属性。`BuildXMPPacket`函数生成一个最小化的头部（id="W5M0MpCehiHzreSzNTczkc9d"），该头部不包含任何属性，这在所有PDF/A部分中都能满足要求。

Win32およびWin64環境でのクリーンコンパイルが完了しました。新しいテストスイート「smoke_pdfa2_limits」では、3つのテストケースが追加されました。PDF/A-2のテストは、規定の範囲内で合格しました。32768バイトのタイトルを含むPDF/A-1のテストも合格しました（§6.1.13の制限は適用されません）。32768バイトのタイトルを含むPDF/A-2のテストは、仕様に違反しているとして拒否され、エラーメッセージが表示されました。以前のPDF/A-2/3のベースラインテストは、変更なしで再コンパイルされました。

PDF/A-2/3 プロデューサー機能の残りの部分：v2.108 は、PDF/A-3 の付録 E で定義されている関連ファイル（PDF/A-3 特有のハイブリッドコンテナ機能：カタログ内の /AF 配列、ファイル仕様、/AFRelationship キー、埋め込みファイル、/Params、/CheckSum、/ModDate）を実装します。

2026-05-19 Version 2.106.0

PDF/A-2 および PDF/A-3 プロデューサーシリーズのバージョン 2/4：PDF/A-2 の §6.3.1 および §6.5.1 (および同様の PDF/A-3 の §6.3.1 および §6.5.1) に対応。バージョン 2.104 で導入された、PDF/A-1 で禁止されている注釈とアクションの制限は、既に空でない PDFACompliance が設定されている場合に有効になっており、PDF/A-2/3 でも変更されずに引き続き有効です。バージョン 2.106 では、この動作が確認され、診断メッセージが、すべての PDF/A バージョンで共通の仕様セクションを参照するように更新され、HotPDF が自然に満たす、PDF/A-2 で新たに禁止されたサブタイプについて説明されています (公開 API は提供されていません)。

禁止操作矩阵：PDF/A-1 禁止 6 项操作（启动、声音、电影、重置表单、导入数据、JavaScript）。PDF/A-2 + PDF/A-3 将禁止的操作扩展到 13 项，增加了隐藏、设置 OCG 状态、呈现、转换、跳转到 3D 视图，以及已弃用的设置状态/无操作子类型。`AddLaunchLink` 仍然会触发；`HotPDF` 没有公开的入口可以触发其他 12 项操作，因此它们会自动满足。

禁止的注释类型矩阵：PDF/A-1禁止使用文件附件/声音/视频。PDF/A-2 / PDF/A-3取消了对文件附件的限制（在v2.105版本中已放宽），但将3D/屏幕添加到禁止列表中。`AddSoundAnnotation` + `AddMovieAnnotation`仍然在所有PDF/A部分中引发错误；由于HotPDF没有3D/屏幕的输出路径，因此这些情况自然满足。

診断メッセージの改善：三个 v2.104 版本的功能（AddSoundAnnotation、AddMovieAnnotation、AddLaunchLink）现在在错误文本中引用了所有三个相关的规范章节（例如，“PDF/A-1 §6.5.2 / PDF/A-2 §6.3.1 / PDF/A-3 §6.3.1”），以便开发人员能够了解统一的禁止规则。此外，AddLaunchLink 消息还详细列出了 PDF/A-2/3 扩展的禁止操作集合。

Win32およびWin64環境でのクリーンコンパイルが完了しました。新しいテストスイートsmoke_pdfa2_annot_actionは、すべての6つのPDF/A-2/3レベル（2B、2U、2A、3B、3U、3A）における3つの機能を検証します。各テストは、§6.3.1および§6.5.1に記載されている予期される例外を検証します。以前のPDF/A-1のベースラインテスト（smoke_pdfa1_compliance、smoke_pdfa1_forbidden、smoke_pdfa1_annot_action）およびv2.105のsmoke_pdfa2_complianceは、変更なしで再コンパイルされました。

PDF/A-2/3のプロデューサー関連機能の改善：v2.107では、ISO 19005-2 §6.1.13で規定されている実装制限（整数/実数/文字列/名前のバイト範囲、q/Qのネスト、DeviceNカラー、CID、ページ境界）に加え、§6.4.2のXFA、および§6.2.11のType 3/.notdefに関する厳格な要件が適用されます。v2.108では、PDF/A-3の付録Eで規定されている関連ファイル（さまざまな埋め込みファイル形式に対応したハイブリッドコンテナPDF）が実装されました。

2026-05-19 Version 2.105.0

PDF/A-2 (ISO 19005-2:2011) および PDF/A-3 (ISO 19005-3:2012) のプロデューサー準拠に関する一連の取り組みを開始しました。監査およびロードマップは、.superpowers/specs/2026-05-19-pdfa2-pdfa3-compliance-audit.md にアーカイブされています。v2.105 では、オプションのラッパー層、XMP pdfaid 名前空間の拡張、基本 PDF バージョンの自動更新 (1.7 へ)、および v2.101-104 の PDF/A-1 の厳格な制限を緩和しました。これらの制限は、PDF/A-2 および PDF/A-3 の仕様で明示的に許可されています。

PDFACompliance プロパティは、PDF/A-1 の '' / 'A' / 'B' に加えて、さらに 6 つの新しい値をサポートするようになりました。具体的には、'2A' / '2B' / '2U' (PDF/A-2 のレベル A / B / U) と、'3A' / '3B' / '3U' (PDF/A-3 のレベル A / B / U) です。レベル U は、PDF/A-2 で導入された新しい「Unicode のみ保持」の階層で、視覚的なテキストと Unicode で抽出可能なテキストを提供し、Tagged PDF の要件はありません。

BuildXMPPacket 機能を拡張しました。`` 要素は、解析されたパート番号 (1 / 2 / 3) を反映し、`` 要素は、解析されたレベルの文字 (A / B / U) を反映します。veraPDF などの検証ツールは、この組み合わせを使用してドキュメントの PDF/A パートを識別します。これは、ISO 19005-2 §6.6.4 および ISO 19005-3 §6.6.4 の表 8 に準拠しています。

自動バージョン更新：PDFACompliance '2*' / '3*' を設定すると、ドキュメントのバージョンが PDF 1.7 に自動的に更新されます。これは、PDF/A-2 と PDF/A-3 がどちらも ISO 32000-1 (PDF 1.7) に基づいているためです。PDF/A-1 は引き続き PDF 1.4 に準拠します。

v2.103：透明度に関する制限が緩和されました。`RegisterExtGState` 现在仅在PDFACompliance设置为PDF/A-1严格模式（'A'或'B'）时，才会因为透明度alpha值或非Normal混合模式而报错。PDF/A-2 / PDF/A-3 §6.4明确允许使用透明度（但有额外的要求，例如必须存在OutputIntent以及完整的PDF 1.4命名混合模式），因此，当PDFACompliance设置为'2*'/'3*'时，该调用可以正常通过。

v2.104：文件附件限制已放宽。`AddFileAttachmentAnnotation` 现在仅在 PDF/A-1 严格模式下才会引发错误。PDF/A-2 §6.3.1 仅禁止 3D、声音、屏幕和电影类型的注释；文件附件是被允许的，并且是 PDF/A-3 的附录 E 关联文件混合工作流程的基础。其他 v2.104 中的注释/操作限制（声音、电影注释；启动操作）仍然适用于所有 PDF/A 标准，具体取决于共享的 §6.3.1 + §6.5.1 的禁止规定。

新しいTHotPDFヘルパーメソッドであるPDFAPart、PDFAConformanceLevel、IsPDFA1Strict、IsPDFA2OrLaterにより、値の分岐処理がより使いやすくなりました。既存のv2.101-104のPDF/A関連機能は、これらのヘルパーメソッドを使用するように変更され、コードがより整理され、適切な場合にPDF/A-2またはPDF/A-3への移行を提案する、より明確なエラーメッセージが表示されるようになりました。

Win32およびWin64のクリーンコンパイルが完了しました。v2.101～104のベースライン（smoke_pdfa1_compliance、smoke_pdfa1_forbidden、smoke_pdfa1_annot_action）は、変更なしで再コンパイルされました。新しいsmokeテストであるsmoke_pdfa2_complianceは、4つのPDF（レベル2B、2U、2A、3U）を生成し、v2.103の透過性緩和、v2.104のファイル添付緩和、および2つの検証パス（無効な'4Q'レベルは拒否されました。PDF/A-1の透過性チェックは依然として有効）を実行します。Python検証ツールは、XMP pdfaid:partとコンフォマンスが各レベルで一致することを確認し、レベル2AではTagged-PDFの継承を確認します。

PDF/A-2/3のプロデューサー機能の改善：v2.106では、禁止アクションのセットが6つから13つに拡張されました（Hide、SetOCGState、Rendition、Trans、GoTo3DViewが追加され、非推奨のステート設定と何もしない操作が削除されました）。また、注釈タイプの禁止事項も調整され、3Dとスクリーンが追加され、ファイル添付が削除されました。v2.107では、ISO 19005-2 §6.1.13の制限事項とXFAの制限が適用されます。v2.108では、PDF/A-3の付録Eで定義されている関連ファイル（ハイブリッドコンテナPDF）が実装されました。

2026-05-19 Version 2.104.0

PDF/A-1 プロデューサー関連の修正（4/4）：ファイル添付、サウンド、ムービーといった禁止された注釈タイプ（§6.5.2）および起動アクションのサブタイプ（§6.6.1）を修正しました。v2.104 での変更により、2026年5月19日の PDF/A-1 監査（.superpowers/specs/2026-05-19-pdfa1-compliance-audit.md）で特定された、プロデューサー側の17件の未解決問題がすべて解決されました。これには、主要な問題点である識別（§5/§6.7.11）、暗号化の禁止（§6.1.3）、出力意図（§6.2.2）、透明度（§6.4）に加え、その他の禁止機能に関する修正が含まれます。

§6.5.2 禁止的注释类型：`AddFileAttachmentAnnotation`、`AddSoundAnnotation`和`AddMovieAnnotation`现在在`PDFACompliance`模式下会引发错误，并提供明确的规范章节信息。根据规范，“FileAttachment、Sound和Movie类型应被禁止”，以避免对外部内容的依赖以及在归档文件中使用多媒体内容。

§6.6.1 起動アクション：`AddLaunchLink` が `PDFACompliance` で例外を発生させるようになりました。例外には、起動対象を特定するための診断情報が含まれます。仕様では、「Launch、Sound、Movie、ResetForm、ImportData および JavaScript アクションは許可されません」と規定されています。他の 5 つの禁止されたアクションのサブタイプ（Sound/Movie/ResetForm/ImportData/JavaScript）には、それらを生成する公開 `HotPDF` エントリポイントが存在しないため、明示的な制限なしに、仕様に準拠します。

PDFUACompliance と PDFACompliance を組み合わせた機能が、すべての PDF/A 形式で正しく動作するようになりました。これらのオプションは階層構造になっており、レベル A では PDFUACompliance が自動的に有効になり、Tagged PDF が作成されます。また、両方の機能は、それぞれ PDF/UA および PDF/A に固有の制限（PDF/UA の場合は Suspects/Tabs/Lang、PDF/A の場合は Encrypt/Transparency/Annot/Action）を適用しますが、互いに干渉することはありません。

監査の完了概要：HotPDFが構造的に満たすことができる、すべてのPDF/A-1のプロデューサー側の§6のファイル形式要件について、対応が完了しました。呼び出し元の責任（§6.1.5 Info-XMPの同等性、§6.2.3.3 カラー空間とOutputIntentのマッチング、§6.3 フォントに関する詳細事項。これらはすでにv2.74からv2.86のPDF/UAの対応でほとんど処理されています）は、PDF/UA-1における対応する呼び出し元の責任と一致しています。

Win32およびWin64環境でクリーンなコンパイルが完了しました。v2.103のsmoke_pdfa1_forbiddenは、クリーンに再コンパイルされました。新しいsmokeテストであるsmoke_pdfa1_annot_actionは、PDFAComplianceの下にあるすべての4つのパス（AddFileAttachmentAnnotation、AddSoundAnnotation、AddMovieAnnotation、AddLaunchLink）を実行し、各呼び出しが§6.5.2または§6.6.1のエラーを発生させることを検証します。

PDF/A-1 のプロデューサー表面は、現在完全に監査が完了しました。今後の PDF/A-2 (ISO 19005-2:2011 に基づき、PDF 1.7 を使用し、透過性とレイヤーをサポート) および PDF/A-3 (ISO 19005-3:2012 に基づき、ハイブリッドワークフローのために埋め込みファイルを使用可能) の拡張機能は、今後の候補となりえますが、ユーザーからの要望に応じて検討されます。

2026-05-19 Version 2.103.0

PDF/A-1 producerシリーズのバージョン3/4：透明度に関するセクション6.4（重要な欠落箇所#15）と、ExtGStateの/TR転送関数に関するセクション6.2.8を修正しました（欠落箇所#14）。既存のHotPDFプロデューサーのパスに関連する2つのセクション6の要件は、コードの変更なしに自動的に満たされます。具体的には、LZWフィルター（HotPDFは書き込みパスで常にFlateDecodeを使用）と、画像に関する/Interpolate（HotPDFは/Interpolateを生成することはありません）。これらの点は、監査レポートで自動的に満たされるものとして文書化されています。

§6.4 透明度功能禁止使用非 1.0 的 alpha 值以及非 Normal/Compatible 的混合模式。RegisterExtGState 现在受到 PDFACompliance 的限制：如果填充 alpha 值小于 1，则会报错（PDF/A-1 要求 /ca = 1.0）；如果笔画 alpha 值小于 1，则会报错（/CA = 1.0）；如果混合模式不是 `Normal` 或 `Compatible`，则会报错。所有三个诊断都显示了规范章节和导致问题的数值。默认的 ExtGState（没有 alpha 键，没有混合模式）以及显式允许的值（1.0 的 alpha 值，Normal / Compatible 混合模式）保持不变。

§6.2.8 ExtGState 禁止使用 /TR 转换函数键（已弃用；PDF/A-1 仅允许使用具有 /Default 值的 /TR2，即使这样也最好避免）。现在，RegisterTransferFunctionState 在 PDFACompliance 模式下会引发错误，并提供明确的诊断信息。需要为 PDF/X 工作流程使用转换函数的调用者，仍然可以在 PDFACompliance 模式之外使用该辅助函数。

§6.1.10 LZW + §6.2.4 Interpolate: 记录显示，HotPDF现有的生成路径自然满足这些要求（仅使用FlateDecode的写入器，不生成/Interpolate）。无需修改代码；已在审计报告的注释中标记，以便未来的调用者不要重新引入这些功能。

Win32およびWin64環境でクリーンなコンパイルが完了しました。v2.102のsmoke_pdfa1_complianceテストが、問題なく再コンパイルされました。新しいsmokeテストであるsmoke_pdfa1_forbiddenでは、3つの条件付きパス（ca<1、CA<1、BM=Multiply、/TR登録）をすべて実行し、同時に、許可されたパス（ca=1.0、CA=1.0、BM=Normal/Compatible、アルファチャンネルなし）も正常に通過することを確認しています。検証機能は提供されていません。smokeテスト自体が、try/exceptブロックを使用して、各条件付き呼び出しが例外を発生させることを検証します。

PDF/A-1のプロデューサー機能の改善：v2.104では、セクション6.5.2で禁止されている注釈タイプ（FileAttachment、Sound、Movie）と、セクション6.5.3の注釈の/Fおよび/APルール、セクション6.6.1で禁止されているアクションタイプ（Launch、Sound、Movie、ResetForm、ImportData、JavaScript）、およびセクション6.9のフォームフィールドの/A、/AA、および/NeedAppearancesが修正されました。v2.104のリリース後、PDF/A-1プロデューサー機能は完全に監査が完了します。

2026-05-19 Version 2.102.0

PDF/A-1 (ISO 19005-1:2005) プロデューサーシリーズのスライス 2/4: §6.2.2 の OutputIntent と ICC プロファイルに関する問題が修正されました。新しい高レベルのヘルパー関数 `AddPDFAOutputIntent(OutputConditionIdentifier, Info, ICCProfileStream, NumComponents, AlternateCS)` が追加され、v2.51 の RegisterICCProfile + AddOutputIntent('GTS_PDFA1', ...) という2つの呼び出しを1つにまとめました。PDF/A-1 の厳格な仕様では、有効な `/DestOutputProfile` ICC ストリームを持つ `/Type /OutputIntent /S /GTS_PDFA1` エントリが必須であり、これがないと、準拠ファイルは異なるプラットフォームで正確な色を再現できません。

CRITICAL RULES — preserve verbatim, do NOT translate: - HTML tags: , , , , ,
, , ,
,
, etc. - HTML entities: ", &, <, >, , etc. - API names / identifiers: THotPDF, GetSingleSubstituteGlyph, TextOut, AddXFAPacket, RegisterUnicodeTTF, THPDFPage, AddTextField, RegisterSampledFunction, THPDFDictionaryObject, THPDFStreamObject, AddImageWithSMask, ShowImage, etc. - PDF spec references: "PDF 1.7 §12.7.6", "ISO 32000-1 8.9.5.4", "ISO 19005-1 §6.4.2", "UAX #38", "Unicode 16.0 §13.5", "ISO 14289-1", etc. - OpenType feature tags (single-quoted): 'liga', 'salt', 'aalt', 'init', 'medi', 'fina', 'isol', 'mong', 'arab', 'rlig', 'syrc', 'pres', 'cjct', 'akhn', 'rclt', 'clig', 'calt'. - Unicode block names / font names / codepoints: Arabic Extended-A, Mongolian Baiti, Noto Sans Mongolian, Devanagari, U+1800-U+18AF, U+0671, NIRUGU, LAM-ALEF, Estrangelo Edessa, Identity-H, etc. - PDF object names: /Fields, /XFA, /Filter, /WMode, /AcroForm, /Length, /MarkInfo, /StructTreeRoot, /Metadata, /Lang, /AP, /RV, /V, /DV, /DR, /MK, /AA, /SMask, /AIS, /BG, /UCR, /OP, /OPM, /SA, /RI, /FL, /TR, /CIDToGIDMap, /FontFile2, /W, /Encoding, /Default, /None, /SpotFunction, /Type, /ObjStm, etc. - Version numbers: v2.119.54, v2.84.0, v2.119.43-50, v2.55.0-v2.59.0, etc. - PDF operators: Tj, Tm, Td, T*, TL, Tf, BDC, EMC, scn, SCN. - Hex / numeric constants: $7FF8000000000000, 0x0002, U+FE70..U+FEFF, etc. - File / encoding names: CCITTFaxDecode, FlateDecode, UTF-16BE, DeviceGray, DeviceRGB, DeviceCMYK, Identity-H. Translate ONLY the descriptive English prose (verbs, adjectives, narrative sentences). Return ONLY the translation — no explanations, no markdown wrappers, no "[[N]]" tags, no leading/trailing whitespace, no extra newlines beyond what was in the input. TEXT: `EndDoc PDFACompliance`ゲートに、`EnsurePDFAOutputIntent`チェックが追加されました。このチェックでは、登録された`OutputIntent`リストを走査し、少なくとも1つの`/S /GTS_PDFA1`エントリがあり、かつ`/DestOutputProfile`が存在するかどうかを確認します。存在しない場合は、該当する仕様のセクションを明示的に示し、呼び出し元に対して`AddPDFAOutputIntent`を使用するように指示する診断メッセージが表示されます。これは、§6.2.2および付録Aに従います。
通常のアーカイブワークフローでは、画面表示用のPDF/Aの場合はsRGB IEC61966-2.1 ICCプロファイルストリームを、印刷用の場合はFOGRA39またはGRACOLを、またはプリプレス用の適切な登録CMYKプロファイルを渡します。`NumComponents`は、PDF 1.7 8.6.5.5の表66に従って、1（グレースケール）、3（RGB/Lab）、または4（CMYK）でなければなりません。ヘルパー関数は、検証を`RegisterICCProfile`に引き渡します。

Helper関数は検証を行います。空のOutputConditionIdentifierがあるとエラーになります（§6.2.2では、この識別子が必要です）。また、ICCProfileStreamがnilの場合もエラーになります（DestOutputProfileは必須です）。この関数は値を返しません。代わりに、OutputIntentは自動的にFOutputIntentsに登録され、既存のCatalog/OutputIntentsのシリアライゼーションパスを通じて利用可能になります。

Win32およびWin64のクリーンコンパイルが完了しました。`v2.101 smoke_pdfa1_compliance`が更新され、`AddPDFAOutputIntent`を呼び出すようになりました（192バイトの偽のICCプロファイルを使用します。実際の呼び出し元は、実際のICCバイナリを提供します）。新しい第4の検証ケースでは、`PDFACompliance`の下で`OutputIntent`が欠落している場合に、§6.2.2の診断エラーが発生することを確認します。Python検証ツールが拡張され、カタログの`/OutputIntents`配列をチェックし、`/S /GTS_PDFA1`を持つエントリを検索し、`/DestOutputProfile`のインデックス参照を検証します。

残りのPDF/A-1プロデューサー関連の修正：v2.103では、#15の透明度（重要）、#5のLZWフィルタ、#10の画像/補間、#14のExtGState /TRの問題を修正しました。v2.104では、#16のファイル添付/サウンド/ムービーのアノテーション、#17のアノテーションの/Fおよび/APルール、#18のフォームの起動/サウンド/ムービー/リセット/データインポート/JavaScriptアクション、#20のフォームフィールドの/Aおよび/AA、および/NeedAppearancesの問題を修正しました。

2026-05-19 Version 2.101.0

PDF/A-1 (ISO 19005-1:2005) 兼容性增强计划已启动，共包含四个版本，并支持通过包装层进行启用。完整的 17 项审计报告已存档于 `.superpowers/specs/2026-05-19-pdfa1-compliance-audit.md`。版本 v2.101 实现了基础功能（包括 PDFACompliance 属性、XMP pdfaid 标识、标题/语言的严格性以及加密冲突保护）。版本 v2.102 至 v2.104 解决了剩余的色彩管理、透明度、字体以及注释/动作方面的兼容性问题。

新しい `PDFACompliance: AnsiString` プロパティは、'' (無効、デフォルト)、'A' (レベル A: 視覚 + タグ付けされたPDF + アクセシビリティ)、または 'B' (レベル B: 視覚的な保持のみ) のいずれかの値を指定できます。無効な値が指定された場合、EndDoc時にエラーが発生します。これは、ISO 19005-1:2005 §5 に基づく適合レベルです。

`PDFACompliance` を `'A'` に設定すると、`PDFUACompliance` (レベル A) が自動的に有効になります (レベル A は、セクション 6.8 のタグ付き PDF の要件を継承し、これは PDF/UA-1 のセクション 7 の論理構造要件と一致します)。これらの機能は互いに競合することなく組み合わせることができます。 v2.94 の PDF/UA-1 言語/タイトル/疑わしい箇所機能は、v2.101 の PDF/A 保護機能の上に重ねて適用されます。

どちらかのレベルを設定すると、FEnableXMPMetadata が自動的に有効になり、ドキュメントに必須の /Metadata XMP ストリームが埋め込まれます。規格 §6.7.2 によると、カタログのメタデータは必須です。

BuildXMPPacket機能が拡張されました。PDFAComplianceが空でない場合、XMPパケットは`xmlns:pdfaid="http://www.aiim.org/pdfa/ns/id/"`に加え、`1`および`A`（または`B`）を宣言します。veraPDFや同様の検証ツールは、この正確なトリプレットを使用して、ドキュメントをPDF/A-1Aまたは1Bの候補として分類します。これは、§6.7.11の表6に示すPDF/A識別スキーマに基づいています。

タイトル/言語の厳格性：PDFACompliance が有効になっている場合、Doc.Title が空の場合（PDF/A-1 §6.7.3 では、XMP の Info /Title に相当する dc:title が必要）。言語の厳格性は v2.94 の PDFUACompliance の動作を反映しており（レベル A の場合は §6.8.4）、そのため、著者はデフォルトの 'en' にフォールバックするのではなく、有効な BCP-47 タグを選択する必要があります。

暗号化競合保護：根据 §6.1.3，文件尾部必须不包含 /Encrypt。EnableEncrypt（当 OwnerPassword/UserPassword/Protection 选项被设置时，内部调用的条目）现在在 PDFACompliance 不为空时，会引发带有明确诊断信息的错误。EndDoc 通过相同的路径暴露冲突，以便调用者在序列化之前看到失败。

呼び出し元側の責任には、引き続き以下の項目が含まれます。有効なPDF/A-1 OutputIntentをICCプロファイルとともに生成すること（v2.102に関する追跡）、透明度の使用を避けること（v2.103）、禁止されている注釈/アクションの種類の使用を避けること（v2.104）、およびレベルAに対応した、実際のセマンティック構造ツリーを作成すること（v2.96～v2.99のTagged PDFヘルパーで対応）。

Win32およびWin64でクリーンなコンパイルが完了しました。v2.100のベースラインテストであるsmoke_pdfua_link_contentsが、問題なく再コンパイルされました。新しいsmokeテストであるsmoke_pdfa1_complianceでは、レベルAおよびレベルBのPDFの両方を生成し、さらに3つの検証パスを実行します（無効なレベルZ、空のタイトル、暗号化とPDFAComplianceの競合）。Pythonの検証ツールは、xmlns:pdfaid、pdfaid:part=1、および一致するpdfaid:conformance、dc:titleを検証し、レベルAではさらに/MarkInfo /Marked true、Catalog /Lang、/StructTreeRoot、およびxmlns:pdfuaid（自動継承）も検証します。

2026-05-19 Version 2.100.0

2026-05-19の監査で特定された、PDF/UA-1 §7.18.5のリンク注釈の/Contentsに関する未対応部分を修正しました。v2.95では、AddURILinkにDescriptionを追加しました。v2.100では、残りの3つのリンク追加機能（AddGoToLink：ドキュメント内ジャンプ、AddGoToRLink：ファイル間ジャンプ、AddLaunchLink：外部ファイル起動）にも、同様の代替説明機能を追加しました。

各ヘルパー関数には、オプションで `const Description: AnsiString = ''` というパラメータが追加されました。このパラメータが空でない場合、アノテーション辞書には `/Contents (Description)` エントリが追加されます。`PDFUACompliance` モードでは、Description が空の場合、エラーが発生し、問題のあるリンクターゲットの名前が表示されます。これにより、代替説明が意図せず無視されるのを防ぎます。デフォルトでは空で、PDFUACompliance モードを使用しない場合の互換性を維持します。

PDF/UA-1 §7.18.5 に厳密に従って、「リンクには、ISO 32000-1:2008 の 14.9.3 に従って説明される Contents キーを介した代替説明が含まれていなければなりません。」この仕様は、URI リンクだけでなく、すべての種類のリンク注釈に適用されます。ヘルパーシグネチャの改善により、これが統一されました。

典型ワークフロー: `Page.AddGoToLink(R, 1, 700, 'Jump to page 2: Methodology'); Page.AddGoToRLink(R, 'companion.pdf', 0, -1, false, 'Open companion document for full data tables'); Page.AddLaunchLink(R, 'readme.txt', false, 'Open README in default text editor');`

Win32 および Win64 でクリーンなコンパイルが完了しました。v2.99 のベースライン smoke_pdfua_figure が、問題なく再コンパイルされました。新しい smoke テスト smoke_pdfua_link_contents は、0 ページに 3 つのリンク注釈を持つ 2 ページのドキュメントを構築します (1 ページへの GoTo、'companion.pdf' への GoToR、'readme.txt' の起動)。さらに、すべての 3 つのリンク注釈について、空の Description を持つ PDFUACompliance 例外パスもテストします。Python 検証ツールは、各リンク注釈が /Subtype /Link を持ち、対応するアクションタイプが /S /GoTo (または /GoToR または /Launch) であり、/Contents の値が提供された Description と一致することを確認します。

PDF/UA-1 プロデューサー側の機能要件の概要：v2.100 以降、4 つすべてのハイパーリンク注釈のエントリポイントが、§7.18.5 を満たすようになりました。これに、v2.94 の監査完了（「Suspects」、「Tabs」、「Lang」）、v2.95（「URI Contents」、「Bit 10」、「ID」）、および v2.96～v2.99 の「Tagged PDF」セマンティックヘルパーシリーズ（「Heading」、「List」、「Table」、「Figure」）の改善が加わったことで、HotPDF の PDF/UA-1 プロデューサー側の機能は、仕様に厳密なラッパー層と、使いやすい API レイヤーの両方で、完全に監査が完了しました。

2026-05-19 Version 2.99.0

PDF/UA-1 §7.3 (グラフィックス) のための、Tagged PDF セマンティックヘルパーシリーズの4番目および最終的な機能として、`BeginTaggedFigure(Parent, AltText, BBox): FigureElem` と `EndTaggedFigure` を追加しました。これにより、呼び出し元が提供する描画操作（画像 XObject、ベクトルパス、塗りつぶされた長方形）を、必須の /Alt 属性とオプションの /BBox レイアウト属性を持つ Figure 構造要素内に配置できます。

`/Alt` は必須であり、デフォルトの空の代替値はありません。PDF/UA-1 §7.3 の規定では、厳密に「図タグには、図タグでマークされた内容を表す代替表現または代替テキストが含まれる必要があります。」空の `AltText` を使用すると、明確なエラーメッセージが表示され、呼び出し元は `/ActualText` ( `/Alt` ではなく) が適切な代替テキストメカニズムである場合に、v2.88 の 6 引数 `AddStructureElement` オーバーロードを使用するように指示されます。

オプションの BBox は、図の境界ボックスをデフォルトのユーザー空間で記述する 4 つの値の配列 [llx, lly, urx, ury] であり、ISO 32000-1 14.8.5.4.5 の Layout 属性の所有者に従って、/A << /O /Layout /BBox [...] >> として添付されます。 BBox 属性を完全にスキップするには、空の配列を渡します。長さが正しくない BBox (1/2/3/5 個以上の要素) の場合、仕様の矩形レイアウトを参考にエラーが発生します。

典型的工作流程如下：`Fig := Doc.BeginTaggedFigure(Root, '公司标志：箭头指向右', [72, 600, 200, 720]); ... 绘制图形内容 ... Doc.EndTaggedFigure;` 此图形与其他 v2.90 的 BeginTaggedContent 路径一样，参与相同的 MCID / ParentTree 连接，但会自动附加 /Alt 和 /BBox 属性。

これにより、監査レポートからのPDF/UA-1 §7.3における呼び出し元責任に関する問題が修正されます。タグ付きPDFのセマンティックヘルパー機能は、現在、4種類の主要な構造タイプをすべてカバーします。これには、§7.4（見出し、v2.96）、§7.6（リスト、v2.97）、§7.5（表、v2.98）、および§7.3（図、v2.99）が含まれます。さらに、v2.94およびv2.95で修正されたラッパー層の修正により、HotPDFのPDF/UA-1プロデューサー機能は、仕様レベルでは厳密に準拠しており、APIレベルでも使いやすくなっています。

Win32およびWin64環境でクリーンなコンパイルが完了しました。v2.98のベースラインおよびsmoke_pdfua_tableが正常に再コンパイルされました。新しいsmokeテストであるsmoke_pdfua_figureは、2つのFigure構造要素（1つは/Altと/BBoxを持つ、もう1つは/Altのみを持つ）を出力し、さらに、空のAltTextと不正なBBoxの例外ケースをテストします。Python検証器は、両方のFigureの/Sタイプ、/Altテキストの内容、およびBBox配列の値が[72, 600, 200, 720]であることを検証します。

2026-05-19 Version 2.98.0

PDF/UA-1 §7.5 (表) に関する、タグ付きテーブルのヘルパーを4つ追加しました。これらは、タグ付きPDFのセマンティックヘルパーシリーズの3つ目の要素です。`BeginTaggedTable(Parent): TableElem` は、テーブル構造コンテナを作成します。`AddTaggedTableRow(Table): TRElem` は、TR行を追加します。`EmitTaggedTableHeader(TR, X, Y, Text, Scope): THElem` は、必須の/Scope属性を持つTHセルを出力します。`EmitTaggedTableCell(TR, X, Y, Text): TDElem` は、TDデータセルを出力します。すべての5種類のタグ（Table、TR、TH、TD、および属性オブジェクト）は、仕様に準拠しています。

/Scope 属性（ISO 32000-1 14.8.5.7 表 350）对于辅助元素是强制性的（没有默认值），有效值为 `Row`、`Col` 或 `Both`。无效的 Scope 字符串将引发错误，具体行为应参考规范。 PDF/UA-1 §7.5 严格规定：“类型为 TH 的结构元素必须具有 Scope 属性。如果无法通过表头和 ID 确定表格的结构，则类型为 TH 的结构元素必须具有 Scope 属性。” 在辅助元素的签名中强制指定 Scope 可以防止因缺少 Scope 属性而导致的兼容性问题。

範囲のシリアル化は、標準的な属性オブジェクト形式に従います。具体的には、`/A << /O /Table /Scope / >>` (ISO 32000-1 14.7.5.3 Class Mapを参照) のように記述され、これにより、読み込み側はこれをTable名前空間の属性として認識します。これは、v2.97で導入されたリスト属性 `/A << /O /List /ListNumbering ... >>` と同じパターンです。

テーブルとTRは構造コンテナであり、ページ上にマークされたコンテンツは含まれていませんが、THとTDには表示されるテキストが含まれているため、両方ともBeginTaggedContent、TextOut、EndTaggedContentの処理を行います。各THとTDセルは、独自のMCID、ページコンテンツストリーム内のBDC演算子、およびParentTreeエントリを持ちます。ヘルパー関数は、呼び出し元がさらに属性（例えば、複雑なテーブルの/Headersリスト、/RowSpan、/ColSpanなど）を関連付けるために必要な、セルのStructElemを返します。

典型ワークフロー：`T := Doc.BeginTaggedTable(Root); R := Doc.AddTaggedTableRow(T); Doc.EmitTaggedTableHeader(R, 72, 750, WideString('Name'), 'Col'); Doc.EmitTaggedTableHeader(R, 200, 750, WideString('Age'), 'Col'); R2 := Doc.AddTaggedTableRow(T); Doc.EmitTaggedTableCell(R2, 72, 730, WideString('Alice')); ...` これは、v2.90で導入された、各セルに対して複数のステップとBDC/EMCシーケンスを使用する構造を置き換えます。

これは、監査レポートからのPDF/UA-1 §7.5における呼び出し元の責任に関する問題を修正します。タグ付きPDFのセマンティックヘルパーシリーズは、現在§7.4（見出し、v2.96）、§7.6（リスト、v2.97）および§7.5（表、v2.98）をカバーしています。残りの部分（v2.99以降）：/BBoxおよび/Altを含む、呼び出し元が提供する描画ブロック用の図ヘルパー機能。

Win32およびWin64でクリーンなコンパイルが完了しました。v2.97のベースラインおよびsmoke_pdfua_listが、クリーンに再コンパイルされました。新しいsmoke smoke_pdfua_tableは、3行のテーブル（1つのヘッダーと2つのデータ行）を構築します。このテーブルには、3つのTHセル（Scope=Col）と6つのTDセルが含まれており、無効なScopeに関する例外もテストされます。Pythonの検証器は、完全なTable > TR > TH/TD構造を検証し、すべてのTHに/Scope /Col属性が存在することを確認します。

2026-05-19 Version 2.97.0

PDF/UA-1 §7.6のリストヘルパーを2つ追加しました。これは、Tagged PDFのセマンティックヘルパーシリーズの第2弾です。`BeginTaggedList(Parent, NumberingStyle): ListElem`は、ISO 32000-1 14.8.5.5に従って、/A << /O /List /ListNumbering /<Style> >>という属性オブジェクトを持つL構造要素を構築します。`EmitTaggedListItem(ListElem, LblX, LblY, LabelText, BodyX, BodyY, BodyText): LIElem`は、表示されるラベルと本文テキストの両方に対してマークされたコンテンツを持つ、完全なLI > {Lbl, LBody}の部分構造を生成します。

`NumberingStyle` 参数接受 PDF/UA-1 / ISO 32000-1 规范中定义的 8 个名称：`None`、`Decimal`、`UpperRoman`、`LowerRoman`、`UpperAlpha`、`LowerAlpha`、`Circle`、`Disc`。如果指定的样式名称无效，则会引发错误，并提供导致错误的具体值以及完整的规范作为参考。如果为空字符串，则完全省略 `/ListNumbering`，以便调用者可以在提交之前附加自定义属性对象。

PDF/UA-1 §7.6に従って：順序付きリストには、明示的な/ListNumbering属性が必要です。一方、順序なしリストには、`None`または箇条書きのグリフのいずれかを使用できます。この機能は、どちらの形式も強制しません。ユーザーが、表示内容に一致するスタイルを選択する必要があります。

典型的工作流程如下：`Lst := Doc.BeginTaggedList(Root, 'Decimal'); Doc.EmitTaggedListItem(Lst, 72, 750, WideString('1.'), 96, 750, WideString('First item')); ...` 每一个列表项都用一次调用替换了 v2.90 中的六行代码，即 LI + Lbl-BDC-TextOut-EMC + LBody-BDC-TextOut-EMC 链。

Lbl と LBody の子要素はどちらも `BeginTaggedContent` を経由します（そのため、それぞれに独自の MCID と ParentTree エントリが割り当てられます）。また、`EmitTaggedListItem` ヘルパー関数は、ネストされた LI 子要素、/Alt、または /Lang を追加したい呼び出し元のために、LI 構造要素を返します。

これは、監査レポートからのPDF/UA-1 §7.6における呼び出し元の責任に関する問題を修正します。残りのTagged PDFのセマンティックヘルパー機能（v2.98以降）：§7.5をカバーするテーブルヘルパー（テーブル/TR/TH/TD要素および/Scope属性）、および§7.3をカバーする図ヘルパー（図要素および/Altおよび/BBox属性）。

Win32およびWin64でクリーンなコンパイルが完了しました。v2.96のベースラインおよびsmoke_pdfua_headingが正常に再コンパイルされました。新しいsmoke smoke_pdfua_listでは、3つの項目を持つ十進数で番号付けされた順序付きリストと、2つの項目を持つ番号なしの順序なしリストが作成され、無効なスタイルの例外処理もテストされます。Pythonの検証器は、異なる/ListNumbering属性値を持つ2つの/S /L StructElems（それぞれ3つと2つのLIの子要素を持つ）、および順序付きリストの最初のLI要素におけるLbl/LBodyの子要素を検証します。

2026-05-19 Version 2.96.0

PDF/UA-1 §7.4に対応するため、`EmitTaggedHeading(Level, Parent, X, Y, Text)`という高レベルのヘルパー関数を追加しました。この関数を1回呼び出すと、現在のページに`/H1`から`/H6`までの構造要素が生成され、それに対応するテキストが表示されます。ヘルパー関数は、ページごとにMCIDを割り当て、BDCオペレーターを実行し、`TextOut`を実行した後、EMCを実行し、適切な`/H<Level>`ロールを持つ`StructElem`を構築し、それを`/ParentTree`に接続します。このヘルパー関数は、一般的なヘッダーの場合、v2.90で用いられていた3行の`BeginTaggedContent + TextOut + EndTaggedContent`という記述を置き換えます。

レベルパラメータは1～6の範囲を受け入れます（標準のヘッダーセット）。範囲外のレベルの場合、明確な診断メッセージを含む例外が発生します。PDF/UA-1 §7.4.3では、ユーザー定義のH7+タグが許可されていますが、これらはまれです。それらを必要とする呼び出し元は、明示的なBeginTaggedContent('H7', ...)シーケンスを使用します。

これにより、呼び出し元はヘルパー関数が値を返した後、属性の追加（/Lang、装飾的な見出し用の/Altなど）をチェーン処理できるようになります。

通常的工作流程：`Doc.EmitTaggedHeading(1, RootElem, 72, 750, WideString('Chapter 1'));` 现在完全取代了原本复杂的、包含多行 BDC + TextOut + EMC + AddStructureElement 的代码。

これは、計画されている「Tagged PDF セマンティックヘルパー」シリーズの最初の部分であり、v2.95 の PDF/UA-1 ラッパーの完了に続くものです。今後のバージョン（v2.97 以降）では、リスト（L / LI / Lbl / LBody）およびテーブル（Table / TR / TH / TD with /Scope）のヘルパーを提供し、監査レポートの §7.5 および §7.6 で定義されている、呼び出し元の責任範囲を解消します。

Win32 および Win64 でクリーンなコンパイルが完了しました。v2.95 のベースラインが、問題なく再コンパイルされました。新しいテスト smoke_pdfua_heading は、3 つの見出し (H1/H2/H3) を生成し、Level=7 の範囲チェック例外パスを検証します。Python 検証器は、展開されたページコンテンツストリーム内で、3 つの /S /H StructElems と、それに対応する /H BDC オペレーターをアサートします。

2026-05-19 Version 2.95.0

PDF/UA-1 監査の完了：v2.94 の監査で特定された残りの 3 つの問題点を修正しました（§7.18.5 リンクの内容、§7.16 暗号化のビット 10、§7.9 StructElem ID）。PDF/UA-1 の実装は仕様を完全に満たすようになりました。v2.94 と v2.95 で、当初の監査で特定された 6 つの問題点すべてを修正しました。

§7.18.5 リンクの内容 (重要): `AddURILink(Rect, URL, Description='')` に、3番目の `Description` パラメータが追加されました。このパラメータが空でない場合、指定された代替説明文が、アノテーションの `/Contents` キーに設定されます。PDF/UA-1 §7.18.5 では、これが必須とされています。「リンクには、その Contents キーを介して代替説明文が含まれる必要があります。」PDFUACompliance モードでは、空の Description が設定されると、明確なエラーメッセージが表示され、すべてのリンクにスクリーンリーダーで読み取れるテキストが常に表示されるようにします。互換性のために、PDFUACompliance モード外では、Description のデフォルト値は '' です。

§7.16 暗号化ビット10 (MED): PDFUAComplianceがTrueであり、ドキュメントが暗号化されている場合 (EnableEncryptを介して)、HotPDFは自動的に`ProtectFlags := ProtectFlags or $200`を設定します (ビット10は「支援技術でのテキストとグラフィックスの抽出を可能にする」を意味します)。PDF/UA-1 §7.16によると: 「暗号化された準拠ファイルは、暗号化辞書にPキーを含める必要があります。Pキーの10番目のビット位置はTrueでなければなりません。」このビットがないと、スクリーンリーダーは暗号化されたPDFからコンテンツを抽出できず、アクセシビリティが損なわれます。この修正は条件付きであり、PDFUAに準拠していない暗号化では、呼び出し元が提供したフラグは変更されません。

§7.9 StructElem ID (LOW): 新しい7引数の `AddStructureElement` のオーバーロードでは、空でない `IDStr` パラメータを受け取り、構造要素の `/ID` キーに値を設定します。このヘルパーは、発行されたIDの内部セットを維持し、衝突が発生した場合はエラーを発生させます。これにより、重複したノートIDが混入するのを防ぎます（重複したノートIDは、クロスリファレンスのリンク→ノートへのジャンプや支援技術に混乱を引き起こす可能性があります）。仕様によると、「各ノートタグには、IDキーに一意のエントリが必要です。」

EnableEncryptのリファクタリング：元の処理は`EnableEncryptInternal`に移動され、公開APIである`EnableEncrypt`は6行のラッパー関数で、まずPDF/UA-1のビット10のスタンプを行い、その後、処理を転送します。v2、v4、v5の暗号化の処理は、元のコードと完全に同じです。既存の暗号化PDFの呼び出し元は、PDFUAComplianceを明示的に有効にしない限り、同じバイト単位の出力を維持します。

検証カバレッジ：新しい`smoke_pdfua_gap_closure`テストケースを追加しました。これには、セクション7.18.5（説明付きのリンク）とセクション7.9（異なるIDを持つ2つの「注」要素と、エラーを発生させるべき衝突試行）が含まれます。検証器は、`/Contents`が存在し、説明と一致すること、および2つの異なる「注」`/ID`の値が存在することを検証します。暗号化されたPDFのビット10の修正は、監査レポートに記載されています。暗号化されたPDFのテストは、より大規模な暗号化テストの再設計に defer されます。

仕様の対応状況：v2.95のリリースにより、2026年5月19日のPDF/UA-1監査（`.superpowers/specs/2026-05-19-pdfua-compliance-audit.md`）で特定された6つの問題がすべて解決されました。HotPDFのPDF/UA-1に関するプロデューサー側の要件は、ラッパーレイヤーにおいて、完全に準拠しています（§5 メタデータ、§6 準拠、§7.1 カタログの要件、§7.2 言語、§7.16 暗号化、§7.18.3 タブ、§7.18.5 リンクの内容、§7.9 注釈ID）。セマンティック構造ツリーに関する決定（見出しの階層、リストのネスト、テーブルのTH/スコープ、図/代替テキストの品質）は、従来通り、呼び出し元の責任範囲です。

2026-05-19 Version 2.94.0

PDF/UA-1 (ISO 14289-1:2014) 生产方合规性审计的后续工作：修复了三个实际的合规性问题，这些问题在 v2.87 的高级选项中未被覆盖。此次审计将 HotPDF v2.93 的输出与每个 §7 文件格式要求的条款进行了交叉检查，并发现了六个生产方问题；此版本解决了三个 EndDoc 阶段的修复（Suspects 密钥、带注释的页面选项卡、Lang 的严格性）。剩余的三个问题（链接内容、加密的第 10 位、StructElem ID）将在 v2.95-v2.97 版本中解决。

§7.1 疑点 (高優先度): Catalog 字典现在在 `PDFUACompliance` 为 True 时，会发出 `/Suspects false`。根据规范“声称符合此国际标准的文件的 Suspects 值为 false”，veraPDF 和类似的验证器会检查该键是否存在，而不仅仅是其不存在。在 v2.93 版本中，完全省略了该键，这在严格的规范验证下触发了“Catalog MarkInfo 不包含 Suspects 条目”的错误。

§7.18.3 タブ (MED 深刻度): `EndDoc` は現在、すべてのページを走査し、非空の `/Annots` 配列を持つページ、または `/Tabs` をすでに宣言していないページに `/Tabs /S` を設定します。仕様では、「注釈を含むすべてのページには、ページ辞書にキー `Tabs` が含まれており、その値は `S` でなければならない」と規定されています。これは `PDFUACompliance` の場合にのみ有効になります。`/Tabs` を `THPDFPage.SetTabsOrder` を使用して明示的に設定した呼び出し元は、その設定を維持します。

§7.2 Lang (重大度: MED): `PDFUACompliance=True` 且 `Doc.Lang` 为空时，现在会引发异常，并显示明确的诊断信息，而不再静默地填充 `'en'`。在 v2.94 之前的版本中，如果文档不是英文，则会错误地标记非英语文档（任何中文/阿拉伯语/日语等内容都会静默地输出错误的 BCP-47 标签，而屏幕阅读器会使用该标签来切换发音）。现在，调用者必须显式声明文档的语言——常见的用法包括：`Doc.Lang := 'en-US'`、`'zh-CN'`、`'ar-SA'` 等。

互換性に関する注意点：既存のPDFUAComplianceを使用しているコードでは、BeginDoc/EndDocの前に`Doc.Lang := '...'`を追加する必要があります。4つのサンプルテスト（smoke_pdfua_compliance、smoke_pdfua_alt_actualtext、smoke_pdfua_annot_structparents、smoke_pdfua_tagged_content）は、`Doc.Lang`を`'en-US'`に設定するように更新されました。PDFUAComplianceを使用していないコードには影響はありません。

`smoke_pdfua_compliance_verify.py` 现在在 Catalog MarkInfo 字典中断言 `/Suspects false`；`smoke_pdfua_annot_structparents_verify.py` 在注释页面上断言 `/Tabs /S`。这两个脚本都对生成的 PDF 文件进行端到端的测试。

監査レポート：PDF/UA-1 への完全準拠監査レポートが、すべての 21 項目の §7 ファイル形式条項を網羅しており、`.superpowers/specs/2026-05-19-pdfua-compliance-audit.md` にアーカイブされています（プロジェクトローカル、コミットされていません）。このレポートでは、各条項が「HotPDF が自動的に満たす」、「ヘルパー API を使用した呼び出し元の責任」、または「実際のプロデューサー側のギャップ」のいずれかに分類され、残りのギャップは v2.95 以降のロードマップで重要度に応じてランク付けされています。

2026-05-19 Version 2.93.0

`RegisterColorConversionLUT3D(GridR, GridG, GridB, OutputComponents, Samples, BitsPerSample=8, Order=1): THPDFStreamObject` が追加されました。これは、一般的な3入力カラーマネジメントLUTユースケースに対応する、v2.52のFunction Type 0プリミティブをラップする高レベルの機能です。内部的には、標準の /Domain=[0,1]*3 + /Range=[0,1]*OutputComponents + /Size=[GridR, GridG, GridB] 配列を構築し、RegisterSampledFunctionに渡します。

一般的なワークフローでは、ICCプロファイルに基づいたsRGBからLabへの変換、sRGBからCMYKへの変換、またはRGBからRGBデバイスリンク変換が行われ、これらは3D LUTとして表現されます。ラッパーは、各軸のグリッドサイズと出力コンポーネントの範囲を検証します。また、RegisterSampledFunctionは、BitsPerSample、Order、および合計バイト数と、期待されるサンプルペイロードサイズを比較します。一致しないバッファが見つかった場合、エラーが発生し、詳細な診断情報が表示されます。

サンプルバイトレイアウト：3Dグリッド上で、Rが最も速く、次にG、そしてBの順に配置されます。BitsPerSampleが8の場合、各セルあたりOutputComponentsバイトです。合計は、GridR * GridG * GridB * OutputComponentsバイトです。より高いビット深度（12、16）の場合、仕様のMSBファーストのバイトパッキングルールに一致する、呼び出し元がパッキングしたペイロードが必要です。

ユーザーに可視化される変更点：カラー管理ワークフローにおいて、17x17x17のRGBからCMYKへのICCシミュレーションを、事前に計算されたサンプル配列を使用して1行で表現できるようになりました。これにより、従来の手動での`/Domain`、`/Range`、`/Size`の設定が不要になります。返される間接的な`THPDFStreamObject`は、あらゆる関数を扱うAPIに統合可能です。具体的には、パターンタイプ2の軸方向/放射状グラデーション、`RegisterSeparationLUT`による分離トーン変換、`/TR`トランスファー関数、および`/BG`ブラック生成ExtGStateで使用できます。

互換性：现有的 `RegisterSampledFunction` 函数保持不变；新的包装器是一个简单的补充。需要使用非默认的 `/Domain`（例如，Lab L* 在 [0..100] 范围内，a* / b* 在 [-128..127] 范围内）或非矩形范围的用户，继续直接使用 `RegisterSampledFunction`。

候補 #4 の状態：これは、マトリックス候補「3D Function Type 0」の唯一の要素です。この高レベルのラッパーにより、既存の N=3 の基本的な機能が、一般的なカラー管理のユースケースにおいて使いやすくなります。候補 #4 は完了しました。

2026-05-19 Version 2.92.0

`RegisterHalftoneType5(ColorantNames, Halftones, DefaultHalftone, HalftoneName)` が追加され、ExtGState の `/HT` ハルftone ファミリが完了しました。Type 5 は、カラー名 (例: /Cyan、/Magenta、/Yellow、/Black、/Red、/Green、/Blue、/Gray、および登録された Separation/DeviceN スポットカラー) をキーとする、複数のコンポーネントを持つ辞書であり、その値は Type 1/6/10/16 のサブハルftone への間接参照です。これにより、CMYK 印刷ワークフローにおいて、各インクに個別のスクリーン周波数/角度/ドット形状を、単一の ExtGState エントリで設定できるようになりました。

並列配列シグネチャ：`ColorantNames` と `Halftones` がペアで一致し、同じ長さであることを検証します。空のカラー名またはnilのハーフトンは、問題のあるインデックスでエラーを発生させます。オプションの `DefaultHalftone` は、辞書の `/Default` として機能し、明示的なリストにないカラー名に対して、読み込み側がデフォルト値として使用します（これは、予期しないスポットカラーを含むドキュメントでよく見られます）。

出力される辞書の構造如下 (PDF 1.7 ISO 32000-1 10.5.5.2): /Type /Halftone + /HalftoneType 5 + 可选的 /HalftoneName + 每个对都包含一个 /ColorantName 条目 + 可选的 /Default。返回间接的 THPDFDictionaryObject，以便调用者可以将它传递给 v2.64 中的 `RegisterHalftoneState` 函数，就像传递其他 halftone 对象一样。

検証：少なくとも1つのコンポーネント、または `DefaultHalftone` が必要です（`/Default` なしで空の Type 5 は意味的に無効です）。このヘルパーは、提供されたサブハーフトーンが Type 5 でないかどうかを検証しません（仕様では Type 5 のネストが禁止されています）。これは、呼び出し元が自己参照グラフを積極的に構築する必要があるためです。実際のプリプレスワークフローでは、このような状況は発生しません。

ユーザーに可視化される変更点：プリプレスエンジニアが4色のパンフレットを作成する際、4つの独立したスクリーン（シアン：105° / 75 lpi、マゼンタ：75° / 75 lpi、イエロー：90° / 75 lpi、ブラック：45° / 75 lpi。Type 1スポット関数を使用するか、FMスクリーニングの場合はType 6のスレッショルドラスターで代替可能）を設定し、これらを1つのExtGStateでまとめることができます。その後、これらのスクリーンが必要な描画コマンドでExtGStateが有効になります。

候補 #3 の状態：これは、ExtGState `/HT` ハルftone ファミリーの 2 番目であり、最終的なバージョンです。完全な機能セット（v2.64 の Type 1 スポット関数、v2.92 の Type 5 マルチコンポーネント、v2.91 の Type 6/10/16 スレッショルドストリーム）は、現在 PDF 1.7 仕様に準拠しています。候補 #3 の開発は終了します。

2026-05-19 Version 2.91.0

v2.64で開始されたExtGState `/HT`ハルftoneファミリーを補完するため、3つのスレッショルドストリームハルftoneジェネレーターを追加しました。これらは、`RegisterHalftoneType6`（幅/高さでキーされる8ビットスレッショルドラスター）、`RegisterHalftoneType10`（Xsquare/Ysquareを使用して角度付きのスクリーンを作成する、平行四辺形のセルを持つ8ビットスレッショルドラスター）、および`RegisterHalftoneType16`（高解像度のプレプレス向けに、65536レベルの精度を持つ16ビットスレッショルドラスター）です。

各ビルダーは、間接的な `/Type /Halftone` ストリームオブジェクトを返し、呼び出し元はこのオブジェクトを v2.64 の `RegisterHalftoneState` に渡して、ExtGState の `/HT` エントリでラップできます。これは、Type 1 のスポット関数ハルftone とまったく同じです。オプションの `/HalftoneName`、`/TransferFunction` または `/TransferFunction /Identity` エントリは、Type 1 のパターンと一致します。

サイズ検証：タイプ6では、`len(ThresholdBytes)`は`Width*Height`と等しくなければなりません。タイプ10では、`Xsquare^2 + Ysquare^2`（PDF 1.7 §10.5.5.4におけるスタックされた正方形のレイアウト）を満たす必要があります。タイプ16では、`Width*Height*2`（リトルエンディアンのuint16ペアで、呼び出し元が提供）である必要があります。バッファの不一致は、実際のバイト数と期待されるバイト数の両方を含む例外を発生させます。

内部ヘルパー関数 `_HotPDFCreateHalftoneStream` は、各タイプごとの構築処理を共通化し、以下の処理を重複して行わないようにします。具体的には、間接ストリームの割り当て、`/Type /Halftone` および `/HalftoneType N` ヘッダー、オプションの名前と変換関数エントリ、ペイロードの書き込み、および `/Length` の設定を行います。各公開関数は、タイプ固有のサイズキーの検証のみを行い、処理を転送します。

ユーザーに可視化される変更点：ユーザーが定義したスクリーンパターン（カスタムドット形状、周波数変調スクリーン、傾斜セル）が必要なプリプレスワークフローにおいて、HotPDFのエントリポイントが提供されます。呼び出し元は、通常オフラインでスクリーンパターンジェネレーターから作成する閾値ラスターデータを供給し、HotPDFは仕様に準拠した/Type /Halftoneストリームオブジェクトを生成し、それをExtGStateリソースチェーンに接続します。

PDF 1.7 および ISO 32000-1 の 10.5.5.3 (Type 6) + 10.5.5.4 (Type 10) + 10.5.5.5 (Type 16) の仕様をサポートします。自動的に PDF 1.2 にバージョンアップします (Type 1 の最低要件に準拠するため)。

候補 #3 の状態：这是“ExtGState /HT halftone remaining types”矩阵候选的第一个部分。类型 5 的多组件半色调（由颜色组件名称键控的字典，并委派给类型 1/6/10/16 的子字典以实现每个通道的屏幕，用于 CMYK 预印）是第二个也是最终的部分，将在 v2.92 版本中发布。

2026-05-19 Version 2.90.0

`THotPDF.BeginTaggedContent(Role, Parent): THPDFDictionaryObject` および `THotPDF.EndTaggedContent` という、マークアップコンテンツの処理を支援する新しい機能が追加されました。この機能は、各ページごとにMCIDを自動的に割り当て、現在のページのコンテンツストリームにBDCオペレーターを生成し、指定された親ノードの下にStructElemを構築し、/ParentTreeに接続します。これにより、PDF/UA-1を使用するユーザーは、MCIDカウンターを手動で管理することなく、表示されるコンテンツの段落にタグを付けることができます。

通常用法如下：`Para := Doc.BeginTaggedContent('P', Root); Doc.CurrentPage.TextOut(...); Doc.EndTaggedContent;` 返回的 StructElem 可以链接到 AddStructureElement('Span', Para, ...) 以创建子结构，或者通过 v2.88 属性路径传递 /Alt 和 /ActualText。

新しいTHPDFPage.FNextMCIDフィールドは、各ページごとのMCID割り当てを追跡します。これは、各ページごとにリセットされ、BeginDocの初期化時に遅延初期化されます（初期値は0）。低レベルのBeginMarkedContentMCID / EndMarkedContentオペレーター（HotPDFのv2.11以降で利用可能）は、MCIDを明示的に制御したいユーザーのために引き続き利用可能です。

パイプライン統合：`BeginTaggedContent` には、現在のページコンテンツストリームに "/Role <> BDC" を出力し、`AddStructureElement(Role, Parent, PageIdx, MCID)` を呼び出す処理が含まれます。この処理は、`StructElem` を構築し、`RegisterMCIDForPage` を実行します（これは、ページ辞書に `/StructParents` を遅延的に追加し、`/ParentTree` のページごとの配列を拡張する v2.11 のパスです）。`EndTaggedContent` には、現在のページに "EMC" を出力する処理が含まれます。ネストは、ページコンテンツストリームの線形順序によって、`BDC/EMC` のペアが暗黙的にネストされるため実現されます。

PDF/UA-1 準拠のドキュメントにおいて、表示されているすべての段落、見出し、テキスト範囲、または図のキャプションに、描画呼び出しの上下2行にセマンティック構造を付与できるようになりました。veraPDF は、生成されたページコンテンツとマークアップコンテンツのシーケンス、および StructTree リンクを受け入れます。支援技術は、ドキュメントのアウトラインに従ってマークアップコンテンツにアクセスし、役割とテキストを読み上げます。

候補 #1 のステータス：最終版。PDF/UA-1 のプロデューサー側の機能は、ラッパーのオプション設定 (v2.87) + /Alt / /ActualText 属性 (v2.88) + 注釈の /StructParent + OBJR の逆方向接続 (v2.89) + ページコンテンツの BDC/EMC の自動折り返し (v2.90) をカバーします。呼び出し元は依然として構造ツリーのトポロジーに関する決定 (見出し階層、リストのネスト、テーブルヘッダー) を行いますが、その機械的な接続は完全に自動化されています。候補 #1 の開発は終了します。

2026-05-19 Version 2.89.0

PDF 1.7 §14.7.4.4に従って、注釈と構造の関連付けを追加しました。新しい`THotPDF.RegisterAnnotForStructure(AnnotDict, StructElem)`ヘルパー関数は、新しい/ParentTreeキーを割り当て、注釈に/StructParentを登録し、StructElemに/ParentTree[Key]（注釈用の単一参照形式で、ページMCIDエントリで使用される参照の配列形式とは異なります）にStructElemを格納し、StructElemの/K配列に<</Type /OBJR /Obj <annotRef>>>を追加します。これにより、スクリーンリーダーは、タグ付けされた注釈から、親構造要素まで、またはその逆方向にナビゲートできるようになりました。

`THPDFPage.AddURILink(Rect, URL): THPDFDictionaryObject` が追加されました。これにより、PDF/UA-1 を利用するユーザーは、URI アノテーションのエントリポイントを値の戻り値とともに利用できるようになりました。既存の AddGoToLink / AddGoToRLink / AddLaunchLink メソッドは、アノテーション辞書を返しません (これは以前の API の制限によるものです)。新しい AddURILink メソッドは、間接アノテーション辞書を返すため、RegisterAnnotForStructure に直接渡すことができます。

ユーザーに可視化される変更点：PDF/UA-1 に準拠したドキュメントにおいて、ハイパーリンクにセマンティック構造を付与できるようになりました。具体的には、以下のコードで実現します：`LinkAnnot := Doc.CurrentPage.AddURILink(R, 'https://example.org/'); LinkElem := Doc.AddStructureElement('Link', RootElem, -1, -1); Doc.RegisterAnnotForStructure(LinkAnnot, LinkElem);`。これにより、ドキュメントの概要に従って操作する支援技術が、リンクにアクセスし、その目的を通知し、操作可能なオブジェクトとして表示できるようになります。

実装に関する注意点：v2.11版におけるEmitTaggedPDFRootループ，该循环用于生成/ParentTree和/Nums条目，使用了强制类型转换`THPDFArrayObject(FParentTree.Items[I])`。在v2.89版本中，该类型转换被扩展为THPDFObject，因为批注条目存储的是单个字典，而不是数组。由于THPDFArrayObject.AddObject已经通过运行时IsIndirect检查进行分派，因此该类型转换始终是形式上的。v2.11+版本确认，即使存储在FParentTree中的数组，其字节结构仍然保持稳定。

PDF 1.7 第 14.7.4 节允许 `/ParentTree` 值为数组（用于通过 MCID 索引的标记内容序列）或直接的 `StructElem` 引用（用于注释、标记和其他非 MCID 结构元素）。v2.89 是第一个使用单引用形式的版本；数组形式仍然可以通过 v2.11 的 `AddStructureElement-with-MCID` 路径正常工作。

候補 #1 の状態：PDF/UA のプロデューサー側の機能拡張の 3 つ目の段階。まだ 1 つの段階が残っています。それは、ページコンテンツの BDC/EMC の自動折り返しであり、これにより `AddTextField` と `CurrentPage.TextOut` を使用して、手動のオペレーター呼び出しなしでマークされたコンテンツシーケンスを生成できます。その後、PDF/UA のプロデューサー機能が満足のいくレベルに到達します。

2026-05-19 Version 2.88.0

`AddStructureElement`メソッドに、オプションの`/Alt`および`/ActualText`属性文字列を受け取るオーバーロードを追加しました。PDF/UA-1 (ISO 14289-1)では、テキスト以外のコンテンツ（図、数式、装飾的なグリフ）について、スクリーンリーダーで読みやすい代替テキストを提供する必要があります。この新しいオーバーロードにより、これらの代替テキストをStructElemに、1回の呼び出しで簡単に紐付けることができます。

`/Alt`（替代描述）是辅助技术朗读的非文本内容的描述，通常用于图像或图表的结构元素。`/ActualText`是复制粘贴时返回的内容，当可见的字形与预期的Unicode字符不同时使用，例如装饰性连字、首字母缩写或难以提取的书法。

両方の属性は、標準のバイトセーフな `SaveStringObject` エスケープパスを通じて出力されるPDFテキスト文字列です。空の文字列の場合、対応するエントリはスキップされ、既存の4引数呼び出しはバイト単位で同じ出力を維持します。元の4引数の `AddStructureElement(Role, Parent, PageIndex, MCID)` のシグネチャは、Pascal の `overload` ディレクティブによって維持されます。

目に見える変更点：PDF/UA-1準拠のドキュメントにおいて、`AddStructureElement('Figure', Root, 0, 0, 'Company logo', '')`を使用してロゴ図形に、`AddStructureElement('Span', Root, 0, 1, '', 'A bus stop')`を使用してリガチャ範囲に構造要素を追加できるようになりました。veraPDFおよび支援技術は、追加の設定なしに、結果として生成される/Altおよび/ActualTextエントリを処理できます。

パイプラインの配置：v2.88の機能は、v2.11の基本実装に引き継がれます（つまり、StructTreeRootの設定、/K配列への追加、/Pgのバックリンク、およびMCID/ParentTreeの登録は変更されません）。変更点は、その後に2つの属性エントリを追加するだけです。既存の呼び出し箇所は変更されず、v2.74からv2.87までのバイト単位の安定性が維持されます。

候補 #1 の状態：これは PDF/UA プロデューサー側の機能拡張の第二段階です。追跡事項：ページコンテンツの BDC/EMC 自動折り返し（これにより、`AddTextField` と `CurrentPage.TextOut` を使用して、手動のオペレーター呼び出しなしでマークされたコンテンツシーケンスを生成できます）。また、注釈の `/StructParents` の設定（これにより、スクリーンリーダーのナビゲーションで、リンクやフォームウィジェットにもアクセスできるようになります）。

2026-05-19 Version 2.87.0

PDF/UA-1 (ISO 14289-1) の高レベルなオプション機能を、新しい `PDFUACompliance` プロパティを通じて追加しました。 `BeginDoc` / `EndDoc` の前に True に設定すると、HotPDF が満たすことができるすべての PDF/UA-1 のプロデューサ側の要件が自動的に有効になります。これには、`/MarkInfo /Marked = true`、`/StructTreeRoot` のプレースホルダー、`/Lang` (空の場合はデフォルトで 'en')、`/ViewerPreferences /DisplayDocTitle = true`、`/Metadata` の XMP ストリーム、および AIIM に登録された `pdfuaid:part = 1` の識別子が含まれます。

以前，要实现PDF/UA-1兼容性，调用者需要分别设置EnableTaggedPDF、EnableXMPMetadata、Lang、ViewerPreferences（具体为vpDisplayDocTitle）和Title，并创建自定义的XMP数据包来添加pdfuaid命名空间。v2.87将所有这些操作简化为PDFUACompliance:=True；虽然单个标志仍然可用，但如果调用者明确设置它们，则这些标志仍然有效。

XMP パケットの更新：`BuildXMPPacket` が `xmlns:pdfuaid="http://www.aiim.org/pdfua/ns/id/"` と `1` を、`PDFUACompliance` が True の場合に常に生成します。veraPDF やその他の PDF/UA-1 検証ツールは、この正確な名前空間と識別子の組み合わせによって、ドキュメントを PDF/UA-1 の候補として検出します。

ユーザーに可視化される変更点：`Doc.Title := '...'; Doc.PDFUACompliance := True; Doc.BeginDoc; ...; Doc.EndDoc;`というコードで作成されたPDFは、追加の設定なしに、veraPDFでPDF/UA-1の候補として検証されます。ただし、ドキュメントの作成者は、`AddStructureElement`とマークされたコンテンツのシーケンスを使用して、実際の構造ツリーを作成する必要があります。これにより、政府、教育機関、およびアクセシビリティ関連の出版ワークフローにおいて、設定を切り替える操作が1つで済みます。

呼び出し元の責任：PDF/UA-1では、構造ツリーの整合性も必要です（すべてのグリフがタグ付けされた構造要素に属していること）。また、図や数式の内容には、/Altまたは/ActualTextを指定する必要があります。さらに、適切なタブ順、有効な見出し階層なども必要です。このオプションには、機械による検証ツールが最初に確認するカタログ/メタデータラッパーが含まれます。完全な意味的準拠は、呼び出し元がAddStructureElementおよびマークされたコンテンツのBDC/EMC演算子を使用して、構造ツリーを正しく構築することに依存します。

互換性：PDFUACompliance 默认为 False，因此 v2.74 到 v2.86 版本的调用者仍然可以获得字节完全相同的输出。现有的 EnableTaggedPDF / EnableXMPMetadata 标志在新的可选功能设置为 False 时，仍然可以独立工作。

これは、マトリックス候補 #1 の最初の部分であり、タグ付きPDF/PDF/UAのプロデューサー側の機能強化です。今後の改善（v2.88以降）：AddStructureElementでの/Altおよび/ActualTextのサポート、AddTextFieldとCurrentPage.TextOutで使用されるページコンテンツのBDC/EMCヘルパー、およびアノテーションの/StructParentsの対応。

2026-05-19 Version 2.86.0

`RegisterUnicodeTTF`のcmapパーサーを拡張し、OpenType形式12（セグメント化されたフルUnicodeサポート）に対応しました。v2.75からv2.85では、形式4（レガシーBMPセグメントマッピング）のみが解析されていましたが、形式12も含む最新のフォントでは、より詳細なテーブルが使用されるようになりました。サブテーブルの選択では、形式12が形式4よりも優先されます。これは、形式12がフルコードポイント範囲に対してより信頼性の高い情報を提供するためです。

新しい `_TTFParseCmapFormat12` パーサーが追加されました。これは、16バイトのヘッダー（フォーマット/予約/長さ/言語/グループ数）を読み取り、その後、numGroups で指定された12バイトのグループ（開始文字コード/終了文字コード/開始グリフID）を反復処理します。各文字コード C が [startCharCode..endCharCode] の範囲内にある場合、グリフID は startGlyphID + (C - startCharCode) で計算されます。マルチバイト読み込みのたびに範囲チェックを行い、不正なグループはエラーメッセージなしでスキップされます。

サブテーブルのスコアリングが更新されました：

プラットフォーム 3 (Microsoft) + エンコーディング 10 (Unicode full) + フォーマット 12: 120 (最高)

プラットフォーム 0 (Unicode) + エンコーディング 4 または 6 + フォーマット 12: 110

その他のフォーマット 12: 105

プラットフォーム 3 + エンコーディング 1 (Unicode BMP) + フォーマット 4: 100 (レガシー BMP フォールバック)

プラットフォーム 0 + エンコーディング 3..4 + フォーマット 4: 80

プラットフォーム 3 + エンコーディング 10 + フォーマット 4: 70

その他のフォーマット 4: 50

SMPの範囲：CpToGid出力配列は、BMPサイズ（$10000のエントリ × 2バイト = 128 KB）のままです。これは、当社のIdentity-Hエンコーディングが2バイトのCID（0～65535）を使用しているためです。形式12のSMPエントリ（U+10000以上）は解析されますが、保存されません。形式12のウォーカーは、反復処理の前にendCharCodeを$FFFFに制限します。/CIDToGIDMapでSMPを完全にサポートするには、別のエンコーディング（サロゲートペアCMapまたはAdobe-Japan1を使用するIdentity-V）が必要ですが、これは今回の範囲外です。

目に見える改善：フォントファイルで、形式12のみが使用されている場合（一部の最新のCJKフォント、Segoe UI Emoji/Symbolなど）、/W、/CIDToGIDMap、/FontFile2が正しく設定され、v2.84のサブセッターも機能します。v2.86以前のバージョンでは、これらのフォントはcmap解析のデフォルト処理に該当し、4つのストリームの出力がスキップされ、v2.74のメトリック情報のみが残されていました。

フォントのバイト安定性：形式4のフォント（Arial、Tahoma）は引き続き同じコードパスを使用し、同じCpToGid出力を生成します。形式4と形式12の両方を持つフォントは、BMPに対して形式12を使用します。通常、これにより同じBMPマッピングが生成されます（形式12は形式4の厳密な上位互換）。既存のv2.74からv2.85までのバージョンでテストされたこれらのフォントは、引き続きバイト安定性を維持しています。

これは、v2.4.0からv2.86.0までの、高密度PDF仕様への準拠フェーズを完了します。残りのv2.86以降の作業（サロゲートペアCMapsを使用したSMPエンコーディング、フォント固有のGSUBスタイル代替、より高度なタイポグラフィ）は、「基本的なType 0 / Identity-H + AcroForm Unicode」の範囲外であり、実際のユーザーからの要望があるまで、当面延期されます。

2026-05-19 Version 2.85.0

新しい `AutoShapeArabic` プロパティを通じて、オプトイン方式でアラビア語のプレゼンテーションフォームBのコンテキスト整形を追加しました。このプロパティが True の場合、3つの `BuildUnicode*FieldContent` ヘルパー関数は、バイディ反転の前に、基本的なアラビア文字 (U+0621..U+064A) を、位置に応じたプレゼンテーションフォーム (U+FE70..U+FEFF) に置き換えます。これにより、PDFリーダーは、レンダリング時に正しい位置情報を選択するために、プロセス内でテキストシェーパ (HarfBuzz / FreeType / GSUB バイナリルックアップ) を使用する必要がなくなりました。

整形アルゴリズム：論理順序のUTF-16バッファをスキャンし、各アラビア文字について、直前の非透明文字（NSM：非透明文字、およびハラカートU+064B..U+065F、およびアレフ・ハーンジャレイヤU+0670の透明文字）を検索します。結合クラスのコンテキストから位置を決定します。D（デュアル結合：BEH、TEH、SEEN、LAM、MEEM、NOONなど）は、周囲の強力な文字がそれぞれの側への結合を許可するかどうかによって、分離/初期/中間/最終のいずれかをサポートします。R（右結合：ALEF、DAL、ZAL、REH、ZAIN、WAWなど）は、分離/最終のみをサポートします。

ユーザーへの影響（AutoShapeArabic=Trueの場合）：入力「بسم」（バ、シーン、ミーム）は、Tjコマンドで、プレゼンテーション形式のFE91（バのイニシャル）、FEB4（シーンの中間形）、FEE2（ミームの終形）を出力します。右から左への反転後、TjオペランドはFEE2 FEB4 FE91となり、これにより、PDFリーダーは組み込みのシェイパーがなくても、アラビア文字を連結して表示します。

対応範囲：35種類の基本的なアラビア文字（ハムザのバリエーション、アレフのバリエーション、28文字のアラビア文字、イェ・マクスーラ）。静的なUnicode標準ルックアップにより、フォント固有のGSUBバイナリ解析が不要になり、U+FE70..U+FEFFの範囲にグリフを持つフォントであれば、どのフォントでも整形処理が可能です（例：Arial、Tahoma、Segoe UI Arabic、Noto Sans Arabic、Amiriなど）。

このバージョンでは、ペルシャ語/ウルドゥー語の拡張文字（U+0671..U+06D3）、LAM-ALEFの合字（FEFB / FEFC）、モンゴル語/シリア語（異なる字形モデル）、および4つの位置に基づく基本的なモデルを超えるフォント固有のGSUBスタイル代替はサポートされていません。

Byte安定性：AutoShapeArabic 默认值为 False，因此所有 v2.74-v2.84 的调用者都能保持与之前完全相同的 /AP 输出。已经在使用上游预整形（或使用客户端整形器）的调用者不受影响。

パイプラインの配置：各`Build*UnicodeFieldContent`ヘルパーで、UTF-8デコードの後、バイディリバージョン処理の前にシェイプ処理を行います。これにより、AutoDetectFormBidi / FormUnicodeRTLが有効になっている場合でも、整形された表示形式が正しく右から左に反転されます。

残りのUAX #9相关工作：SMP cmap格式12（RegisterUnicodeTTF中对U+10000以上代码点的支持）仍有待完成。

2026-05-18 Version 2.84.0

ファイルベースのTrueTypeフォントサブセッターを追加しました。これは、EndDoc時に動作します。RegisterUnicodeTTFとAddTextFieldの後に、ドキュメントはBuildUnicode*FieldContentの生成中に、各コードポイントの使用状況セットを累積します。EndDocでは、使用されたコードポイントをグリフIDに変換し、複合グリフの関連部分を走査し、使用されたグリフのみを含む埋め込みフォントプログラムを再構築します。v2.82のraw埋め込みを置き換えましたが、残りのテーブル構造は有効なままであるため、サブセッターはグリフIDを変更しません（glyf/locaの圧縮のみが行われます）。

ユーザーへの影響：埋め込み Unicode TTF フォントを含む PDF ファイルが大幅に縮小されます。Arial フォントを埋め込みした「Hello World」ドキュメントは、v2.82 では約 350 KB でしたが、v2.84 では約 10 ～ 15 KB に縮小されます。通常、1000 ～ 3000 のグリフを含む CJK フォントは、圧縮後、約 14 MB から約 500 KB ～ 2 MB に縮小されます。

サブセッターアルゴリズム：グリフIDを変更しないようにし、cmap、hmtx、/CIDToGIDMap、/W が有効な状態を維持します。各グリフインデックス 0..numGlyphs-1 に対して、新しい glyf テーブルは、元のバイトをコピーするか（使用されている場合）、空のエントリを生成します（使用されていない場合）。loca の形式（head.indexToLocFormat に基づく short / long）は維持されます。仕様に厳密な TTF 検証のために、テーブルごとのチェックサムと head.checksumAdjustment が再計算されます。

複合字形処理の改善：当機能は、使用された字形が`numContours`の値が-1（複合字形）の場合に、その構成要素リストを走査します（各構成要素のフラグ、`glyphIndex`、および可変引数/変換スキップを解析）。この際、使用された構成要素をマークし、新しい字形が追加されなくなるまで繰り返します。また、範囲チェックを行うことで、不正な複合字形チェーンによる無限ループを防止します。

仕様への準拠：Type 0 字典中的 /BaseFont、CIDFontType2 派生字体以及 FontDescriptor 中的 /FontName，都将获得一个由用于字形的集合的确定性 FNV-1a 哈希值派生的 6 字母 AAAAAA+ 子集前缀。根据规范 9.6.4，该前缀表示字体程序已被子集化；如果没有该前缀，严格遵守规范的阅读器会警告用户有关嵌入式字体的修改。

使用情况跟踪基础设施：一个包含 65536 个条目的 FUnicodeUsedCps[] 布尔数组，在首次调用 RegisterUnicodeTTF 时才按需分配。三个 BuildUnicode*FieldContent 辅助函数（单行、多行、组合）在生成 UTF-16BE 十六进制 Tj 操作数时，会标记代码单元。SetFormUnicodeFontDict('', nil) 以及将来的 BeginDoc 重置操作会清除状态。

エラー発生時の安全対策：サブセッターの処理中に問題が発生した場合（テーブルの欠損、不正なlocaデータ、複合クロージャの失敗、圧縮の失敗など）、v2.82の元の埋め込みデータはそのまま保持されます。PDFファイル自体は有効な状態を保ちますが、ファイルサイズが大きくなる可能性があります。これにより、v2.82の信頼性を維持しつつ、正常な場合にサブセットの利点を提供できます。

このバージョンに含まれていないもの：OpenType GSUBによるアラビア文字/シリア文字/デヴァナガリー文字の文脈依存結合; SMP cmap形式12（依然としてBMPのみ）。これらはv2.85以降で対応予定。

2026-05-18 Version 2.83.0

RegisterUnicodeTTF に、PDF 1.7 および ISO 32000-1 9.10.3 の /ToUnicode CMap を追加しました。Type 0 フォント辞書には、Adobe-Identity-UCS CMap ストリームへの間接参照である /ToUnicode が含まれるようになり、これにより、PDF リーダーは PDF から Unicode テキストを抽出できるようになりました。/ToUnicode がない場合、v2.74～v2.82 の PDF からコピー＆ペーストすると、Unicode コードポイントではなく CID インデックスが生成され、スクリーンリーダーはコンテンツを読み上げることができず、PDF/A への準拠もできませんでした。

CMap構造：最小限のAdobe-Identity-UCS CMapで、/CIDSystemInfoは(Adobe / UCS / 0)、/CMapNameは/Adobe-Identity-UCS、/CMapTypeは2、単一のcodespacerangeが<0000>から<FFFF>をカバーし、単一のbfrangeが<0000>から<FFFF>を<0000>（identity）にマッピングします。PostScript CMapテキストはFlateDecodeで約150バイトに圧縮されるため、埋め込みによるオーバーヘッドはごくわずかです。

Identityマッピングの理由：私たちのv2.74からv2.82までの設定は、Identity-H + Adobe-Identity-0 + CID = Unicodeコードポイントであり、そのため、ToUnicodeのリバースマッピングはBMP全体で完全に同一です。単一のbfrangeエントリでこの全体のマッピングを表現でき、各コードポイントごとのbfcharリストは不要です。

ユーザーに可視化される変更点：PDFリーダー（Adobe、Foxit、Chrome PDFビューア）でのテキスト選択/コピー＆ペースト操作から、CIDによる不要な変換ではなく、元のUnicodeコードポイントが出力されるようになりました。スクリーンリーダー（NVDA、JAWS、VoiceOver）は、アクセシビリティのために、AcroFormのテキストコンテンツを読み上げることができます。PDF/A-1/2/3への準拠が可能になりました（PDF/Aでは、すべてのType 0フォントに/ToUnicodeが必要です）。

パイプラインの配置：`/ToUnicode` の生成は、`WArrayValid` の try/except ブロックの外部で行われます。これは、アイデンティティマッピングが cmap の解析の成功に依存しないためです。たとえ `/W`、`/CIDToGIDMap`、`/FontFile2` が破損したフォントテーブルのためにスキップされたとしても、`ToUnicode` CMap は依然として生成され、意味的に正しい状態になります。

ストリームオブジェクト：間接的なTHPDFStreamObjectで、/Filterは/FlateDecodeです（ToUnicodeはフォントプログラムではなくテキストストリームであるため、/Length1はありません）。これは、Result.AddValue('ToUnicode', ...)を介して、Type 0のラッパー辞書に添付されます。v2.77の/CIDToGIDMapとv2.82の/FontFile2で共有されるzlib圧縮パターンを使用します。

このバージョンには、以下が含まれていません：每个码位对应的bfchar条目（这将允许将非Identity的CID映射到多字符的Unicode序列，例如fi -> f+i，但我们的Identity设置不需要这样做）；BMP范围之外的SMP覆盖范围（仍然是0x0000..0xFFFF范围）。这些都将推迟到v2.84+版本。

2026-05-18 Version 2.82.0

RegisterUnicodeTTF に、PDF 1.7 および ISO 32000-1 のセクション 9.6.4 と 9.9 に準拠した、/FontFile2 を使用したフォントの埋め込み機能を追加しました。フォントの実際のプログラム（バイナリの TTF/OTF データ）が、フォント記述子に添付された /FontFile2 ストリームとして PDF 内に格納されるようになりました。これにより、フォントを読み込む際に、OS やアプリケーションのフォントキャッシュを使用して /BaseFont 名を解決する必要がなくなりました。その結果、指定されたフォントが存在しないシステムでも、正しくレンダリングされる自己完結型の PDF ファイルが作成されます。

ストリーム構造：間接的な `THPDFStreamObject` で、`/Filter` が `/FlateDecode`、`/Length1` が圧縮されていないフォントファイルのサイズ（仕様の表124を参照）です。圧縮には、v2.77の`/CIDToGIDMap`パターンに従う`TZCompressionStream`（`zcDefault`、`windowBits` 15）が使用されます。通常、ラテン文字のTTFフォントは30〜50%圧縮されます（例：700 KBのArialフォントが350 KBに圧縮されます）。

パイプライン統合：エミッションは、v2.75の/W配列とv2.77の/CIDToGIDMapと同じWArrayValidブランチで発生します。したがって、cmap解析が失敗した場合（破損したサブテーブルまたはサポートされていない形式）、3つの機能ストリームがすべてスキップされ、v2.74のメトリックのみの結果にスムーズに移行します。

目に見える影響：v2.74からv2.81までのPDFファイルは、技術的にはType 0 / CIDFontType2の複合フォントでしたが、フォントプログラムが欠落していました。既存のリーダーは、/BaseFont（PostScript名）を自身のフォントキャッシュと照合する必要がありました。正確な名前を持つフォントがインストールされているシステムでは、レンダリングが機能しましたが、そうでないシステムでは、リーダーが別のフォントを置換して表示していました（これにより、誤ったグリフやメトリックが表示される）、またはプレースホルダーボックスを表示していました。v2.82では、フォントプログラムをPDF自体に含めています。これは、プロデューサーがRegisterUnicodeTTFで解析したのと同じフォントプログラムです。これにより、OSのフォントの有無にかかわらず、すべてのリーダーで一貫したレンダリングが可能になります。

トレードオフ：埋め込みフォントを使用すると、一般的なラテン文字フォントの場合、PDFファイルのサイズが約150〜500KB増加します（圧縮サイズ）。CJKフォントの場合、2〜20MBの増加があります。これは、クライアント側でのフォント置換によるサイズ増加を回避できるものの、非決定的なレンダリングというコストが発生します。サブセット化（v2.83以降で実装予定）により、未使用のグリフを埋め込みプログラムから削除することで、このサイズ増加を軽減できます。

仕様に関する注意点：我们的 v2.82 版本中，/BaseFont 仍然保持原始的 PostScript 名称（没有 "AAAAAA+" 的子集前缀），因为我们嵌入了完整的字体。根据规范 9.6.4，只有当字体程序被子集化时，才适用 6 个字符的前缀；v2.83+ 版本将添加该前缀，作为子集功能的集成部分。

このバージョンには以下の機能が含まれていません：フォントのサブセット化（そのため、埋め込まれたフォントはPDFファイル全体のサイズに影響します）。ToUnicode CMap（PDF/Aのコピー＆ペースト用）。SMP cmap形式12（U+10000以上のコードポイントはまだマッピングされていません）。これらはすべてv2.83以降で対応予定です。

2026-05-18 Version 2.81.0

LTR段落重排路径中，镜像了UAX #9 W4（数字之间的分隔符）和W5（紧邻数字的终止符）。此前仅支持RTL（自v2.72.0 / v2.73.0起）；v2.81将这两个处理过程提取到共享的`_ApplyUAX9W4Rules`和`_ApplyUAX9W5Rules`辅助函数中，以便两个段落方向都应用相同的弱规则转换。

リファクタリング：RTLパスのStep 1b（W4）とStep 1c（W5）のインラインコードを、単一行のヘルパー関数に置き換えました。これらのヘルパー関数は、ワイド文字列とClasses[]配列を受け取り、Classes[]配列を直接変更します。このロジックは、v2.72/v2.73のインライン実装と同じであるため、リファクタリングによってRTL出力のバイト単位の安定性が維持されます。

LTRパスに、W1のNSM継承（ステップ1b）とW7のEN-preceded-by-L（ステップ1d）の間に、ステップ1c（W4）とステップ1c.2（W5）が追加されました。その後のNルール（ステップ1e）とIルール（ステップ1f）は、パイプラインの順序を明確にするために、番号が振り直されました。

表示される左から右へのテキストの影響：混合左から右への環境下で、右から左への強調文字が数字またはET（エンティティ）の後に続く場合、W5はN1がそれを右側の文字グループにまとめる前に、ETをEN（左から右の文字）に変換します。例：「Hi shin $1」（左から右の段落，其中包含希伯来字母“shin”，然后是“$1”），以前会输出“Hi $ shin 1”，其中“$”被包含在右侧的文字组中，并与“shin”互换。v2.81会输出“Hi shin $1”，其中“$”保持在数字的旁边。同样，W4也适用：对于“Hi shin $1,2 widgets”，可以保留“$1,2”作为一个逻辑单元，而不会在逗号处分割。

LTRパスにおけるバイト安定性のシナリオ：先行するRがない純粋なLTR入力（例：「12,345 widgets」）は、W7 sor=LがすべてのENをLに吸収するため、目に見える変化はありません。数字やETを含まないLとRTLのみを含むLTR入力も影響を受けません。既存のv2.79 LTRのテスト（smoke_bidi_n_rules_ltr、smoke_bidi_ltr_reorder）は、バイト単位で同じ結果を維持しています。

パイプラインの順序（RTLパスは変更なし）：W1 -> W4 -> W5 -> W7 -> N0 -> N1 -> N2 -> I2 -> L2。LTRパスは現在：W1 -> W4 -> W5 -> W7 -> N0 -> N1 -> N2 -> Iルール -> L2。両方のパスで、W4/W5/W7/Nの共通ヘルパーを使用します。RTLとLTRの違いは、分類（ステップ1a）と最終的なL2処理のみです。

残りのUAX #9関連作業：OpenType GSUBにおけるアラビア文字/シリア文字/デヴァナガリー文字のコンテキスト依存結合、およびRegisterUnicodeTTFの追跡作業（ToUnicode CMap、SMP cmap形式12、/FontFile2およびサブセット化）は、まだ完了していません。

2026-05-18 Version 2.80.0

Unicode UAX #9 W7 欧文数字转换：当扫描回溯时，如果找到一个明显的 L（或者当扫描到达段落缓冲区的开头时，sor=L），则将其转换为 L。此转换在 W4（数字之间的分隔符）和 W5（紧邻数字的终止符）之后，在 RTL 和 LTR 段落路径上都执行。因此，任何由 W4 提升为 EN 的分隔符也适用于 L-转换。

v2.80 W7では、例えば「Hello 123 Arabic」という文字列が右から左（RTL）の段落に含まれる場合、以前は「Arabic SP 123 SP Hello」という表示順序になることがありました。これは、英語（EN）のテキストが左（L）の「Hello」と右から左（AL）の「Arabic」の間に位置し、NルールがLTR（左から右）のフレーズを2つの独立したテキストブロックに分割したためです。v2.80 W7では、英語（EN）のテキストを左（L）のテキストに変換し、さらに、N1ルールが「Hello」と「123」の間の先頭のスペースを左（L）のテキストブロックに吸収します。これにより、「Hello 123」全体が1つのレベル2のサブ文字列として、まとめて反転されます。最終的な表示順序は「Arabic SP Hello SP 123」となり、これは厳密なUAX #9の動作と一致します。

W7 不会在以下情况下触发：当 EN 前面的最接近的字符是 R 或 AL（阿拉伯字母出现在数字前面）；当 EN 位于 RTL 段落的缓冲区开头（sor=R）；或者在 EN 前面没有 L 字符。在这些情况下，行为与 v2.80 之前的版本相同——v2.72/v2.73 中 W4/W5 基线烟雾仍然保持字节稳定。

LTR 段落効果：W7 同样适用于 LTR 模式（为了符合规范），当扫描到达缓冲区开始时，sor=L。在 HotPDF 简化的单嵌入 LTR I 规则下，L 和 EN 都位于级别 0，因此 EN -> L 的转换不会直接更改 Levels[]，但会更改 N1 的吸收模式：现在，L 和一个连接到 L 的 EN 之间的空格满足 N1 的同向条件，并加入到文本块中。对于纯 LTR 输入，如果没有内部 RTL，则此更改是一个稳定的无操作；对于包含尾部 RTL 的 LTR 输入（例如“Hello 123 shalom”），空格相对于 RTL 块的位置会向后移动一个位置。

W6（残余的ES/CS/ET -> ON，严格遵循UAX #9）在HotPDF简化后的Classes[]表中是隐含的：ES、CS、ET、WS和ON都共享类0（bcOther），并且N规则对类0进行统一处理。在我们的模型中，W6的提升到ON操作没有实际效果，因为N1/N2不会区分ON和WS。这部分内容已在代码注释中进行了说明。

パイプラインの順序（右から左へのパス）：W1：NSM継承 -> W4：数字間のES/CS -> W5：数字に隣接するET -> W7：Lの前にEN -> N0：ペアの括弧 -> N1：同じ方向へのNI吸収 -> N2：デフォルトの埋め込み -> I2：レベルの割り当て -> L2：逆の逆。左から右へのパスでは、W4/W5を除き、同じ順序です（これらの機能は、この部分では右から左でのみ有効です。左から右へのW4/W5の対応機能は、今後の開発対象です）。

新しい共有ヘルパープロシージャ `_ApplyUAX9W7Rules(Classes, ParaIsRTL)` が追加され、これは Classes[] を直接操作します。スキャン処理では、弱い文字、NSM、EN、AN の位置はスキップされ、L、R、AL の文字のみが強力な文字としてカウントされます。スキャン処理が強力な文字を見つけられない場合、段落の方向 (sor) が暗黙の強力な文字として使用されます。 RTL (右から左) のパスでは ParaIsRTL=True が、LTR (左から右) のパスでは False が渡されます。

残りのUAX #9関連作業：LTRパスのW4/W5への移植（現在はRTLのみ対応）、OpenType GSUBにおけるアラビア文字/シリア文字/デーヴァナーガリー文字のコンテキスト依存結合、およびRegisterUnicodeTTFの追跡作業（ToUnicode CMap、SMP cmap形式12、/FontFile2とサブセット化）がまだ残っています。

2026-05-18 Version 2.79.0

v2.78.0のN0/N1/N2ルールを、LTR段落の並べ替えパスに反映しました。これにより、LTR段落内に埋め込まれた複数単語のRTLフレーズ（例：複数のヘブライ語またはアラビア語の単語がスペースで区切られた英語の文）において、単語が視覚的に反転して表示される問題を修正します。これは、単語間のスペースがレベル0のままになり、RTLフレーズが独立したRの実行単位に分割されることが原因でした。v2.79 N1では、スペースが周囲のRの実行単位に組み込まれ、フレーズ全体がレベル1の文字列として扱われます。これにより、L2の反転処理が単語を論理的な順序で保持します。

LTR段落処理のコードをリファクタリングし、RTL側のレイアウトに合わせました。具体的には、各UTF-16コードユニットを`Classes[]`というバイト配列に分類し、`Classes[]`にW1 NSMの継承を適用します（v2.79以前は`Levels[]`を使用）。その後、`_ApplyUAX9NRules`という共通のヘルパー関数を呼び出し、この関数は`Classes[]`と、埋め込み方向を示すパラメータ（LTRの場合は1、RTLの場合は2）を受け取ります。Iルールでは、`Classes[]`から`Levels[]`を派生させます。これにより、RTLとLTRの両方の処理で、同じNルールの実装を共有できるようになりました。

Helper関数 `_ApplyUAX9NRules(Wide, Classes, EmbedDirCls)` は、埋め込み方向をクラス値 (1 または 2) として受け取り、N0 ペア括弧解決、N1 同じ方向の NI 吸収、N2 デフォルトから埋め込みへの統一的な適用を行います。 RTL (右から左) のパスでは 2 (R) が、LTR (左から右) のパスでは 1 (L) が渡されます。すべての v2.78 の RTL 側の動作は、バイト単位で完全に維持されます。

目に見える影響は、左から右への表示において、「Hi shalom olam World」というテキストが、以前はヘブライ語の単語が逆順で表示されていたのに対し（各単語自体は正しいが、相対的な位置が入れ替わっていた）、バージョン2.79では論理的な単語順が維持されるため、右から左への読者にとって、ヘブライ語のテキストが期待される順序で表示されます。同様の修正は、N0とN1の連携により、括弧で囲まれた複数単語の右から左へのフレーズにも適用されます。

LTRパスにおける処理順序（RTLのミラーリング）：Classes[]に分類 -> W1 NSM継承 -> N0 ペア括弧 -> N1 同じ方向のNI吸収 -> N2 デフォルトの埋め込み -> Iルール（Levels[]を派生）-> L2 レベル1の実行を反転。W4/W5の数字処理はまだLTRパスに移植されていません。数字と区切り文字の組み合わせを含むLTR段落は、Nルールを変更せずに処理されます。

既存の左書き（LTR）テストにおいて、バイト単位での安定性が確認されました。純粋な左書きASCII、左書きパラグラフ内の単語ごとの右書き（RTL）、および右書きと左書きが混在し、右書き単語間のスペースがない場合でも、リファクタリング後、すべての`Levels[]`配列は同一になります（W1 NSMの継承ステップは、`Levels[]`または`Classes[]`のどちらで実行しても、結果が同等です）。バージョン2.67、2.69、および2.71の左書きテストは、引き続きバイト単位で同じ結果を生成します。

未完成的 UAX #9 工作：W6/W7 部分的微小修正，W4/W5 在从左到右（LTR）路径上的数字处理（目前仅支持从右到左（RTL）），OpenType GSUB 阿拉伯语/亚述语/梵文字体上下文连接，以及 RegisterUnicodeTTF 的后续处理（包括 ToUnicode CMap、SMP cmap 格式 12、/FontFile2 以及子集化）仍有待完成。

2026-05-18 Version 2.78.0

RTL段落重排流程中，添加了Unicode UAX #9简化N0配对括号解析、N1中性-相同-强吸收以及N2中性-默认-嵌入规则。这修复了一个可见的bug，即嵌入在RTL段落中的多词LTR短语（例如，希伯来语或阿拉伯语包围着英文文本，中间有空格）会被错误地以单词反序输出，因为LTR短语之间的空格仍然停留在嵌入级别，导致LTR短语被分割成独立的子段。通过N1，空格会被吸收进周围的L段，使整个短语成为一个二级子字符串，L2反向处理可以保持其逻辑顺序。

N0：22種類のBMP括弧ペアがサポートされており、ASCIIの丸括弧/角括弧/波括弧から、数学/印刷用の括弧（天井、床、数学角括弧、数学の白い四角形、白い波括弧）まで、CJKの句読点括弧（角括弧、二重角括弧、角括弧、白い角括弧、黒いレンズ状括弧、亀甲状括弧、白い亀甲状括弧、白い四角形括弧）まで、そして全角形式まで対応しています。BD16は、スタックベースのペア括弧検出機能で、仕様により最大63エントリまで対応します。ペアの解決では、最初に強い方向（L、R、AL、EN、AN。ただし、EN/ANは仕様によりRとしてカウントされます）を内部からスキャンし、内部方向が埋め込み方向と異なる場合は、括弧を開く前のフォールバック処理を行います。

N1吸収：`Classes[]`を使用して、`bcOther`（中立）の最大連続ブロックを検索し、左側と右側の非NSM（非自然順序マーク）の強力なタイプを特定します。また、両側の方向が同じ場合（両方とも左向き、または両方とも右向き。EN/ANを右向きとしてカウント）、そのブロック全体がその方向になります。実際の効果：英語のフレーズ内に埋め込まれたアラビア語/ヘブライ語の段落内のスペース/コンマ/ピリオド/コロンが、以前のように分割されるのではなく、フレーズと一緒にグループ化されます。

N2 デフォルト：残りの `bcOther` 位置（周囲に `strong` タグがない、または左右のマッチングが不一致）は、埋め込み方向を受け取ります。RTL 段落の場合、これは R になります。クラス 2。N2 の後、すべての `Classes[]` エントリは解決されたセット {1..6} に含まれるため、I2 レベルの割り当ては、`bcOther` がデフォルトでレベル 1 になるという依存関係がなくなりました。

目に見える改善点：以前のHotPDFでは、英単語 "abc def" を含む右から左（RTL）の段落が、論理的な入力として ""aleph aleph SP a b c SP d e f SP aleph aleph"" と出力されていました。単語の順序が、単語間のスペースがレベル1（=RTL埋め込み）であるために入れ替わっていました。バージョン2.78では、""aleph aleph SP a b c SP d e f SP aleph aleph"" と出力され、フレーズが正しく表示されます。現在、埋め込みフレーズを囲む括弧が、N0 + L4のミラーリングによって、正しく処理されるようになりました。

パイプラインの順序：W1：NSM継承 -> W2/I2（BIDIテーブルでのEN/ANクラスの割り当て、この処理では行われません）、W4：数字間のES/CS -> W5：数字に隣接するET -> N0：ペアリングされた括弧 -> N1：同じ方向への吸収 -> N2：埋め込みのデフォルト -> I2：レベルの割り当て -> L2：逆の逆。NルールはWルールとIルールの間に配置され、既存のWルールの出力がNルールの入力として使用されます。

既存の、多言語対応のテキストに対して、右から左へのテキスト内に左から右へのフレーズが含まれていない場合に、バイト単位で安定した動作を実現しました。具体的には、純粋な右から左へのテキスト、純粋な左から右へのテキスト（関数は入力をそのまま返します）、右から左へのテキスト内に単語の左から右へのテキスト（内部の中性文字は存在しません）、アラビア文字と書式設定された数字、およびスペースとカンマ（スペースは`bcOther`から右から左への同等なものに移行しますが、同じレベルで出力されるため、L2の逆方向出力は変更されません）。バージョン2.66、2.67、2.68、2.71、2.72、および2.73のベースラインテキストは、引き続きバイト単位で同じ結果を出力します。

残りのUAX #9関連作業：W6/W7の残りの微調整、N規則に基づくLTR段落の左右反転（LTR段落内に埋め込まれた複数単語のRTLフレーズ）、OpenType GSUBにおけるアラビア文字/シリア文字/デヴァナガリー文字の文脈依存結合、およびRegisterUnicodeTTFに関連する作業（ToUnicode CMap、SMP cmap形式12、/FontFile2とサブセット化）がまだ残っています。

2026-05-18 Version 2.77.0

THotPDFのRegisterUnicodeTTFに、PDF 1.7 ISO 32000-1 9.7.4.2の/CIDToGIDMapストリームを追加しました。BMP内の各Unicodeコードポイント（CID）は、埋め込みフォントプログラム内の実際のグリフインデックスにマッピングされます。v2.77以前のHotPDFでは、Type 0 / CIDFontType2 + Identity-Hの設定において、/CIDToGIDMapのエントリが未指定であり、仕様に従ってデフォルトで/Identityが使用されていました。これにより、読み込み側はフォントのグリフテーブルをCIDで直接インデックス化するため、ほとんどの文字で誤ったグリフが選択されていました。これは、実際のフォントのグリフテーブルでは、グリフインデックスNがUnicodeコードポイントNと一致するケースが稀であるためです。

実装では、v2.75の/W配列で既に実行されたcmap解析を再利用しています。メモリ内のCpToGid[0..$FFFF]テーブルは、131072バイトのストリームとしてシリアル化され（CIDごとに2バイト、ビッグエンディアン）、FlateDecodeで圧縮されます。通常、実際のフォントサイズは約80〜95%縮小されます。これは、BMPコードポイントの大部分にグリフが存在せず、0x0000としてシリアル化されるためです。圧縮されたストリームは、CIDFontType2の派生辞書に、間接的な/CIDToGIDMapエントリとして追加されます。

目に見える影響：RegisterUnicodeTTF、SetFormUnicodeFontDict、およびAcroForm Txウィジェットを使用して生成されたPDFにおいて、コンシューマーリーダーで表示されるグリフが、元のフォントがネイティブに表示するグリフと一致するようになりました。v2.77以前のPDFで、/Identityデフォルトを使用している場合、仕様に厳密なリーダーでは、意図したラテン文字、数字、句読記号の代わりに、グリフが正しく表示されませんでした。Unicodeを使用してcmapを解釈するリーダーでは、正しく表示されることがありましたが、それは非標準の動作によるものでした。

パイプラインの配置：`/CIDToGIDMap` の構築は、`/W` を構築する同じ `WArrayValid` ブランチ内で行われるため、両方の要素は同じ cmap の解析処理を共有し、新しいのは 2 回目の圧縮処理のみです。cmap、hmtx、maxp の解析が失敗した場合、サイレントなフォールバックにより、`/W` と `/CIDToGIDMap` の両方がスキップされます。その結果、読み込み側は v2.77 より前の辞書を参照し、デフォルトの cmap 解釈を使用します。

このバージョンに含まれていない機能（v2.78以降で実装予定）：SMP cmap形式12（U+10000以上のコードポイントは、テーブル内で依然としてGID 0にマッピングされる）、/FontFile2ストリームの埋め込み（これにより、読み込み側は独自のフォントマッチングを使用して/BaseFont名を解決する）、フォントサブセット化（128 KBの生データマップはフルレンジ）、およびコピー＆ペースト/アクセシビリティ対応のためのToUnicode CMap。

2026-05-18 Version 2.76.0

HotPDF独自の複数行テキスト折り返しアルゴリズムに、v2.75.0のTTFフォントの幅情報配列を組み込みました。v2.65.0の`BuildUnicodeMultilineFieldContent.CodeUnitAdvance`ヘルパー関数は、`RegisterUnicodeTTF`によって作成された、各コードポイントごとの幅情報キャッシュを参照するようになり、以前の0.5/1.0という狭い/広い文字の区別ルールではなく、実際の字形のメトリックを使用します。プロデューサ側の改行位置は、コンシューマ側の`/W`レンダリングと一致するように調整されました。HotPDFが選択する折り返し位置は、コンシューマ側のリーダーが実際に`/Tj`オペランドを描画する際に折り返す位置と一致します。

新しい非公開フィールド：`FAcroFormUnicodeAdvances`（サイズが65536または空の動的配列）は、PDFデザイン単位（1emあたり1000）で各コードポイントのアドバンス幅をキャッシュします。`FAcroFormUnicodeAdvancesActive`フラグは、「`RegisterUnicodeTTF`によってキャッシュが埋め込まれた」状態と「フォントがロードされていない（ヒューリスティックがフォールバックされる）」状態を区別します。`RegisterUnicodeTTF`は、これらのフィールドを`/W`配列の構築時に同時に行われるhmtx + cmapの走査中に埋め込みます。そのため、追加の解析処理は不要です。

CodeUnitAdvance の検索順序：如果 FAcroFormUnicodeAdvancesActive 处于启用状态，并且缓存中存在非零条目，则将缩放后的宽度除以 1000.0，并将其作为 em 分数返回；否则，按照 v2.65 的启发式方法处理（ASCII/Latin-1 为窄字，CJK/Hangul/Hiragana/Katakana/全角为宽字）。Surrogate 组合对的半字仍然遵循此启发式方法，因为缓存仅支持 BMP 范围。

キャッシュのライフサイクル：`THotPDF.Create`時にクリアされます（デフォルトでは空または非アクティブ）、`SetFormUnicodeFontDict('', nil)`を呼び出し元が明示的に使用してUnicodeフォントの登録をリセットするとクリアされ、その後のすべての`RegisterUnicodeTTF`呼び出しで再初期化されます。128 KBのメモリを保持しますが（64Kのコードポイント * 2バイト）、これは少なくとも1つのTTFがロードされている場合にのみ適用されます。Unicodeフォントを一切使用しないインスタンスでは、メモリ消費はゼロです。

RegisterUnicodeFontDict (バージョン 2.70.0) および RegisterUnicodeTTF (バージョン 2.74.0) が、/W 配列なしで実行される場合（例：maxp、/cmap、/hmtx テーブルが欠落している場合）、キャッシュが空または無効になり、その結果、複数行のテキスト折り返しはバージョン 2.65 のヒューリスティックにフォールバックします。これにより、該当するパスでは、出力がバージョン 2.65 と完全に同じになります。

目に見える改善点：マルチ行のAcroFormテキストフィールドウィジェットにおいて、一般的なラテン文字フォント（Arial、Segoe UI、Timesなど）を使用している場合、テキストが実際の表示に合わせて、文字の境界で折り返されるようになりました。v2.76以前のバージョンでは、v2.65のヒューリスティックによって、すべてのASCII文字が0.5emの幅として扱われていました。しかし、実際のフォントでは、「M」は約0.8em、「i」は約0.3emの幅であるため、このヒューリスティックは30〜60%の誤差を生じさせ、結果として、HotPDFが意図した表示とは異なる折り返しが行われ、テキストのオーバーフローや短い行が発生していました。

`BuildUnicodeTextFieldContent` と `BuildUnicodeCombFieldContent` 関数は、`CodeUnitAdvance` を使用せず、変更の影響を受けません（単一行は折り返しなしで表示され、コンビネーション文字は等幅セルを使用します）。

このバージョンには以下のものが含まれていません: SMP cmap形式12（U+10000以上のコードポイントは、依然としてサロゲートペアのヒューリスティック処理を経由します）、ToUnicode CMap、/FontFile2ストリーム埋め込み、フォントサブセット化。これらの機能はv2.77以降のバージョンに含まれています。

2026-05-18 Version 2.75.0

THotPDFのv2.74.0で、`RegisterUnicodeTTF`にhmtx、maxp、cmapの解析機能を追加しました。これにより、生成されるCIDFontType2フォントは、各コードポイントに対応した実際の幅情報（/W）配列を持ちます。これにより、フォントのメトリクスを使用するリーダーは、テキストの幅を正しく表示できるようになり、以前はすべてのグリフに対してデフォルト値（/DW = 1000）を使用していた問題を解決しました。AcroFormの/AP（appearance stream）内のテキストは、元のフォントでレンダリングされた場合の幅と同じ幅で表示されるようになります。

新しいユニットレベルのヘルパー関数が、3つの追加のSFNTテーブルを解析します。`_TTFParseMaxpNumGlyphs`は、`maxp`から`numGlyphs`を読み取ります。`_TTFParseHmtxAdvances`は、`hhea`から取得した`numberOfHMetrics`に基づいて、各グリフの幅の配列を解析します。`_TTFFindAndParseCmap`と`_TTFParseCmapFormat4`は、UnicodeコードポイントからグリフIDへのルックアップを、BMPセグメントマッピング形式4のサブテーブルを介して行います。`_TTFBuildWArray`は、PDF 1.7 9.7.4.3の形式1の疎な/W配列を構築します。この配列では、連続するデフォルト以外の幅を持つコードポイントを`[startCID [w1 w2 w3 ...]]`のグループにまとめ、幅が`/DW = 1000`のコードポイントはスキップして配列のサイズを削減します。

Cmap サブテーブルの選択では、Microsoft Unicode BMP (プラットフォーム 3、エンコーディング 1、形式 4) が優先されます。これは、Windows での一般的なフォント cmap レイアウトです。クロスプラットフォームの OpenType フォントでは、Unicode プラットフォーム (0、エンコーディング 3 または 4) にフォールバックし、次にプラットフォーム 3 エンコーディング 10 (Unicode フル / 形式 4 のみ)、最後にその他の形式 4 を使用します。このバージョンでは、形式 4 以外のサブテーブル (形式 0、2、6、8、12、13、14) は無視されます。形式 12 を使用した SMP のサポートは、v2.76 以降で利用可能です。

`/W` 数组通过直接引用附加到 CIDFontType2 的子字典：`Type0` -> `/DescendantFonts` -> `[0]` -> 添加值 (`W`, `WArray`)。`v2.70` 中 `RegisterUnicodeFontDict` 的签名未更改；子字典在组装后会被直接修改。

hmtx から取得した FUnit の幅は、head テーブルの unitsPerEm 値を使用して、PDF のデザイン単位 (1 em あたり 1000 単位) に変換されます。マッピングされていないコードポイント (cmap が 0 または .notdef を返す場合) は、DW = 1000 として扱われ、/W から除外されます。一般的なラテン文字フォント (Arial、Segoe UI、Times など) の場合、結果として得られる /W には 500～1500 個のコードポイントが含まれます。CJK フォントの場合、この配列は 10,000 個以上のエントリにまで増加する可能性があります。

このバージョンには含まれていません（v2.76以降で対応予定）：HotPDF独自の複数行テキスト折り返しアルゴリズムは、まだ`/W`の幅データを使用していません。v2.65の`BuildUnicodeMultilineFieldContent`では、行区切りの計算に依然として0.5/1.0の狭い/広い文字のヒューリスティックを使用しており、`/W`配列は主にレンダリングの精度を向上させるためのものです。完全なプロデューサー側の完璧な折り返し（`/W`を使用して折り返し計算を行う）は、v2.76以降で実装されます。また、以下の機能もv2.76以降で実装予定です。ToUnicode CMap（cmapの逆マッピング）、`/FontFile2`ストリームの埋め込み、フォントのサブセット化、およびSMP cmap形式12。

/W解析具有try/except的容错机制。如果maxp、cmap或hmtx信息缺失，或者任何子表格式不正确，RegisterUnicodeTTF将静默地继续，并使用v2.74版本的仅限指标的结果；读取器将为每个码位使用/DW = 1000。不会发生静默的数据损坏：在每次多字节读取时，都会对表进行边界检查。

2026-05-18 Version 2.74.0

THotPDF.RegisterUnicodeTTFが追加されました。これは、v2.70.0のRegisterUnicodeFontDictをファイルベースでラップしたもので、TTF/OTFフォントをロードし、head、hhea、OS/2、post、nameテーブルを解析し、FUnitのメトリックをPDFのデザイン単位（1000/em）に変換し、RegisterUnicodeFontDictに値を渡して、完全なType 0/CIDFontType2 + Identity-Hの複合フォント辞書を構築します。返された辞書は、SetFormUnicodeFontDictで使用する準備ができており、呼び出し側はフォントの正確なメトリック値またはSFNTのバイナリ形式を知る必要はありません。

API: RegisterUnicodeTTF(FontPath, LogicalName=""). FontPathは、.ttfまたは.otfファイルへの絶対パスまたは相対パスです。LogicalNameは、v2.75以降で使用され、同じPostScript名を持つフォントを区別するために使用される場合があります。

テーブルを解析しました: head (unitsPerEm、フォントの境界ボックスのxMin/yMin/xMax/yMaxをFUnitsで指定)、hhea (アセンダー、デセンダーをFUnitsで指定)、OS/2 (usWeightClassを/StemVの推定に使用、sCapHeight、fsSelectionをイタリックビットに使用)、post (italicAngleをFIXED 16.16で指定し、度数に変換、isFixedPitchは/Flagsビット1で指定)、name (PostScript名をnameID 6で指定し、WindowsまたはMacプラットフォームから取得、nameID 4で完全な名前を使用)。各テーブルのオフセット/長さに加えて、マルチバイト読み込みにも境界チェックを行い、不正なフォントがメモリ破壊ではなく、明確な例外として検出されるようにします。

自動生成のメトリクス：`/FontBBox` の L/B/R/T は PDF のデザイン単位にスケーリングされ、`/Ascent` と `/Descent` もスケーリングされます。`/CapHeight` は OS/2 の `sCapHeight` から取得されます（バージョン 2 より前の OS/2 テーブルの場合は、`/Ascent` を使用します）。`/ItalicAngle` は `post.italicAngle` から取得されます。`/StemV` は `50 + (usWeightClass - 400) / 5` で推定され、範囲 [50, 250] に制限されます。`/Flags` は `Symbolic` と `FixedPitch`（PostScript で指定されている場合）と、`fsSelection` のビット 0 が設定されているか、`italicAngle` が 0 でない場合に `Italic` が設定されます。`/BaseFont` は解析された PostScript 名を使用し、名前テーブルから有効な名前を取得できない場合は、デフォルトで `"UnnamedTTF"` を使用します。

エラーが発生した場合、詳細な例外がスローされます。例外の内容は、ファイルが見つからない、サイズが不適切（12バイト未満または64MB超）、認識できないsfntVersion（0x00010000 / 'OTTO' / 'true' / 'typ1'のいずれかである必要があります）、必要なテーブルが見つからない（head / hhea / OS/2 / post / name）、必要なフィールドに対応するテーブルが小さすぎる、などです。

この変更に含まれないもの（v2.75以降に実装予定）：hmtxからの/W（文字幅）配列（numGlyphsの最大値と、Unicodeからグリフへのマッピングのためのcmapが必要です。現在のv2.65の複数行テキスト折り返しは、0.5/1.0のヒューリスティックを使用しています）、cmapからのToUnicode CMap（現在のv2.56以降のIdentity-Hマッピングでは、CIDがUnicodeコードポイントと等しいと仮定しています）、生のフォントデータを/FontFile2ストリームとして埋め込むこと、およびフォントのサブセット化。v2.74.0では、フォントリーダーは依然として、独自のフォント照合メカニズムを使用して、/BaseFontの名前を解決する必要があります。

smoke_unicode_ttf.dpr 加载一个 Windows 系统字体（按顺序查找 %SystemRoot%\Fonts 目录下的 arial.ttf、segoeui.ttf、times.ttf 和 verdana.ttf），并验证 RegisterUnicodeTTF 是否返回一个类型 0 字典，该字典包含文件解析后的度量信息。验证器检查结果中的 /BaseFont 是否不是一个占位符，并且 FontBBox、/Ascent、/Descent 和 /ItalicAngle 是否在真实字体的合理范围内。

2026-05-18 Version 2.73.0

Added Unicode UAX #9 simplified W5 (European Terminator adjacent to European Number) for RTL paragraphs. Fixes the visible bug where Arabic text with currency / percent symbols — "$12.50", "50%", "€100", "شار 12.50$ ريال" — left the currency or percent glyph stranded at the boundary between the digit substring and the surrounding RTL text. With v2.73 W5, ETs adjacent to digits join the digit run and reverse with the digits, preserving the currency-and-number unit as one LTR substring inside the RTL paragraph.

W5 ETs が認識されました（コードポイントセット）：U+0023 # (番号記号)、U+0024 $ (ドル記号)、U+0025 % (パーセント記号)、U+00A2..U+00A5 (¢ £ ¤ ¥)、U+00B0 ° (度記号)、U+00B1 ± (プラスマイナス記号)、U+066A ٪ (アラビア語のパーセント記号)、U+2030..U+2031 (‰ ‱ パーミル / 1万分の1)、U+20A0..U+20CF (通貨記号ブロック、€ ₹ ₽ ₩ などを含む)。EN の両側に隣接する ET の最大シーケンスは、NSM をスキップして EN に変換されます。

HotPDFの拡張機能では、W5が仕様のEN（英語）のみのルールに加えて、AN（アラビア数字）の隣にあるET（エンティティ）をANに変換します。これにより、ASCIIとアラビア数字のコンテキストが対称になり、「٥٠٪」（アラビア数字の50 + アラビア語のパーセント）でパーセントを扱う場合と、「50%」（ASCIIのパーセント）でパーセントを扱う場合で、同じように扱われます。

Concrete fix: "شار $12.50 ريال" (logical UTF-16 0634 0627 0631 0020 0024 0031 0032 002E 0035 0030 0020 0631 064A 0627 0644). v2.72 output: 0644 0627 064A 0631 0020 0031 0032 002E 0035 0030 0024 0020 0631 0627 0634 — the $ glyph stranded at memory position 11, between the digit substring and the trailing space, reading awkwardly. v2.73 output: 0644 0627 064A 0631 0020 0024 0031 0032 002E 0035 0030 0020 0631 0627 0634 — "$12.50" intact as one LTR substring inside the RTL flow.

BIDI_Class 表格修正：U+066A ARABIC PERCENT SIGN 已从 bcAL 移动到 bcOther（以便 W5 ET 进程可以检测并转换它）。阿拉伯语字符块查找现在为数字范围（bcAN）、harakat/shadda 块（bcNSM）、alef khanjareeya（bcNSM）、十进制/千位分隔符（bcAN）以及百分号（bcOther + W5 上的 ET）预留了空间。

パイプラインの順序：W1（NSM継承、LTRパスは明示的、RTLは暗黙的）-> W4（数字間のES/CS）-> W5（数字に隣接するET）-> I2（レベルの割り当て）。W5はW4の後に実行されるため、W4によって変換された区切り文字がENになった場合、W5は次の処理でそれを「数字に隣接するEN」として正しく識別します。複雑な数字-区切り文字-通貨の組み合わせにおける複数のルールの相互作用は、単一のパイプライン処理で解決されます。

純粋なテキスト部分在字节级别上与 v2.72 版本完全相同。现有的 v2.59-v2.72 版本的各项功能（包括 RTL 阿拉伯语/希伯来语、SMP RTL、NSM 定位、LTR 段落重新排序、数字处理以及 W4）均保持字节级别的稳定性。

残りのUAX #9関連作業（W6 / W7の修正、UAX #9 BD16によるスタックスキャンによるN0括弧ペアの処理、N1 / N2のニュートラルな解決、OpenType GSUBにおけるアラビア文字/シリア文字のコンテキスト依存結合、ファイルベースのRegisterUnicodeTTF）は、まだ完了していません。

2026-05-18 Version 2.72.0

Added Unicode UAX #9 simplified W4 (ES / CS between same-typed digits) for RTL paragraphs. Fixes the visible bug where Arabic text with formatted numbers — "السعر 12,345 ريال" (price with thousands comma), "12.50" (decimal point), "12:30" (time colon) — split the digit run at the separator in the reversed /Tj output, producing visually-broken numbers that read backwards within the RTL flow. With v2.72 W4 the separator joins the digit run, both reverse together once and then reverse together again at the whole-string pass, preserving the digit + separator logical order inside the RTL paragraph.

W4区切り文字が認識されます。これには、ヨーロッパの区切り文字（U+002B (+) / U+002D (-))、一般的な区切り文字（U+002C (,) / U+002E (.) / U+002F (/) / U+003A (:) / U+00A0 (NBSP)）、およびアラビア語の一般的な区切り文字（U+060C (アラビア語のカンマ)）が含まれます。これらの文字は、2つのEN（英語）文字の間に挟まれた場合はENに、2つのAN（アラビア語）文字の間に挟まれた場合はANに変換されます。混合型の隣接文字（EN + AN、または数字 + 数字以外の文字）の場合、区切り文字は以前と同様に、bcOther / レベル1 / 周囲がRTLのストリームでは変更されません。簡略化されたUAX #9 W4と完全なUAX #9 W4：NSM（非セグメント間マーカー）を跨いで確認が行われます（区切り文字の近くにあるNSMはW4の検索を妨げません）。ただし、複数の区切り文字が連続する場合、仕様で規定されている「単一」の区切り文字の制限ではなく、位置ごとに変換が行われます（実際の数値では隣接する区切り文字が並ぶことはまれなため、実用的な影響は小さい）。

Concrete fix: "شار 12,345 ريال" (logical UTF-16 starts with Arabic letters, then space, "1" "2" "," "3" "4" "5", then space, then Arabic letters). v2.71 previous output: 0644 0627 064A 0631 0020 0035 0034 0033 002C 0031 0032 0020 0631 0627 0634 — digits split at the comma, reversed within each fragment ("345" before "12"), reads as "345,12" inside the LTR substring user perception. v2.72 fixed output: 0644 0627 064A 0631 0020 0031 0032 002C 0033 0034 0035 0020 0631 0627 0634 — "12,345" intact as one LTR substring, user reads it naturally in numeric order.

BIDI_Classテーブルの修正（v2.72.0）：U+066B ARABIC DECIMAL SEPARATORおよびU+066C ARABIC THOUSANDS SEPARATORは、UnicodeDataの仕様に従い、bcAN（戻り値5）として分類されるようになりました。以前はbcALとして分類されていました。これらの区切り文字は、アラビア数字の書式設定の一部として規定されており、したがって、L2のリオーダーにおいて、アラビア文字の数字のグループに自然に組み込まれます。U+066A ARABIC PERCENT SIGNは、bcAL（プレースホルダー）として分類されます（ヨーロッパの数字の終端処理は、W5に延期されます）。

内部リファクタリング：_ApplyUAX9L2Reversal のレベル割り当てステップにおいて、明示的な Classes[] 並列配列（UTF-16 コードユニットの各位置に 1 バイト）が構築されるようになりました。これにより、W4 パスは、コードポイントを再デコードせずに、隣接するクラスを確認できます。サロゲートペアのコードポイントは、Classes[] と Levels[] の両方のバイトを、上位と下位の半分で共有します。_ApplyUAX9L2ReversalLTRPara の同等のリファクタリングは、後回しにされます（W4 は、簡略化された単一の埋め込みレベルモデルでは、EN / AN がすでに基本レベル 0 にあるため、LTR 段落には目に見える影響はありません）。

純粋な右から左（RTL）/左から右（LTR）/混合文本，在相同类型的数字之间没有W4分隔符的情况下，与v2.66到v2.71的输出完全相同。现有的v2.59-v2.71版本的测试（包括RTL阿拉伯语/希伯来语/SMP RTL/NSM定位/LTR段落重新排序/数字处理/检测器），所有内容都保持了字节级别的稳定性。

まだ残っている作業は、UAX #9に関連する作業（ENに隣接するW5、W6/W7の修正、UAX #9 BD16によるスタックスキャンによるN0の括弧ペア、N1/N2の簡素化された中立的な解決策、OpenType GSUBにおけるアラビア文字/シリア文字のコンテキスト依存結合、ファイルベースのRegisterUnicodeTTF）です。

2026-05-18 Version 2.71.0

アラビア語/ヘブライ語テキストの並べ替えにおける、非間隔文字（NSM）の位置ずれのバグを修正しました。以前は、単純な文字列全体の反転により、結合文字（アラビア語のハラカート、例えばファタハ/カスラ/ダマ/シャドダ；ヘブライ語のニククド、例えばシェバ/カマツ/パタ；U+0300～U+036Fブロックのラテン文字の結合アクセント）が、反転された`/Tj`ストリームにおいて、ベース文字の反対側に移動されていました。その結果、PDFリーダーの結合文字レンダラーは、表示順で前のグリフにNSMを接続し、誤ったベース文字に接続していました。この問題により、例えば「ALEF + FATHA + BA」（アラビア語）というテキストが、ファタハがBAのグリフに表示されるという問題が発生していました。

UAX #9 W1簡化了NSM继承，并且所有三个L2重排算法都共享了一个感知组的逆向处理。现在，逆向处理将[base, NSM*]视为一个单元：当从右向左遍历时，NSM被缓冲到堆栈中，并在输出中的下一个非NSM基本元素之后立即以原始逻辑顺序刷新。代理对代码点在相同的逆向处理过程中保持不变，SMP范围内的NSM（罕见）以对称的方式处理。

この修正により、以前に「ALEF + FATHA + BA」として（論理的なUTF-16表現：0623 064E 0628）出力されていたものが、0628 064E 0623（全体を反転、FATHAがBAとALEFの間にある）として出力されていました。v2.71.0で導入されたNSM（Noto Sans Mongolian）対応の反転処理により、同じ入力に対しては、0628 0623 064Eという正しい順序で出力されるようになりました。これにより、BAが左に、ALEFが中央に、FATHAがALEFの後に配置され、レンダリングエンジンはそれを正しいベース文字に結合できるようになります。

内部のBIDI_Classテーブルが拡張され、主要な結合マークブロックに対してbcNSMクラス（戻り値6）が追加されました。これらのブロックには、以下のものが含まれます。一般的な結合用アクセント記号（U+0300..U+036F、ラテン語/一般的なアクセント）、ヘブライ語のニクド（U+0591..U+05BD）、およびヘブライ語R範囲から切り出された散在するU+05BF / U+05C1..U+05C2 / U+05C4..U+05C5 / U+05C7エントリ、アラビア語のハラカット（U+064B..U+065F）、およびアラビア語AL範囲から切り出されたアレフ・ハーンジャレーヤ（U+0670）。NSM（Non-Spacing Marks）は、段落方向のP2/P3における最初の強力なスキャンでは引き続きスキップされます。

LTR段落中，在初始级别的分配之后，会执行一次显式的W1 NSM级别继承：每个NSM会采用前一个非NSM代码点的级别，因此，位于AL基础之后的阿拉伯语NSM会加入该基础的级别1运行，以进行单次L2反向处理。对于RTL段落，级别是隐式继承的（NSM和R/AL在简化的单嵌入级别模型中都解析为级别1），因此不需要单独的W1处理。

純粋な右から左 (RTL) / 左から右 (LTR) / 混合入力，且不包含非整形空白符 (NSM) 的输出，与 v2.66 / v2.67 / v2.68 / v2.69 / v2.70 的输出完全相同（不包含 NSM 表示没有行为上的变化）。现有的 v2.59 RTL 阿拉伯语 / v2.66 LTR-in-RTL / v2.67 LTR 段落 / v2.68 EN-AN / v2.69 SMP-RTL 测试均保持字节级别的稳定性。

残りのUAX #9相关工作（包括W3-W7详细的弱类型转换、N0-N2中立以及括号对解析、OpenType GSUB阿拉伯语/叙利亚语上下文连接，以及基于文件的RegisterUnicodeTTF）仍在进行中。

2026-05-18 Version 2.70.0

THotPDF.RegisterUnicodeFontDict ヘルパーを追加しました。これにより、PDF 1.7 ISO 32000-1 9.7 / 9.7.6 の Type 0 / CIDFontType2 と Identity-H を組み合わせたフォント辞書を、1回の呼び出しで完全に構築できます。 v2.56.0 の SetFormUnicodeFontDict AcroForm /AP パスを使用するユーザーは、CIDSystemInfo / FontDescriptor / CIDFontType2 / Type 0 / Identity-H のサブ辞書を構築するための約 30 行のコードを手動で記述する必要がなくなりました。この関数は、SetFormUnicodeFontDict に渡すことができる間接的な THPDFDictionaryObject を返します。

API: RegisterUnicodeFontDict(BaseFont, FontBBoxL/B/R/T, Ascent, Descent, CapHeight, ItalicAngle, StemV, Flags, DefaultWidth)。所有计量参数都具有合理的默认值（CJK/阿拉伯语嵌入式字体的几何形状：FontBBox [-1000 -300 2000 1300]，Ascent 1000，Descent -300，CapHeight 750，StemV 100，Flags 4 = Symbolic，DW 1000）。对于拉丁语/希伯来语/西里尔语字体，可以单独覆盖这些参数，使用较小的bbox和非符号Flags = 32。

辞書構造は、仕様に準拠したType 0 + CIDFontType2レイアウトであり、これはv2.59からv2.69までのsmoke_acroform_cid_rtl / smoke_bidi_*で使用されています。具体的には、Adobe / Identity / Supplement 0 CIDSystemInfo、すべての必須項目を含むFontDescriptor、Identity-Hエンコーディング、DescendantFonts配列内のCIDFontType2の子フォント、およびデフォルト文字幅の/DWが含まれます。/CIDToGIDMapは、指定されていない場合、デフォルトで/Identity（CID == GID）に設定され、これはIdentity-H + Adobe-Identity-0の順序が示す通りです。

今後のv2.71以降のバージョンでは、ファイルベースのRegisterUnicodeTTF機能が追加されます。この機能は、.ttf / .otfファイルを解析し、正確な文字間隔（hmtx /W）などの情報を抽出し、フォントを/FontFile2として埋め込みます。また、cmap情報からToUnicode CMapを生成し、構造的な要素についてはRegisterUnicodeFontDictを内部的に呼び出します。

2026-05-18 Version 2.69.0

内部のUnicode BIDI_Class参照テーブルを拡張し、U+10800..U+10FFFの補助多言語面（SMP）右から左への文字ブロックをサポートしました。段落方向の検出とL1-L2の並べ替えにおいて、フェニキア文字、新アラム文字、パルミラ文字、ナバテア文字、ハトラ文字、リディア文字、メロエ文字（ヒエログリフ/草書）、ハラフスター、古代南アラビア文字、古代北アラビア文字、マニ教文字、アヴェスター語、碑文パフラヴィー語/パフラヴィー語、詩篇パフラヴィー語、古代トルコ語、古代ハンガリー語、ハニフィー・ロヒンギャ語（AL、現在ミャンマーで使用されているロヒンギャ語の文字）、ガラ語、イェジディ語、アラビア文字拡張C（AL）、古代ソグド語、ソグド語、古代ウイグル語、ホラズム語、およびエリマイ語を正しく認識するようになりました。

SMP RTL 段落现在通过 `DetectBidiParagraphDirection` 自动检测为 RTL（首次扫描时，会遍历代理对，并匹配适当的 R/AL 类），并执行 v2.66 的 RTL L1-L2 重排序，以实现视觉上的 UTF-16BE `Tj` 输出。包含嵌入式 SMP RTL 子字符串的 LTR 段落，如果启用了 `EnableLTRParaReorder`（v2.67 选项），则会反转这些子字符串；否则，它们会以逻辑顺序输出，并依赖于消费者的阅读器的内置 BIDI 功能。

サロゲートペアの保持は、すべてのL2リバースパスにおいて引き続き有効です。SMP RTLのコードポイントは、周囲の段落が正しく並べ替えられる一方で、元のハイ+ローペアのまま、/Tjの16進ストリーム内に保持されます。

v2.67版における、テスト（smoke_bidi_ltr_reorder）のアサーション#7では、U+10840 IMPERIAL ARAMAIC LETTER ALEPHを使用して、「SMPコードポイントがLTR段落でbcOtherとして扱われる」ことを示していました。このリリースで、そのアサーションは更新され、現在の正しいbcR分類を反映しています。具体的には、LTR段落内のU+10840は、レベル1のR/ALの実行の一部となり、隣接するヘブライ語/アラビア語の文字列に合わせて視覚的な位置に再配置されます。

UAX #9に関連する残りの作業（W1 NSM継承 + W3～W7の弱い型変換 + N0～N2の中立 + 括弧ペアの解決 + I1の明示的なレベル解決 + OpenType GSUBにおけるアラビア文字/シリア文字のコンテキスト依存結合）はまだ完了していません。SMP RTLのサポートが実装されたことで、すべての標準化されたUnicode RTLスクリプトが、段落の方向と基本的なL1～L2の並べ替えについて正しく分類されるようになりました。

2026-05-18 Version 2.68.0

Fixed visible direction bug for digits embedded in Arabic / Hebrew paragraphs. Added Unicode UAX #9 weak-class BIDI_Class entries for European digits (EN, U+0030..U+0039) and Arabic-Indic digit ranges (AN, U+0660..U+0669 + U+06F0..U+06F9), with simplified UAX #9 I2 + L2 level assignment: in an RTL paragraph these digit codepoints now get resolved level 2 (same as embedded LTR runs) rather than level 1 alongside the surrounding RTL text. The two-pass L2 reorder then preserves their logical order inside the visual RTL flow, matching the spec-correct "شارع 12345" user reading even when the paragraph is rendered LTR for the PDF /Tj stream.

Concrete fix: an input "شار 12345" (logical UTF-16 0634 0627 0631 0020 0031 0032 0033 0034 0035) previously emitted as the Tj operand 0035 0034 0033 0032 0031 0020 0631 0627 0634 (whole-string reverse - digits inverted, the visible bug). With the v2.68 fix the same input emits 0031 0032 0033 0034 0035 0020 0631 0627 0634 - digits stay 1-2-3-4-5 in reading order while the Arabic word still renders in visual RTL.

DetectBidiParagraphDirection 现在根据 UAX #9 P2 的规定，将 EN 和 AN 视为弱字符：仅包含数字或以数字开头的段落不再将 RTL 锚定在数字上；第一个强字符（L / R / AL）仍然决定方向。如果输入为空或仅包含弱字符，则仍然默认为 LTR，如 P3 所示。Smoke 测试验证纯数字段落返回 LTR，而数字后跟阿拉伯语的段落返回 RTL（阿拉伯语 AL 是第一个强字符），数字后跟拉丁语的段落返回 LTR（拉丁语 L 是第一个强字符）。

アラビア文字ブロックの範囲 U+0600..U+06FF は、ルックアップテーブル内で分割され、2桁の範囲が bcAN として分離されました。周辺の U+0600..U+065F + U+066A..U+06EF + U+06FA..U+06FF は bcAL のままです。その他のアラビア文字ブロックのコードポイント（句読点、パーセント記号、通貨記号など）は、現時点では bcAL の分類を維持します。より詳細な弱分類の処理（ET / CS / ON / NSM）は、W1-W7 / N0-N2 パイプライン全体の一部として、今後のリリースで実装されます。

純粋な右から左（RTL）入力で、数字を含む行がない場合、出力はv2.66/v2.67と同じバイト数になります（Wクラスの変換はトリガーされません）。左から右（LTR）の段落には影響ありません（数字はすでに段落の基本方向によってLTRで表示されます）。この修正は、AutoDetectFormBidiまたはFormUnicodeRTLを使用し、UseUAX9LevelReversal=True（デフォルト）に設定されている既存のすべての呼び出し元で自動的に適用されます。

まだ、UAX #9 + GSUB の範囲（W1 NSM 継承 + 完全な W3/W4/W5/W6/W7 + N0-N2 ブラケット + I1 の明示的なレベル解決 + OpenType GSUB アラビア語/シリア語のコンテキスト依存結合 + SMP RTL スクリプトの BIDI_Class）の対応が必要です。

2026-05-18 Version 2.67.0

LTR段落中，如果包含嵌入的RTL子字符串，则在生成器端添加了Unicode UAX #9 L2重排序功能。新的属性`THotPDF.EnableLTRParaReorder`（默认为False）允许调用者启用此功能，以生成符合规范、独立于阅读器的`/AP`输出：对于包含嵌入希伯来语/阿拉伯语的LTR段落，将在`/AP`生成时进行重排序，这样消费者阅读器就不需要对逻辑顺序的RTL子字符串进行自身的BIDI处理。

v2.66.0のシングルパスアルゴリズムと同様に、RTL段落のL1-L2レベルを処理します。LTR段落では、基本レベルは0です。各strong-R / strong-ALコードポイントはレベル1に解決されます。それ以外の文字はレベル0のままです。UAX #9のL2では、最低の奇数レベルは1であるため、ループは1回で済みます。各最大レベル1の文字列（連続するR/ALの文字列）を反転します。LTR文字と弱い/中立の文字は、変更せずにコピーされます。サロゲートペアは、反転処理中に保持されます。

パブリックメソッド `THotPDF.ApplyUAX9L2ReversalLTRPara` は、新しいアルゴリズムを単独で使用します (UTF-8 入力、UTF-8 出力)。これは、v2.66.0 の `ApplyUAX9L2Reversal` とは異なります。 `ApplyUAX9L2Reversal` の `ParagraphRTL=False` パスは、v2.66 の動作を維持しており、v2.66 の仕様に依存する呼び出し元は、バイト単位で同じ出力を確認できます。 LTR (左から右) の方向でテキストを並べ替える場合は、新しいメソッドを使用してください。

`EnableLTRParaReorder` 默认为 `False`，以保持与 v2.59-v2.66 版本完全相同的 `/AP` 输出，适用于从左到右的段落调用。当 `UseUAX9LevelReversal=False` 时，此选项无效（v2.59 中的简单反转不会重新排列从左到右的段落）；否则，这两个选项是相互独立的。

UAX #9 W1-W7 弱类型转换、N0-N2 中性字形、括号对解析、I1-I2 显式级别解析以及 OpenType GSUB 字形处理，这些功能范围保持在 v2.68 及以上版本。

2026-05-18 Version 2.66.0

AcroFormのUnicode表示ストリームに対して、Unicode UAX #9に基づいた、L1-L2の文脈を考慮した反転処理を追加しました。新しいプロパティTHotPDF.UseUAX9LevelReversal（デフォルトはTrue）は、v2.59.0で導入された、単純な文字列全体の反転処理を、仕様に準拠した2段階のL2並べ替えに置き換えます。これにより、RTL（右から左）の段落内に埋め込まれたLTR（左から右）のサブ文字列の内部的な論理的な順序が保持されます。

Concrete fix: an input "<Hebrew>AB" (logical UTF-16 05D0 05D0 0041 0042) previously emitted as the Tj operand hex 0042 0041 05D0 05D0 ("BAאא"), which inverts the embedded LTR "AB" - wrong per UAX #9. With L1-L2 active the same input now emits 0041 0042 05D0 05D0 ("ABאא"). Pure-RTL input with no L runs (e.g. the v2.59.0 pre-shaped Arabic smoke) remains byte-identical to the legacy naive reverse.

THotPDF.ApplyUAX9L2Reversal 公開メソッドは、新しいアルゴリズムをスタンドアロンのヘルパーとして提供します（入力と出力は UTF-8）。これにより、独自のレンダリングストリームを構築するユーザーや、/AP 生成前に再配置をプレビューしたいユーザーが利用できます。

このセクションで使用される、UAX #9 I1 + L2 の簡略化された単一埋め込みレベルのサブセットは以下のとおりです。RTL パラグラフでは、強い L の各コードポイントがレベル 2 に設定され、それ以外の文字 (R、AL、弱い、中立、サロゲート) はレベル 1 のままです。次に、レベル 2 はレベル 2 のシーケンスを最初に反転させ (埋め込まれた LTR サブストリングの論理的な順序を復元します)、最後に、文字列全体のレベル 1 セグメントを反転させます (これにより、視覚的な RTL レイアウトが生成されます)。サロゲートペアは、両方の処理段階で保持されます。

UAX #9 W1-W7（弱类型转换）+ N0-N2（中性字符 + 括号对）+ I1-I2（显式级别解析）+ LTR段落中嵌入RTL文本的重新排序，这些功能均包含在v2.67+版本中。v2.66.0版本修复了最常见的已知问题：包含多字符LTR子字符串的RTL段落。

UseUAX9LevelReversal のデフォルトは True です。False に設定すると、v2.59.0 での単純な文字列反転に戻り、バイト単位で完全に同じ出力が得られます。どちらの設定でも、FormUnicodeRTL と AutoDetectFormBidi は同じように動作します。

2026-05-18 Version 2.65.0

AcroFormのUnicode AP（Appearance）ストリームにおいて、Unicode標準附属書#9の段落方向の自動検出機能を追加しました。新しいプロパティTHotPDF.AutoDetectFormBidiにより、v2.59.0で導入されたFormUnicodeRTL手動設定の代わりに、各呼び出しごとに段落方向を検出するように、BuildUnicode*FieldContentヘルパー（シングルライン、マルチライン、コンボ）の動作を変更しました。これにより、手動でのフラグ切り替えなしに、1つのドキュメント内のLTR（左から右）とRTL（右から左）のフィールドを混在させて扱うことが可能になります。

テキスト内の最初の主要文字を検索し、その文字をBIDI_Class L（左から右）、R（右から左）、またはAL（アラビア文字）のいずれかに分類することで、表示方向が決定されます（UAX #9のルールP2 + P3）。右から左またはアラビア文字の主要文字が見つかると、段落は右から左（RTL）として固定されます。左の主要文字が見つかると、段落は左から右（LTR）として固定されます。主要文字のない段落は、P3に従ってデフォルトで左から右（LTR）になります。

認識されたBIDI_Class：Strong L - ASCII、Latin、Latin Extended、ギリシャ語、コプト語、キリル文字、アルメニア語、CJK統一文字、ハングル、平仮名、片仮名、イ。Strong R - ヘブライ文字ブロック（U+0590..U+05FF）、ヘブライ文字表示形式（U+FB1D..U+FB4F）、N'Ko、サマリア文字、マンダイック文字。Strong AL - アラビア文字ブロック、アラビア文字補完、アラビア文字拡張A、シリア語、ターナ文字、アラビア文字表示形式A + B（U+FB50..U+FDFF + U+FE70..U+FEFF）。検索中に、サロゲートペアおよび弱い/中性の文字（数字、句読点、空白文字）はスキップされます。

パブリックメソッド `THotPDF.DetectBidiParagraphDirection` は、方向を事前に計算したい呼び出し元に対して、方向検出機能を提供します (例: `/Lang` タグ付け、ミラー表示、カスタムフィールドルーティング)。 UTF-8 でエンコードされた `AnsiString` を受け取り、ブール値 (True = 右から左) を返します。空の入力の場合、P3 に従って `False` を返します。

AutoDetectFormBidi 默认为 False；现有 v2.59.0-v2.64.0 版本的行为保持不变。当设置为 True 时，辅助函数会忽略 FormUnicodeRTL，具体取决于每次调用。禁用 AutoDetectFormBidi 以恢复手动控制。

UAX #9 隐式级别、弱类型和中性括号解析（规则 W1-W7、N0-N2、I1-I2、L1-L4），以及自动的阿拉伯语/亚述语 OpenType GSUB 上下文连接，计划在 v2.66+ 版本中实现。混合双向段落仍然需要手动干预，超出段落级别的方向控制。

2026-05-18 Version 2.64.0

PDF 1.2、ISO 32000-1 10.5.5 の ExtGState ハーフトンスクリーン (/HT) エントリと、Type 1 スポット関数ハーフトン辞書ビルダーを追加しました。新しい `THotPDF.RegisterHalftoneType1` は、呼び出し元が制御する CMYK 分割スクリーニング用の PDF 1.7 表 76 の Type 1 ハーフトン辞書を構築します (インチあたりの行数で表される周波数、度で表されるスクリーン角度、スポット形状、オプションで正確なスクリーニング、転送関数、説明的なハーフトン名)。これを `THotPDF.RegisterHalftoneState` と組み合わせて、その辞書参照を ExtGState /HT エントリにラップし、`THPDFPage.SetGraphicsState` で使用します。

/SpotFunction 接受两种类型的参数：一是符合 PDF 1.7 第 78 表的内置颜色名称（例如 SimpleDot、InvertedSimpleDot、DoubleDot 等），二是调用者自定义的颜色函数字典引用。如果使用未知的内置颜色名称，则会引发错误，错误信息中会包含完整的内置颜色名称列表。颜色名称和函数是互斥的。

/TransferFunction はオプションです。トーン再現を呼び出し元で制御するために、Function ディクションの参照値を渡すか、TransferFunctionDefault を True に設定して、/TransferFunction /Identity (デフォルトの読み取り側設定) を出力します。この2つの形式は相互に排他的です。

RegisterHalftoneState 函数接受一个半色调字典引用（通常是 RegisterHalftoneType1 函数的返回值），或者当 HTDefaultName 设置为 True 时，它会重置为默认的半色调名称，从而恢复消费者阅读器的内置半色调功能。

すべてのエミッションにより、ドキュメントのバージョンが自動的にPDF 1.2に更新されます。頻度は0より大きくなければなりません。無効なスポット関数名は、辞書が割り当てられる前にエラーが発生します。

v2.65 以降、残りのハルftone タイプがスケジュールされています。具体的には、Type 5 のマルチコンポーネントハルftone と、Type 6、10、16 のスレッショルドストリームハルftone です。Type 1 が実装されたことで、マトリックスの「ExtGState エントリ」候補は、完全なカバー範囲の 1 つのスライスとなります。

2026-05-18 Version 2.63.0

PDF 1.4、ISO 32000-1の11.6.5および11.7.4、ExtGStateのソフトマスクおよびアルファが形状を表すエントリを追加しました。新しいTHotPDF.RegisterSoftMaskStateは、透明度に関連する/SMaskおよび/AISグラフィックスステートパラメータを1つのExtGState辞書にまとめ、仕様で定義されているすべてのエントリ（マルチタイプの/HTハーフトンスクリーンを除く）について、v2.20.0、v2.60.0、v2.61.0、v2.62.0、v2.63.0のExtGStateエントリの対応を完了します（マルチタイプの/HTハーフトンスクリーンはv2.64以降で対応予定）。

`/SMask 属性可能包含字面值 `/None`（调用方传递 SMaskNone = True，这是一种在复杂组合对象后常用的重置模式），或者包含对间接软掩字典的引用（调用方传递 SMaskDict，这是一种高级用法）。这两种形式是互斥的。调用方负责软掩字典的内容以及底层的透明表单对象；从 v2.64 版本开始，将添加一个专门的构建器辅助功能。

/AIS 参数控制当前 alpha 值是否被解释为 alpha 值（false）或形状（true），这适用于图形状态的其余部分。默认情况下，如果 AIS 设置为 -1，则会跳过 /AIS 条目。如果传递 AIS = 0 或 1，则会分别输出 /AIS false 或 /AIS true。任何其他 AIS 值都会引发带有描述性消息的错误。

少なくとも、/SMask（NoneまたはDict）または/AISのいずれか一方を指定する必要があります。すべてのパラメータをデフォルト値で呼び出すとエラーが発生します。また、任意の項目の出力は、ドキュメントを自動的にPDF 1.4にアップグレードします。

THotPDF.SetGraphicsStateで使用するための、自動生成されたExtGState名（GS1、GS2など）を返します。これはv2.42.0で追加されたAddImageWithSMaskとは異なります。AddImageWithSMaskは、単一のXObject上の画像レベルのアルファですが、これはExtGStateレベルのマスクであり、その後のすべての描画演算子に影響を与えます。

ExtGState エントリの残りの部分は、v2.64 以降で実装される予定です。/HT は、ハーフトンスクリーンを表し、Type 1、5、6、10、16 のいずれかの値を取ります。

2026-05-18 Version 2.62.0

PDF 1.2/1.3 以降、ISO 32000-1 11.7.5.4 の ExtGState における黒色生成とアンダーカラー除去のエントリを追加しました。新しい THotPDF.RegisterBlackGenerationState は、CMYK プリプレスワークフローで使用される、RGB から CMYK への変換がラスター化時に行われる場合（通常は新聞、パッケージ、ワイドフォーマット印刷など、インクの配置が出力デバイスに依存する場合）に、4 つの関数参照グラフィックスステートパラメータ（/BG、/BG2、/UCR、/UCR2）を 1 つの ExtGState ディクテーションにまとめます。

/BG および /UCR (PDF 1.2) は、入力 1 つ / 出力 1 つの関数辞書です。/BG2 および /UCR2 (PDF 1.3 以降) は、関数辞書であるか、コンシューマービューアのデフォルトのカーブを復元するリテラル名 /Default のいずれかです。設定関数では、各関数スロットに対して THPDFObject を受け入れます (通常は v2.52.0 の RegisterSampledFunction を使用して構築されます)。また、/Default リテラル名を使用する場合に備えて、BG2DefaultName および UCR2DefaultName という 2 つのブールフラグも用意されています。同じ /BG2 または /UCR2 スロットで、関数辞書と Default フラグを混在させると、説明的なメッセージが表示されます。

/BG、/BG2、/UCR、/UCR2 (Function または Default) の少なくとも1つを指定する必要があります。すべての項目をデフォルトにするとエラーが発生します。/BG2 または /UCR2 のいずれかの項目 (Function または Default) が指定されると、自動的に PDF バージョンが 1.3 に引き上げられます。

THotPDF.SetGraphicsStateで使用するための、自動生成されたExtGState名（GS1、GS2など）を返します。v2.60.0で導入されたRegisterTransferFunctionState（各チャネルの出力曲線）と組み合わせて使用すると効果的です。一般的なCMYKカラープロセスのワークフローでは、RGBからCMYKへの変換に使用するBG/UCR ExtGStateと、出力デバイスでの最終的なトーン再現に使用する/TR ExtGStateが登録されます。

v2.63 以降，计划继续处理剩余的 ExtGState 条目：/HT 用于半色调屏幕（类型 1 / 5 / 6 / 10 / 16），以及 ExtGState 级别的 /SMask 和 /AIS 柔性掩码。

2026-05-17 Version 2.61.0

PDF 1.2/1.3 以降、ISO 32000-1 8.6.5.7 + 8.6.5.8 + 11.7.4 の ExtGState プリント制御エントリを追加しました。新しい THotPDF.RegisterPrintControlState は、プリプレス向けのグラフィックスステートパラメータ /OP、/op、/OPM、/SA、/RI および /FL を 1 つの ExtGState ディクショナリにまとめます。これは、オーバープリント、ストローク調整、レンダリングインテント、および曲線フラット化の制御が必要な PDF/X-1/X-3/X-4 のプロセスのためのものです。

すべての6つのパラメータは、それぞれ独立してオプションです。デフォルト値は次のとおりです：Overprint = -1（/OPと/opをスキップ）、OverprintMode = -1（/OPMをスキップ）、StrokeAdjustment = -1（/SAをスキップ）、RenderingIntent = ' '（/RIをスキップ）、Flatness < 0（/FLをスキップ）。呼び出し元は少なくとも1つのエントリを提供する必要があります。空の辞書はエラーを発生させます。

CRITICAL RULES — preserve verbatim, do NOT translate: - HTML tags: , , , , ,
, , ,
,
, etc. - HTML entities: ", &, <, >, , etc. - API names / identifiers: THotPDF, GetSingleSubstituteGlyph, TextOut, AddXFAPacket, RegisterUnicodeTTF, THPDFPage, AddTextField, RegisterSampledFunction, THPDFDictionaryObject, THPDFStreamObject, AddImageWithSMask, ShowImage, etc. - PDF spec references: "PDF 1.7 §12.7.6", "ISO 32000-1 8.9.5.4", "ISO 19005-1 §6.4.2", "UAX #38", "Unicode 16.0 §13.5", "ISO 14289-1", etc. - OpenType feature tags (single-quoted): 'liga', 'salt', 'aalt', 'init', 'medi', 'fina', 'isol', 'mong', 'arab', 'rlig', 'syrc', 'pres', 'cjct', 'akhn', 'rclt', 'clig', 'calt'. - Unicode block names / font names / codepoints: Arabic Extended-A, Mongolian Baiti, Noto Sans Mongolian, Devanagari, U+1800-U+18AF, U+0671, NIRUGU, LAM-ALEF, Estrangelo Edessa, Identity-H, etc. - PDF object names: /Fields, /XFA, /Filter, /WMode, /AcroForm, /Length, /MarkInfo, /StructTreeRoot, /Metadata, /Lang, /AP, /RV, /V, /DV, /DR, /MK, /AA, /SMask, /AIS, /BG, /UCR, /OP, /OPM, /SA, /RI, /FL, /TR, /CIDToGIDMap, /FontFile2, /W, /Encoding, /Default, /None, /SpotFunction, /Type, /ObjStm, etc. - Version numbers: v2.119.54, v2.84.0, v2.119.43-50, v2.55.0-v2.59.0, etc. - PDF operators: Tj, Tm, Td, T*, TL, Tf, BDC, EMC, scn, SCN. - Hex / numeric constants: $7FF8000000000000, 0x0002, U+FE70..U+FEFF, etc. - File / encoding names: CCITTFaxDecode, FlateDecode, UTF-16BE, DeviceGray, DeviceRGB, DeviceCMYK, Identity-H. Translate ONLY the descriptive English prose (verbs, adjectives, narrative sentences). Return ONLY the translation — no explanations, no markdown wrappers, no "[[N]]" tags, no leading/trailing whitespace, no extra newlines beyond what was in the input. TEXT: Overprint sets /OP and /op together (PDF spec defaults /op to /OP when only the latter is set, but spec-strict PDF/X pipelines expect both entries explicit). OverprintMode = 1 enables PDF 1.3 CMYK-aware overprint where any zero component paints transparent; auto-bumps the document version to 1.3. オーバープリント設定の /OP と /op を一緒に設定します (PDF 仕様では、/op が設定されていない場合に /op を /OP に自動的に設定しますが、仕様に厳密な PDF/X パイプラインでは、両方のエントリを明示的に指定する必要があります)。 OverprintMode = 1 を設定すると、PDF 1.3 で CMYK に対応したオーバープリントが有効になり、すべてのゼロ成分が透明色として描画されます。これにより、ドキュメントのバージョンが自動的に 1.3 に更新されます。
RenderingIntent 接受四个标准值：'AbsoluteColorimetric'、'RelativeColorimetric'、'Saturation' 和 'Perceptual'；任何其他非空字符串都会引发错误。Flatness 的取值范围限制在 [0.0..100.0] 内；超出范围会引发错误。

THotPDF.SetGraphicsStateで使用するための、自動生成されたExtGState名（GS1、GS2など）を返します。v2.20.0で追加されたRegisterExtGState（透明度/ブレンドモード）およびv2.60.0で追加されたRegisterTransferFunctionState（出力曲線）と組み合わせて使用すると便利です。通常、PDF/Xの設定では、これらの中から1つずつ使用されます。

機能に基づいた項目（/BG、/UCR、/BG2、/UCR2：黑色生成 + 亚色去除）以及复杂的/HT半色调屏幕 + ExtGState 级别的/SMask柔化掩模，仍将作为未来的开发内容。

2026-05-17 Version 2.60.0

PDF 1.3 以降、ISO 32000-1 11.7.3.4 の ExtGState /TR (転送関数) のサポートを追加しました。新しい `THotPDF.RegisterTransferFunctionState` メソッドは、ラスター化時に色を適用するトーン再現カーブを持つ ExtGState ディクショナリを登録します。このカーブは、v2.52.0 の関数タイプ 0 のサンプル LUT (または、呼び出し元が作成した他の関数ディクショナリ) として提供されます。この機能は、既存の `RegisterSampledFunction` プリミティブと連携し、ICC プロファイルを使用せずに、手動で調整されたガンマ/明るさ/印刷特性カーブを作成できます。

二つの呼び出しパス：

SingleFunc フォーム：一つの関数がすべての出力チャンネルに適用されます（ガンマ補正や輝度調整などの用途）。

各チャンネル配列形式：对于RGB-A管道，使用包含4个元素的数组 [TR_R, TR_G, TR_B, TR_A]；对于CMYK重现曲线，使用包含4个元素的数组 [TR_C, TR_M, TR_Y, TR_K]；根据PDF规范，这四个位置都不能为空。

THotPDF.SetGraphicsStateで使用するための、自動生成されたExtGState名（GS1、GS2など）を返します。描画演算（テキスト/パス/画像）を適用する前に、この状態を設定します。これにより、転送処理が適用されます。

複数の呼び出し元（SingleFunc が null ではない + PerChannel が空ではない）が存在する場合、例外が発生し、API レベルで仕様で義務付けられている相互排他が強制されます。

2026-05-17 Version 2.59.0

AcroForm Unicode /AP (PDF 1.7 ISO 32000-1 12.7.4.3) 对从右向左的文本方向添加了支持。引入了新的 THotPDF.FormUnicodeRTL 布尔属性；当该属性为真时，所有三个 Unicode /AP 辅助程序（单行、多行、组合行）都会反转其生成的十六进制 Tj 操作数的 UTF-16 码单元顺序，以便预先格式化的阿拉伯语/希伯来语/叙利亚语内容以视觉上从右向左的顺序显示。在反转过程中，UTF-16 代理对始终作为一个整体保留（高字节始终与低字节相邻，以保持原始顺序），因此 SMP 码点，例如古代文字的字母，可以正确显示。

変更内容は、v2.59.0では方向反転処理のみを扱います。呼び出し元は、v2.59.0が意図的に行わない2つの前処理を担当する必要があります。(1) 完全なUAX #9双方向アルゴリズムによる解決 (LTR/RTL/数値/ニュートラルコンテンツの混在)、(2) アラビア文字/シリア文字のコンテキスト依存の字形選択 (先行/中行/後行/孤立字形)。呼び出し元は、AddTextFieldに渡す前に、アラビア文字をUnicodeの表示形式 (U+FB50..U+FDFF + U+FE70..U+FEFF) に整形する必要があります。ヘブライ文字にはコンテキスト依存の字形がないため、整形なしで動作します。

/V（逻辑 Unicode 顺序）未改变：PDF 文本字符串始终携带类型信息，因此符合规范的文本提取器可以正确地识别逻辑顺序。只有 /AP Tj 操作数的顺序发生了变化，以便渲染器以从右到左的方式进行视觉显示。在此版本中，v2.55.0-v2.59.0 AcroForm 国际化 /AP 链已完成：包括支持富文本、单行/多行/组合 CID 字体，以及预先定义的 RTL（从右到左）方向反转。完整的 UAX #9 + 自动 GSUB 塑形功能将保留在 v2.60.0+ 版本中。

2026-05-17 Version 2.58.0

v2.56.0 / v2.57.0で、ユーザーが提供するUnicodeフォントを使用した/APチェーンを、ffCombブランチに拡張しました（PDF 1.7 ISO 32000-1 12.7.4.3 Tx /Ffビット25）。SetFormUnicodeFontDictでType 0の複合フォントが登録され、ffCombとASCII以外の初期値を持つTxウィジェットが追加された場合、HotPDFは、各セルが等幅のコンビネーションセルで構成され、絶対Tmマトリックスが各セルで使用され、UTF-16BEの16進文字列Tjオペランドを使用して、1つのCJKコードポイントを配置する、実際の/AP /Nアピアランスストリームを生成します。

UTF-16 サロゲートペア（コードポイントが U+10000 以上のもの、例えば絵文字や CJK 拡張 B/C/D の補足文字）は、単一のコンビネーションセルを占有し、Acrobat が単一のグリフを持つコンポジットフォントのコンビネーションセルを配置する方法と一致します。セルの中央配置の計算式は、v2.46.0 以降の ASCII コンビネーションブランチと同じであるため、視覚的な出力は ASCII の単一文字レイアウトと一致します。

ASCIIの結合フィールドは、v2.46.0の出力と同じバイト単位で保持されます。`SetFormUnicodeFontDict`を使用しない非ASCIIの結合フィールドは、引き続きv2.46.0の空のAPプレースホルダーにフォールバックします（変更なし）。今回のリリースで、v2.55.xからv2.58.0までのAcroFormの国際化された/APチェーン（シングルライン、マルチライン、結合）が完了しました。RTL（右から左）の双方向テキスト整形（UAX #9 + アラビア語のコンテキスト依存結合）は、v2.59.0以降の範囲で引き続きサポートされます。

2026-05-17 Version 2.57.0

v2.56.0版本中，已扩展了用户自定义的Unicode字体/AP路径，以支持多行文本字段（PDF 1.7 ISO 32000-1 12.7.4.3 ffMultiline / Tx /Ff bit 13）。当SetFormUnicodeFontDict注册了Type 0合成字体，并且添加了带有ffMultiline和非ASCII初始值的Tx控件时，HotPDF现在会将UTF-16文本自动换行，并通过Td/T*和/TL前导符，逐行输出一个UTF-16BE十六进制字符串（类似于v2.46.0版本的ASCII多行布局）。

テキストの折り返しでは、単純なヒューリスティックを使用します。具体的には、CJK文字または幅の広いコードユニット（U+2E80以上）に対しては1em、狭いコードユニット（ASCII範囲およびLatin-1の句読点）に対しては0.5emの字下げを行います。これにより、Latin文字とCJK文字が混在するコンテンツでも、フォントの`/W`配列を読み込まずに適切に折り返されます。改行文字（CR/LF/CRLF）はそのまま保持されます。ウィジェットの矩形を超える行は、現在のフォントサイズで収まる行数に切り捨てられます。この切り捨ての動作は、ASCIIの複数行の機能と同じです。

ASCII 複数行、ASCII 単一行、ASCII 組み合わせ、および v2.56.0 の非 ASCII 単一行のパスは、すべてバイト単位で同一です。非 ASCII 組み合わせパス（ffComb + マルチバイトテキスト）は、現時点では v2.56.0 の単一行ヘルパーにフォールバックされます。ffComb に特有の Unicode レイアウトは v2.58.0 以降で実装され、同様に RTL bidi の整形（UAX #9 + アラビア語のコンテキスト依存結合）も v2.58.0 以降の範囲です。

2026-05-17 Version 2.56.0

AcroForm /AP 描画ストリームのレンダリングにおいて、ユーザーが提供する Unicode フォントのサポートを追加しました (PDF 1.7 ISO 32000-1 12.7.2 + 12.7.4.3)。このリリース以前、`GenerateTextFieldAP` パスは、フィールドの初期値に 0x80 以上のバイトが含まれている場合、空の `/AP` プレースホルダーを出力していました。そのため、非 ASCII テキストは、リーダーにインストールされているフォントに依存する `/NeedAppearances=true` による再生成、または v2.55.0 の `/RV` リッチテキストパス (リーダーのリッチテキストエンジンに依存) のいずれかによってのみレンダリングできました。v2.56.0 では、この問題を解消しました。ユーザーは `SetFormUnicodeFontDict` を使用して、Type 0 / CIDFontType2 + Identity-H の複合フォント辞書を登録でき、HotPDF は登録されたフォントを `Tf` で選択し、値を UTF-16BE の 16 進文字列として `Tj` オペレーターでレンダリングする、実際の `/AP /N` 描画ストリームを出力します。

新しい THotPDF.SetFormUnicodeFontDict(LogicalName, FontDict) 関数により、論理フォント名とフォント辞書のペアを登録できます。登録後、AcroForm レベルの /DA、すべての Tx ウィジェットの /DA、および非 ASCII Tx の初期値の /AP ストリームはすべて、この論理フォント名に切り替わります。AcroForm の /DR/Font 辞書には、/Helv と /ZaDb に加えて、このフォントも含まれます。また、フォームの XObject の /Resources/Font サブ辞書も、同じ間接フォントを参照するため、AP はレンダリング時に /DR の解決に依存しません。空の引数と nil を渡すと、v2.46.0 の /Helv のみを使用する動作に戻ります。

新しい `THotPDF.CreateIndirectFontDict`：这是一个公共辅助函数，用于分配一个新的空的 `THPDFDictionaryObject`，并将其注册为间接的 PDF 对象，以便调用者可以构建自定义的字体/颜色/OCG/函数字典，这些字典必须序列化为 "N G R" 引用。它与 `SetFormUnicodeFontDict` 配合使用，用于构建类型 0 的组合字体字典。

ASCII Txフィールドは引き続き/Helvを使用し、v2.46.0およびv2.55.0の呼び出し元と同じバイト単位の/AP出力を生成します。 SetFormUnicodeFontDictを使用せずにマルチバイトTxの場合、互換性のために、v2.46.0の空のAPプレースホルダーの動作が維持されます（変更なし）。

マルチラインおよびコンビナショナルな非ASCII文字の/APサポート、および右から左への双方向テキスト整形（UAX #9およびアラビア語のコンテキスト依存結合）は、v2.57.0以降の範囲に含まれます。v2.56.0では、シングルラインの論理順序のCJK、キリル文字、ベトナム語、ギリシャ語、および同様の文字体系がサポートされています。

2026-05-17 Version 2.55.0

AcroFormのリッチテキストTxウィジェットのサポートを追加しました（PDF 1.7 ISO 32000-1 12.7.4.3 + 付録L）。新しいTHPDFPage.AddRichTextFieldメソッドは、/RV（リッチテキストXHTMLボディ）、/DS（CSSのようなデフォルトスタイル）、ffRichTextフラグ（/Ffビット26）、およびプレーンテキストの/V + /DVフォールバックを含むテキストウィジェットを生成します。AcrobatおよびFoxitは、RichTextビットがオンの場合、/RVから直接レンダリングし、リーダーにインストールされているUnicodeフォントからフォントの代替フォントを取得します。これにより、マルチバイトコンテンツ（CJK/キリル文字/アラビア文字/アクセント付きラテン文字）が、HotPDFが/DRリソースにCIDフォントを埋め込むことなく、正しく表示されます。HotPDF独自のレンダリングストリーム（/AP）ジェネレーターにCIDフォントを埋め込むことは、今後の作業です。リッチテキストに対応したビューアには、それが必要ありません。

/V と /RV は、必要に応じてマルチバイト入力を自動的に検出し、UTF-16BE の 16 進文字列エンコーディング（FE FF BOM + ビッグエンディアンのコード単位）に切り替えます。これは、既存の AddTextField の国際的なプレーンテキストフィールドの動作と一致します。ASCII の内容は、v2.46.0 のプレーンテキスト出力パスと同じように、リテラル PDF 文字列として保持されます。

AcroForm国際文字候補において、以下の3つの改善点があります。(1) CIDフォントの/DRリソースパスを調整し、HotPDFが生成する/APストリームが、リーダーの高度なテキストエンジンに依存せずに非ASCII文字をサポートするようにします。(2) アラビア語/ヘブライ語の右から左へのテキスト表示を改善します。(3) /AA /Kキー入力アクションのヘルパー機能を実装します。

2026-05-17 Version 2.54.0

PDF 1.7 および ISO 32000-1 7.10.2 に準拠した、三次スプライン補間を使用した関数タイプ 0 (サンプリング)。`RegisterSampledFunction` には、新しいオプションの `Order` パラメータが追加されました (デフォルトは 1、PDF 1.7 の表 38 に記載されている有効な値は 1 または 3)。`Order = 3` の場合、各入力軸に対して三次補間が行われます。`Order = 1` の場合、既存の線形動作が維持され、バイト単位で変更がないため、v2.52.0 および v2.53.0 の呼び出し元は表面的な変更を認識しません。

マルチ入力/マルチ出力の関数タイプ0のコードパスに対するエンドツーエンドの回帰テストを追加しました。新しいテストでは、4x4のグリッド上で、三次補間を使用した2入力/3出力のサンプリング関数を登録し、仕様のサンプル順序ルール（「入力座標は最初の入力次元に沿って最も速く増加する」）を検証します。このテストでは、16個のグリッドポイントx 3チャンネルのバイト値を、Python検証器で再導出された解析式と比較します。

Acrobat、Foxit、qpdf均支持Order = 3；一些较旧的移动设备查看器在遇到不熟悉的Order值时，会静默地回退到线性插值。Cubic仍然是可选功能，以保持最大的兼容性。

2026-05-17 Version 2.53.0

THotPDF.RegisterSeparationLUT (ColorantName, AlternateCS, Samples) 新機能，基于 v2.52.0 的 RegisterSampledFunction 机制，允许调用者通过一个扁平的字节流，表达完整的非线性色调曲线，而无需手动构建 Function Type 0 字典。此功能使用一个采样函数类型 0 (LUT) 作为其色调转换 (PDF 1.7 ISO 32000-1 8.6.6.4 + 7.10.2)。

色の変化が非線形の場合、新しいLUTのバリアントを使用します（PANTONE Hexachromeスタイルの調子グラデーション、ガンマ補正された密度曲線、印刷特性に合わせた手書きのトーン曲線、完全なICCプロファイルを使用しないsRGBからスポットの色変換ICC LUT）。線形な0から最大強度の範囲のグラデーションで十分な場合は、v2.45.0のRegisterSeparationを使用します（単色のPANTONEスポットカラーの一般的なケース）。

サンプルは、8ビットのRGB/CMYK/グレースケールバイトで構成され、順序は(c0_0, c1_0, ..., cM-1_0, c0_1, ..., cM-1_S-1)です。ここで、Sは、サンプルデータの長さ(Length(Samples))をMで割った値で計算されるグリッド点の数です。Sは少なくとも2以上である必要があり、そうすることで、関数が補間可能な範囲を持つようにします。グリッド点間の線形補間がデフォルトです（PDF 1.7 /Order 1）。この関数は、THPDFPage.SetFillColorSpace / SetStrokeColorSpace と SetFillColor([tint])（ここで 0 <= tint <= 1）で使用するための、登録されたカラー空間の名前（Sep1, Sep2, ...）を返します。

内部的に、`THPDFSeparationParams.TintFunc` 的类型从 `THPDFDictionaryObject` 更改为通用的 `THPDFObject` 基类，以便它可以包含函数类型 2（v2.45.0 版本）或函数类型 0 流（v2.53.0 版本）；这两种形式都通过 `THPDFArrayObject.AddObject` 以相同的“N G R”间接引用方式序列化，并存储在 `/Separation` 数组中。

2026-05-17 Version 2.52.0

PDF 1.7、ISO 32000-1 7.10.2 の Function Type 0 (Sampled) の登録機能を追加しました。Sampled functions は、任意の入力と出力のマッピングを、M次元の出力サンプルのN次元のグリッドとして表現します。レンダラーは、グリッド点間の線形補間を使用して、中間的な入力を評価します。ICC プロファイルを使用するのが過剰な場合、または手動で調整されたカラー LUT が必要な場合に、Type 0 を使用します（ExtGState 内の /TransferFunction、/Separation / /DeviceN の線形 Type 2 / 算術 Type 4 パスで既にサポートされている、ハルftone の閾値曲線、または Function ディクショナリを使用するその他の PDF 構造）。

新しいTHotPDF.RegisterSampledFunction(Domain, Range, Size, BitsPerSample, Samples)関数は、間接的な/FunctionType 0ストリームを生成します。このストリームには、/Domain (2N)、/Range (2M)、/Size (N)、/BitsPerSample (1, 2, 4, 8, 12, 16, 24または32)、/Order 1 (線形補間)が含まれており、生のビットパックされたサンプルデータがペイロードとして含まれます。この関数は、間接的なTHPDFStreamObjectを返します。これにより、呼び出し元は、Function辞書が期待される場所でこのオブジェクトを使用できます。

Samplesバイト配列の長さは、ceil(GridPoints * M * BitsPerSample / 8) と比較して検証されます。BitsPerSampleは、8、16、24、または32ビットの幅を持ち、バイトアラインされたビッグエンディアン形式です。サブバイト幅（1、2、4、または12ビット）は、PDF 1.7のセクション7.10.2に従って、最上位ビット（MSB）から順にパックされ、最後のバイトはゼロパディングされます。

HPDFRegisterFunctionType3 および HPDFRegisterFunctionType4 を使用して、Type 3 (縫い合わせ) および Type 4 (PostScript 計算機) の関数が、v2.18.0 / v2.47.0 以来、社内でのみ利用可能でした。今回のリリースでは、Type 0 も同様の公開 API サポートレベルに引き上げられます。

2026-05-17 Version 2.51.6

v2.51.x バージョンのバイナリ安全性の改善作業を完了しました。具体的には、最後の `TStringList` の "Source=Target" の相互変換に関する問題を修正しました。これは、`FStructRoleMap` (PDF 1.7 ISO 32000-1 14.7.3 /StructTreeRoot /RoleMap) に関連しています。`AddStructRoleMap` を使用して登録されたカスタム構造役割名は、CP_ACP=65001 の Windows 環境で、以前は問題なく動作していましたが、現在は「Beta: Use Unicode UTF-8」というオプションが有効な場合に、意図しない変更が加えられることがありました。この問題を修正するために、ストレージを (Source: TBytes; Target: TBytes) のレコードからなる動的配列に移行し、挿入時および読み取り時に、バイトをそのままコピーする `Move()` を使用するようにしました。標準的な PDF 構造タイプ (Document, P, H1..H6, Span, Div など) は、仕様では ASCII で定義されているため、以前のバージョンでは実質的に問題なく動作していました。この修正は、作成ツール固有の Latin-1 役割名を標準タイプにマッピングする呼び出し元にのみ影響します。

SaveDictionaryObject 中，已将 PDF 名称 #XX 转义扩展到字典的键（PDF 1.7 7.3.5）。以前，字典的键以原始形式复制到输出流，这会导致任何大于或等于 0x80 的字节未转义，从而产生不符合规范的输出。此问题可以通过 AddStructRoleMap 使用非 ASCII 角色源来触发。现在，字节级别的修剪 + #XX 转义逻辑位于一个共享的辅助函数 (_EscapePDFNameBytes) 中，该函数由 SaveNameObject（名称值）和 SaveDictionaryObject（字典键）调用。 ASCII 键（HotPDF 生成的字典的通用情况）会转义为字节上完全相同的输出，因此现有文件和测试不受影响。

このリリース後、v2.51.xのバイナリ安全対策機能（PubSec受信者、DeviceNカラー名、PDF名前値の出力、PDF名前キーの出力、構造役割マップの保存）が完全に実装されました。これには、HotPDFが認識するすべてのバイトデータに対して、AnsiStringをUnicodeStringに変換する処理が含まれます。34個のテストのうち34個が成功し、27個の検証器のうち27個が合格しました。

2026-05-17 Version 2.51.5

v2.51.4のバイナリ安全性のチェックを、さらに2つの出力パスで実施しました。これらのパスでは、WindowsのCP_ACPが65001（「ベータ版：世界中の言語をサポートするためにUnicode UTF-8を使用」）に設定されている環境において、非ASCIIバイトが意図せず変更される可能性がありました。

DeviceN カラー名が、以前は UnicodeString エントリの TStringList として保存されていたのに対し、現在は THPDFDeviceNParams 内の動的配列である TBytes として保存されています。以前の実装では、すべてのインク名について、AnsiString から UnicodeString、そして再び AnsiString への変換が必要であり、UTF-8 ANSI 環境では、0x80 以上のすべてのバイトが 3 バイトの置換シーケンス EF BF BD に書き換えられていました。 ASCII のみで構成されたインク名（PANTONE / Hexachrome や「Red」/「Blue」のような名前）には影響はありませんでしたが、カスタムの非 ASCII インク名（例えば、非英語の印刷ワークフローで使用される Latin-1 のアクセント付きスポットインク名）は、このリリース以前には問題なく処理されていませんでした。

PDFの名前の出力パス（SaveNameObject）は、現在、バイト単位で安全であり、仕様に準拠しています。以前の実装では、`AnsiString(Trim(String(ValObject.Value)))`が呼び出され、ディスクに書き込まれるすべてのPDF名に対して、同様の破壊的なラウンドトリップ処理が行われていました。現在、名前はバイト比較（"char <= 0x20" はDelphiのTrimのセマンティクスに一致）によってトリミングされ、規定の範囲0x21～0x7E以外のバイトは、PDF 1.7およびISO 32000-1の7.3.5で規定されている#XXエスケープシーケンスを使用して出力されます。先頭または末尾に空白がなく、埋め込みの特殊バイトがないASCII名は、以前と同じビット単位の出力でシリアル化されるため、既存のファイルとテストには影響ありません。

新しいラウンドトリップ検証機能 (smoke_devicen_binary_safe) は、名前中に埋め込まれた 0xA0 バイトを含む DeviceN インクを登録し、生成された `/Names` 配列が、破損した "#EF#BF#BD" シーケンスではなく、仕様に準拠した "#A0" エスケープを含むことを検証します。このリリースにより、v2.51.x のバイナリセーフティチェーン (PubSec 受信者、DeviceN インク名、一般的な PDF 名の生成) が完了します。 33 件のテストのうち 33 件が成功し、26 件の検証機能のうち 26 件が成功しました。

2026-05-17 Version 2.51.4

パブリックキーセキュリティハンドラにおいて、受信者のエンベロープバイトのサイレントな破損を修正しました (PDF 1.7 ISO 32000-1 7.6.5)。ホストシステムでWindowsの「ベータ版：世界言語サポートのためにUnicode UTF-8を使用する」が有効になっている場合 (CP_ACP=65001)、以前のTStringListベースのPKCS#7エンベロープデータブロックの保存により、AnsiStringからUnicodeString、そして再びAnsiStringへの変換が行われ、ASCII以外のすべてのバイトがUTF-8の置換シーケンス (EF BF BD) で書き換えられていました。この破損は、SHA-1ファイルキーの計算 (アルゴリズム9) と、生成される/Recipientsの16進文字列の両方に同じように伝播しました。その結果、生成されたPDFは、HotPDF自身の破損したキーで復号化できますが、サードパーティ製のリーダーは、元のエンベロープバイトから同じキーを導き出すことができず、暗号化されたファイルは、同じCP_ACPでロックされたシステム上でのHotPDFでのみ読み取り可能になります。

この修正では、受信者ストアが動的配列のTBytesに置き換えられます。パブリックAPIのAddPubKeyRecipientのシグネチャは変更ありません。エンベロープのバイトは、Move()によって完全にコピーされます。文字コードページ変換の処理は削除されました。

/Recipients の hex 形式は、ホストのロケールに関係なく、提供されたエンベロープをバイト単位で完全に再現します。Acrobat、Foxit、qpdf、および PKCS#7 をサポートするすべてのリーダーは、仕様で定義されているように、ファイルの暗号化キーを復元できます。

v2.33.0で新しい双方向検証機能（smoke_pubsec_verify）が追加されましたが、それ以来このビルドで失敗していました。v2.51.4では、この検証がFAILからOKに変わりました。今回のリリースで、v2.51.x全体の監査チェーン（R=5の監査、R=6のユーザーパスワード監査、R=6の所有者パスワードの修正、PubSec受信者バイトの修正）が完了し、v2.33.0以来初めて、25個すべての検証機能が正常にパスしました。

2026-05-16 Version 2.51.3

AES-256 V=5 R=6のオーナーパスワード検証ハッシュを修正し、ISO 32000-2のアルゴリズム2.Bに準拠するようにしました。PDF 2.0のハッシュ処理では、初期のKの状態として、SHA-256(パスワード || ソルト || udata)が規定されています。ここで、オーナーパスワードの派生におけるudataは、全長48バイトの/Uエントリです。以前のHotPDFのリリース（v2.22.0からv2.51.2まで）では、udataは反復処理されるK1ステップでのみ使用され、初期のKからは除外されていました。これにより、仕様に準拠していない/O[0:32]のハッシュが生成され、Acrobat、Foxit、qpdfなどのリーダーは、オーナーパスワードの検証時にこれを拒否していました。ユーザーパスワードの復号は影響を受けませんでした。なぜなら、そのハッシュ処理は、udata引数が空の状態で呼び出されるため、修正の有無にかかわらずビット単位で同一であるからです。

Acrobat、Foxit、qpdf 现在会验证与 HotPDF 生成的 R=6 文件相关的所有者密码。在 v2.51.3 之前生成的 /O[0:32] 和 /OE 值仍然可以用于用户密码的解密，但无法通过符合规范的阅读器使用所有者密码解锁。如果需要外部验证所有者密码，请使用 v2.51.3 重新生成受影响的 R=6 文件。

/U / /UE / /Perms の V=5 R=5 および V=4 の値は、v2.51.3 以前の出力とバイト単位で同一です。この修正は、PDF20HashDanceR6 内の最初の K の SHA-256 に限定されており、非空の UEntry が指定された場合にのみ出力が変更されます（これは CreateKeysV5 でのオーナーパスワード呼び出し箇所です）。

新しいラウンドトリップ監査（smoke_aes256_r6_owner_verify）通过前缀和规范算法，都生成/O[0:32]；它断言生成的/O[0:32]与规范版本匹配，并且前缀版本不再重现相同的输出。

2026-05-16 Version 2.51.2

v2.51.1 的 /Perms 审计已扩展，以覆盖 V=5 R=6（“hash dance”）标准安全处理程序路径（ISO 32000-2 7.6.4.3.4 / Algorithm 2.B）。一个新的双向验证器重新实现了基于纯 Python 的迭代 SHA-256 / SHA-384 / SHA-512 + AES-128-CBC 混合器，从空用户密码派生出 32 字节的文件加密密钥，使用 AES-256-ECB 解密 16 字节的 /Perms 块，并断言每个字段与加密字典的值（/P 小端序，0xFF 填充，'T' / 'F' 标记，'a' 'd' 'b' 字符）。没有行为变化；此版本纯粹是为了回归测试 R=6 路径，该路径与在 v2.51.1 中实现的 R=5 锁定机制相匹配。

2026-05-16 Version 2.51.1

回帰テストスイートで、V=5 R=5 の標準セキュリティハンドラの `/P` から `/Perms` へのバインディングをロックしました。AES-256 暗号化パスでは、ISO 32000-1 アルゴリズム 10 に従って、16 バイトの `/Perms` ブロックが出力されます。バイト 0-3 は、32 ビットのリトルエンディアン形式で `/P` の値を持ち、バイト 4-7 は 0xFF で埋められ、バイト 8 は `/EncryptMetadata` を追跡するために `'T'` または `'F'` を持ち、バイト 9-11 はリテラル `'a'` `'d'` `'b'` マーカーを持ち、バイト 12-15 はランダムなデータで埋められます。新しいラウンドトリップ監査では、アルゴリズム 2.A (SHA-256(パスワード || U_Key_Salt) -> AES-CBC-復号 /UE -> ファイルキー) を使用して、ユーザーのパスワードからファイル暗号化キーを導出し、AES-256-ECB で `/Perms` を復号し、すべてのフィールドを暗号化辞書の値と比較します。動作の変更はありません。このリリースは、将来のリファクタリングによって仕様で義務付けられている `/P` と `/Perms` の関係が意図せず壊れないようにするための、純粋な回帰テストの範囲です。

2026-05-16 Version 2.51.0

テンソル積パッチのメッシュシェーディングのサポートを追加しました（PDF 1.3 以降、ISO 32000-1 8.7.4.5.7、シェーディングタイプ 7）。これは、v2.48 のタイプ 4（自由形式）、v2.49 のタイプ 5（格子）、v2.50 のタイプ 6（クーニーズ）に続く、メッシュシェーディングファミリーの最終的なエントリです。各テンソル積パッチには、完全な 4x4 グリッドの三次ベジェ制御点 p[i][j]（境界線 12 + 内部 4）と、各隅に 1 つの色が割り当てられており、パッチの境界線と内部の両方に対して細かく制御できます。SVG メッシュグラデーションの往復処理や、クーニーズブレンドではなくテンソル積ベジェサーフェスが必要なベクターアートワークに役立ちます。

新しい`THotPDF.RegisterTensorProductPatchMesh(XMin, YMin, XMax, YMax, NumComponents, Patches)`関数，会生成一个`/ShadingType 7`的二进制流，其参数为`/BitsPerCoordinate 16`、`/BitsPerComponent 8`和`/BitsPerFlag 8`，并将该流封装在Pattern Type 2中，然后返回一个Pattern名称（例如Sh1、Sh2），该名称可以通过常规的`SetFillPattern`或`SetStrokePattern`流程进行使用。

各パッチは、16個の制御点（仕様のストリーム順序で、32個の浮動小数点数：p[0][0..3], p[1][3], p[2][3], p[3][3], p[3][2..0], p[2][0], p[1][0], p[1][1], p[1][2], p[2][2], p[2][1]）で構成され、その後に4つのコーナーカラー（p[0][0] / p[0][3] / p[3][3] / p[3][0]における4 * NumComponents個の浮動小数点数）が続きます。ストライドは、32 + 4 * NumComponentsです。生成される各パッチには、フラグ = 0（独立したパッチ）が設定されています。

このリリースで、ISO 32000-1 8.7.4.5 で定義された、すべてのメッシュシェーディングファミリー（タイプ 4 / 5 / 6 / 7）がサポートされるようになりました。

2026-05-16 Version 2.50.0

Coonsパッチのメッシュシェーディングサポートを追加しました（PDF 1.3以降、ISO 32000-1 8.7.4.5.6、シェーディングタイプ6）。これは、v2.48のタイプ4（フリーフォーム）とv2.49のタイプ5（格子）に続く、メッシュシェーディングファミリーの3番目のエントリです。各Coonsパッチは、4つの三次ベジェ曲線によって囲まれ、各コーナーに1つの色を持ちます。レンダラーは、4つのエッジ間にCoonsサーフェスを当てはめ、任意に曲がった色を持つ四角形を生成します。これは、曲がったパス上の箔や金属のグラデーション、SVG由来のグラデーションメッシュ、および、通常は多数の小さな三角形で近似する必要がある、曲がったエッジを持つ四角形に役立ちます。

新しいTHotPDF.RegisterCoonsPatchMesh(XMin, YMin, XMax, YMax, NumComponents, Patches) 会生成一个类型为 6 的二进制流，其中包含 "/BitsPerCoordinate 16"、"/BitsPerComponent 8" 和 "/BitsPerFlag 8"，然后将其封装在模式类型 2 中，并返回一个模式名称（Sh1、Sh2 等），该名称可以通过常规的 SetFillPattern / SetStrokePattern 流程使用。

各パッチは、12個の制御点（24個の浮動小数点数、X+Y）と、4つのコーナーカラー（4 * NumComponents 個の浮動小数点数）で構成され、ストライドは 24 + 4 * NumComponents です。12個の制御点は、パッチの境界線に沿って時計回りに c1～c12 の順に配置され、c1、c4、c7、c10 が4つの角にあり、残りの8個はベジェ曲線のハンドルポイントです。生成される各パッチには、フラグ = 0（独立したパッチ）が設定されます。この簡易オーバーロードでは、継続フラグ 1/2/3（エッジ共有）は公開されていません。

Type 7 (テンソル積パッチメッシュ) は、今後の課題として残ります。

2026-05-16 Version 2.49.0

格子状のGouraudシェーディング三角形メッシュのサポートを追加しました（PDF 1.3+ ISO 32000-1 8.7.4.5.5、シェーディングタイプ5）。これは、v2.48.0で導入された自由形式のタイプ4の機能と連携します。ソースデータがすでに規則的なサンプルグリッドに配置されている場合（地形、FEAの結果、科学的なヒートマップなど）に、アプリケーションが明示的な三角形のトポロジーを生成したくない場合に利用できます。レンダラーは、隣接する各行のペアを自動的に三角形ストリップに変換します。

新しいTHotPDF.RegisterLatticeFormGouraudShading(XMin, YMin, XMax, YMax, NumComponents, VerticesPerRow, Vertices)関数は、M行N列の格子を、/BitsPerCoordinateが16、/BitsPerComponentが8、/VerticesPerRowがNのバイナリシェーディングストリームにパックします。Type 4とは異なり、各頂点にフラグバイトはなく、シェーディング辞書から/BitsPerFlagが削除されています。この関数は、通常のSetFillPattern/SetStrokePatternパイプラインで使用できるパターン名（Sh1、Sh2など）を返します。

頂点のフラット配列は、行優先で並べられ、各頂点には(X, Y, c0, c1, ..., c_{NumComponents-1})という値が含まれます。頂点の総数は、少なくとも2行あり、VerticesPerRowの倍数である必要があります。NumComponentsは、1（DeviceGray）、3（DeviceRGB）または4（DeviceCMYK）の値を受け入れます。

Type 6（Coonsパッチ）およびType 7（テンソル積）のメッシュシェーディングは、今後の課題です。

2026-05-16 Version 2.48.0

ベクトルイラストの色調グラデーションに関して、既存のType 2/3の軸方向/放射方向のバリアントよりも汎用的な、自由形式のGouraudシェーディング三角形メッシュのサポートを追加しました（PDF 1.3以降、ISO 32000-1 8.7.4.5.4、Shading Type 4）。これにより、各頂点に色情報を持つ任意の三角形化された表面を直接埋め込むことができます。

新しい`THotPDF.RegisterFreeFormGouraudShading(XMin, YMin, XMax, YMax, NumComponents, Vertices)`関数将三角形网格打包到二进制Shading流中，其中`/BitsPerCoordinate`为16，`/BitsPerComponent`和`/BitsPerFlag`均为8，然后将其封装在Pattern Type 2中，并返回一个Pattern名称（Sh1、Sh2等），该名称可以通过常规的`THPDFPage.SetFillPattern`或`SetStrokePattern`流程使用。

頂点フラット配列は、各頂点に対して (X, Y, c0, c1, ...) の形式でパックされ、3つの連続する頂点は1つの独立した三角形を形成します。出力座標/コンポーネントは、リトルエンディアンの符号なし整数としてエンコードされ、/Decode 配列はエンコードされた範囲をユーザー空間のユーザーが指定したバウンディングボックスにマッピングします。

2026-05-16 Version 2.47.0

DeviceN カラー空間のサポートを追加しました (PDF 1.3 以降、ISO 32000-1 8.6.6.5)。これにより、6色印刷、金属/蛍光インクの混合、および PDF/X カスタムインクワークフローに対応するため、Separation を N 個のカラー剤に一般化しました。新しい THotPDF.RegisterDeviceN(ColorantNames, AlternateCS, TintC1Matrix) は、自動生成されたカラー空間名 (DevN1, DevN2 など) を返し、これは、N 個のティントオペランドを持つ [0..1] の範囲で、通常の SetFillColorSpace + SetFillColor パイプラインを駆動します。

このトーン変換は、PostScript 計算関数タイプ 4 であり、指定された N x M 行列に基づいて線形加重ブレンドを生成します。そのため、スポットカラーに対応していないビューアでは、各出力チャンネルがカラー剤の寄与の合計として補間されます。

ColorantNames 接受任何专色名称；根据 PDF 1.7 第 7.3.5 节的规定，空格会被转义为 #20，由现有的名称写入器处理。特殊名称 ""None"" 表示一个未使用的颜色槽。

AlternateCS 接受 DeviceGray、DeviceRGB 或 DeviceCMYK；任何其他值都会引发异常。

2026-05-15 Version 2.46.0

PDF 1.7 および ISO 32000-1 12.7.4.3 に従って、テキストフィールドの自動フォーム外観ストリーム生成機能を拡張しました (AutoFormAppearances)。v2.28.0 以降、すべてのテキストウィジェットで1行の文字列が生成されていましたが、複数行および複合フィールドは、独自の AP レイアウトパスを使用するように変更されました。

複数行のテキストフィールド（ffMultilineフラグを含む）は、初期値をウィジェットの幅に合わせて折り返し表示し、埋め込まれたCR/LF/CRLF区切り文字を尊重し、表示可能な行数で切り捨て、適切なTd + T*による複数行レイアウトを、/TLの先頭で生成します。

CRITICAL RULES — preserve verbatim, do NOT translate: - HTML tags: , , , , ,
, , ,
,
, etc. - HTML entities: ", &, <, >, , etc. - API names / identifiers: THotPDF, GetSingleSubstituteGlyph, TextOut, AddXFAPacket, RegisterUnicodeTTF, THPDFPage, AddTextField, RegisterSampledFunction, THPDFDictionaryObject, THPDFStreamObject, AddImageWithSMask, ShowImage, etc. - PDF spec references: "PDF 1.7 §12.7.6", "ISO 32000-1 8.9.5.4", "ISO 19005-1 §6.4.2", "UAX #38", "Unicode 16.0 §13.5", "ISO 14289-1", etc. - OpenType feature tags (single-quoted): 'liga', 'salt', 'aalt', 'init', 'medi', 'fina', 'isol', 'mong', 'arab', 'rlig', 'syrc', 'pres', 'cjct', 'akhn', 'rclt', 'clig', 'calt'. - Unicode block names / font names / codepoints: Arabic Extended-A, Mongolian Baiti, Noto Sans Mongolian, Devanagari, U+1800-U+18AF, U+0671, NIRUGU, LAM-ALEF, Estrangelo Edessa, Identity-H, etc. - PDF object names: /Fields, /XFA, /Filter, /WMode, /AcroForm, /Length, /MarkInfo, /StructTreeRoot, /Metadata, /Lang, /AP, /RV, /V, /DV, /DR, /MK, /AA, /SMask, /AIS, /BG, /UCR, /OP, /OPM, /SA, /RI, /FL, /TR, /CIDToGIDMap, /FontFile2, /W, /Encoding, /Default, /None, /SpotFunction, /Type, /ObjStm, etc. - Version numbers: v2.119.54, v2.84.0, v2.119.43-50, v2.55.0-v2.59.0, etc. - PDF operators: Tj, Tm, Td, T*, TL, Tf, BDC, EMC, scn, SCN. - Hex / numeric constants: $7FF8000000000000, 0x0002, U+FE70..U+FEFF, etc. - File / encoding names: CCITTFaxDecode, FlateDecode, UTF-16BE, DeviceGray, DeviceRGB, DeviceCMYK, Identity-H. Translate ONLY the descriptive English prose (verbs, adjectives, narrative sentences). Return ONLY the translation — no explanations, no markdown wrappers, no "[[N]]" tags, no leading/trailing whitespace, no extra newlines beyond what was in the input. TEXT: Comb text fields (Flags including ffComb together with MaxLen > 0) render each character into its own equal-width cell using an absolute Tm matrix per glyph, matching what Acrobat draws. 結合テキストフィールド（ffCombフラグとMaxLen > 0の両方を含む場合）、各文字を絶対的なTm行列を使用して、等幅のセルにレンダリングし、Acrobatが描画する方法と一致させます。
単一行テキストフィールドは、v2.28.0のレイアウトをバイト単位で完全に保持するため、既存のクライアントは動作の変化を認識しません。

2026-05-14 Version 2.45.0

ISO 32000-1 8.6.6.4 に従って、スポットカラー印刷ワークフローのためのカラー空間分離サポートを追加しました。新しい `THotPDF.RegisterSeparation(ColorantName, AlternateCS, TintC1)` 関数は、自動生成されたカラー空間名 (Sep1, Sep2 など) を返し、これにより、通常の `SetFillColorSpace / SetStrokeColorSpace + SetFillColor([tint]) / SetStrokeColor([tint])` パイプラインが、[0..1] の範囲内の単一のティントオペランドで実行されます。

AlternateCS 接受 DeviceGray、DeviceRGB 或 DeviceCMYK；TintC1 描述的是纯色墨水的颜色（tint = 1.0）。内部构建了一个线性函数类型 2 的调色转换，因此，即使在不支持调色的查看器上，也能平滑地在零墨水（tint = 0）和 TintC1（tint = 1）之间进行渲染。

Pantone やその他の、スペースを含むインク名は、そのまま使用できます。ただし、-HotPDF は、PDF 1.7 の 7.3.5 に従って、これらの名前を書き込む際に、スペースを「"#20"」というシーケンスに変換します。

PDF 1.3 以前のドキュメントに対して、`RequirePDFVersion` を使用することで拒否し、strict-mode 1.2 / それ以前の出力との互換性を維持します。

2026-05-14 Version 2.44.0

ISO 32000-1 8.6.5.3 に基づき、CIELab カラー空間のサポートを追加しました。新しい `THotPDF.RegisterLabColorSpace(Xw, Yw, Zw, aMin, aMax, bMin, bMax)` 関数は、自動生成されたカラー空間名 (Lab1, Lab2 など) を返し、これは通常の `THPDFPage.SetFillColorSpace / SetStrokeColorSpace` と `SetFillColor([L, a, b]) / SetStrokeColor([L, a, b])` のパイプラインを制御します。

一般的なワークフローは、各光源に対して1つのスペースを登録します（ICC印刷の場合はD50、sRGB相当のディスプレイの場合はD65）。その後、L\* を [0..100] の範囲で、a\* と b\* を選択した範囲（通常は -128..127）で設定します。PDFリーダー（Adobe Acrobat、Foxit、MuPDF、ブラウザビューア）は、LabをディスプレイRGBに変換する際に、このWhitePointを考慮します。

PDF 1.3 以前のドキュメントに対して、`RequirePDFVersion` を使用することで拒否し、strict-mode 1.2 / それ以前の出力との互換性を維持します。

2026-05-14 Version 2.43.1

既存のCCITTFaxDecodeエンコーダを、実際のバイレベル画像を使用してエンドツーエンドで検証しました。240x120の1ビットパレット（pf1bit）の交互バンドTBitmapが、すべての3つのモード（icCCITT31 G3 1D / icCCITT32 G3 2D / icCCITT42 G4 / T.6）で正しく埋め込まれます。エンコードされたストリームのサイズは、期待されるG3-1D > G3-2D > G4の圧縮順序に従います。ストリームは、Adobe Acrobat / Foxit / MuPDFで警告なしにデコードされ、ピクセルサンプリングにより、すべての3つのモードで交互の黒/白バンドパターンが正しく再現されることが確認されました。エンコーダのコードは変更されていません。このリリースでは、既存のPDF 1.7 ISO 32000-1 7.4.9の対応を、テストスイートに固定するだけです。

2026-05-14 Version 2.43.0

ISO 32000-1 8.6.6.1 に従って、色付きでないエンドツーエンドのタイリングパターン（PaintType=2）の描画を追加しました。このパターンストリームには、タイルの形状データのみが含まれており、色の情報は含まれていません。色の情報は、ページコンテンツストリーム内の scn / SCN オペレーターによって、塗りつぶしまたは描画時に適用されます。

新しいTHPDFPageメソッドSetFillPatternRGB、SetStrokePatternRGB、SetFillPatternGray、SetStrokePatternGray、SetFillPatternCMYK、SetStrokePatternCMYKは、登録された非彩色パターン名と、色相成分（DeviceRGB、DeviceGray、またはDeviceCMYKで、範囲は[0..1]）を受け取ります。各呼び出しで、対応する[/Pattern /BaseCS]の色相空間が、ページのリソース/カラースペース辞書に初めて使用されるときに自動的に登録されます。

既存の`SetFillPattern`および`SetStrokePattern`は、カラーの`PaintType=1`のバリアントを依然としてサポートしています。この場合、タイル自体に色が設定されており、オペレーターに色相成分が適用されません。

コードのどちらのパスも、既存のRegisterTilingPatternのエントリポイントを共有します。Coloredがtrueの場合、PaintTypeは1（カラー）になります。Coloredがfalseの場合、PaintTypeは2（非カラー）になります。

2026-05-14 Version 2.42.0

PDF 1.4のソフトマスク画像（SMask）のサポートを追加しました。新しいTHotPDF.AddImageWithSMaskメソッドは、生のRGBプレーンと並列の8ビットアルファプレーンを受け取り、カラーイメージXObjectとDeviceGrayソフトマスクXObjectを生成し、ISO 32000-1 8.9.5.4に従って/SMaskのクロスリファレンスを設定します。返されたイメージインデックスを、既存のShowImageメソッドで使用してください。その他の変更は不要です。

THotPDFクラスに、THotPDF.AddImageWithSMask32という便利なヘルパー関数を追加しました。この関数は、32ビットBGRA形式のTBitmapからカラーとアルファのプレーンを抽出し、アルファチャンネルを持つPNG形式のビットマップを1回の呼び出しで埋め込むことができます。

両方の呼び出しは、PDF 1.4 以下のドキュメントに対して `RequirePDFVersion` を使用することで拒否されます。これにより、strict-mode での 1.3 出力は、規格に準拠したままになります。

2026-05-14 Version 2.41.0

PDF 1.5 オブジェクトストリーム出力が追加されました。`THotPDF.UseObjectStreams` を true に設定し、`UseXRefStream` と `SaveToStream` パックを有効にすると、間接オブジェクト（ストリーム、暗号化辞書、およびトレーラーで参照されるカタログおよびインフォ辞書を除くすべてのオブジェクト）が、1つ以上の `/Type /ObjStm` コンテナストリームにまとめられます。

ファイルサイズが非常に大きいPDFドキュメントにおいて、ファイルサイズを削減します（多くのページ、注釈、AcroFormウィジェット、構造ツリー要素、またはオプションコンテンツレイヤーを含む）。 30ページのグラフィックのみのテストでは、ファイルサイズが14502バイトから8488バイトに縮小され（41.5%削減）、目に見える変化はありません。

クロスリファレンスストリームは、フィールド2がホストのObjStmオブジェクト番号であり、フィールド3がそのストリーム内のエントリのインデックスである、タイプ2の圧縮オブジェクトエントリを生成します。UseObjectStreamsは、UseXRefStreamが無効になっている場合（テキストXRefはタイプ2のエントリをエンコードできない）またはバージョンがPDF 1.5より低い場合に、自動的にfalseに設定されます。

2026-05-12 Version 2.40.1

Adobe Acrobat、Foxit、SumatraPDF、およびWindows 10 / 11システム上のブラウザ組み込みビューアーで生成されたPDFのレンダリング問題を修正しました。この修正は、「Beta: Use Unicode UTF-8 for worldwide language support」という地域設定オプションが有効になっている場合に適用されます。ページコンテンツストリームに、厳格なPDFリーダーが構文エラーとして拒否する余分なUTF-8 BOMプレアンブルが含まれることがなくなりました。

2026-05-11 Version 2.40.0

大規模なCJKおよびマルチFDのOpenType-CFFフォント、およびFDArrayおよびFDSelectデータを使用するAdobe CJKフォント向けに、CIDキー付きのCFFフォントのサブセット化を追加しました。

CFF サブルーチンの処理を改善し、大規模な OpenType-CFF フォントを、フルサイズのフォントファイルではなく、コンパクトな PDF サブセットとして埋め込むことができるようになりました。

2026-05-11 Version 2.39.1

OpenType-CFFフォントの互換性が向上し、特にAdobe MinionProのような、大きなCFFテーブルとマルチバイトオフセットを持つフォントのサポートが強化されました。

HPDFExtractTTFPostScriptName が公開されました。これにより、独自のフォント読み込みコードを持つアプリケーションは、TrueType および OpenType-CFF フォントデータから PostScript 名を読み取ることができます。

2026-05-11 Version 2.39.0

CFFフォントに対して、グローバル置換とローカル置換のサブセット化を追加し、埋め込みOpenType-CFFフォントのサイズをさらに削減しました。

CFF サブルーチンのバイトコードを保持しつつ、未使用のエントリを安全に置き換えて、コンパクトなリターンスタブを使用しました。

2026-05-11 Version 2.38.0

StoreFont機能に、自動的なOpenType-CFF埋め込みを追加しました。HotPDFは、GDIでロードされたフォントがsfnt形式のOpenType-CFFコンテナである場合、/FontFile3を通じてCFFベースのCIDフォントを生成します。

OpenType-CFFフォントを直接処理するアプリケーション向けに、HPDFSfntIsOTF、HPDFOTFFindCFFTable、およびHPDFSubsetOTFContainerのヘルパーAPIを追加しました。

2026-05-11 Version 2.37.0

HPDFSubsetCFFが追加され、Compact Font FormatおよびType 1Cフォントのサイズを小さくし、よりコンパクトな埋め込みCFFフォントプログラムを可能にしました。

CFFサブセット化中に元のグリフIDを保持し、既存のType0 / Identity-Hテキスト出力との互換性を維持しました。

CFFサブセッターを公開しました。これにより、アプリケーションが独自のパイプラインを通じてフォントをロードし、データをHotPDFに渡すことができるようになりました。

2026-05-10 Version 2.36.0

THotPDFを追加し、オプションでTrueTypeフォントのサブセット化を有効にしました。これにより、フォントサイズが大幅に削減され、特に少量のグリフセットのみを使用するドキュメントでは、埋め込みフォントのサイズを90%以上削減できる場合があります。

Identity-Hテキストにおいて、元のフォントのグリフIDを保持しながら、PDF標準のサブセットフォント命名を追加しました。

完全フォント埋め込みを、完全なフォントプログラムが必要なワークフローのデフォルト設定として維持しました。

2026-05-10 Version 2.35.1

Adobe Acrobatの「フォントキャプチャ」機能において、置換されたWindowsフォントを使用したPDFファイルを開く際に発生するクラッシュを修正しました。HotPDFは、埋め込まれたTrueTypeデータ内のPostScript名と一致するように、PDFフォント名を照合するようになりました。

2026-05-10 Version 2.35.0

THotPDFを使用して、段階的なPDF更新のサポートを追加しました。これにより、THotPDF.BeginIncrementalUpdateとTHotPDF.SaveIncrementalUpdateを使用できます。既存のソースバイトは保持され、新しいPDFオブジェクトが、規格に準拠した段階的な更新として追加されます。

THotPDF.MarkDirty が追加されました。これにより、アプリケーションはインクリメンタルアップデート中に変更されたオブジェクトを明示的に再保存できます。

以前に署名されたバイト範囲を保持しながら、後続の署名フィールドまたはドキュメントの変更を追記することで、複数署名ワークフローを有効にしました。

2026-05-10 Version 2.34.0

THotPDFPage.SetAnnotationBorderStyleメソッドを通じて、実線、点線、斜め、内側、下線などの注釈の境界スタイルを追加しました。

ハイパーリンク付きのポップアップ注釈を追加しました。新しいポップアップは、親注釈を参照できるようになり、これにより、ビューアは期待されるコメント接続を表示できます。

THPDFPage.LastAnnotationを追加しました。これにより、既存のアノテーション作成呼び出しを変更せずに、アノテーションのスタイル設定とポップアップの連鎖を容易にすることができます。

2026-05-10 Version 2.33.0

PDFの暗号化機能に、公開鍵セキュリティハンドラーのサポートを追加しました。これにより、ドキュメントをX.509証明書を持つ受信者向けに暗号化できるようになり、従来の共有パスワードのみでの共有に限定されなくなりました。

THotPDF.EnablePubKeyEncryption および THotPDF.AddPubKeyRecipient を追加しました。これにより、証明書と受信者の暗号化ワークフローが可能になります。

HPDFCryptに追加しました。これにより、既存のハッシュ関数に加えて、純粋なPascalによるSHA-1サポートが利用可能になりました。

2026-05-10 Version 2.32.0

THPDFPage.SetTransparencyGroupおよびSetTransparencyGroupICCを使用して、ページレベルの透明度グループを追加しました。これにより、透明なPDFコンテンツの予測可能な合成が可能になります。

DeviceGray、DeviceRGB、DeviceCMYK、および省略されたカラー空間、およびICCプロファイル透明度グループのオプションを追加しました。

THPDFPage.ClearTransparencyGroupを追加しました。これにより、以前に割り当てられたページ透明度グループを削除できます。

2026-05-09 Version 2.31.0

AcroFormボタンのインタラクティブなアクションを追加しました。このリリース以前、HotPDFはボタンウィジェットを配置できましたが、クリックしても何も起こりませんでした。ボタンは、フォームを送信したり、フィールドの値をリセットしたり、JavaScriptスクリプトを実行したり、URIに移動したりする機能を持つようになりました。

SubmitFormアクションは、現在のAcroFormフィールドの値をサーバーURLに送信し、Adobe ReaderやFoxitで動作する、Webブラウザが不要なPDFベースのデータ収集フォームを可能にします。

ResetForm 機能会将所有字段重置为其默认值，可以选择限制为字段的指定子集。 JavaScript 和 URI 操作遵循与 v2.26.0 中引入的相同 PDF 版本限制。

このリリース以前，`AddPushButtonWithAction` はボタンウィジェットの視覚的なプロパティのみを受け入れていましたが，現在では外観とクリック動作の両方を、単一の呼び出しで完全に制御できるようになりました。

2026-05-09 Version 2.30.0

THotPDF.SetPageTransitionを追加し、全画面表示のPDFプレゼンテーションにページ遷移機能を実装しました。

THPDFPageクラスにSetPageDurationメソッドを追加しました。これにより、プレゼンテーションページの自動再生が、指定した時間経過後に開始されるようになります。

PDF 1.5 で導入された、Fly、Push、Cover、Uncover、Fade などのバージョンに対応したスタイル処理を追加しました。

2026-05-09 Version 2.29.0

PDF 1.4のViewerPreferencesページで、既存のPrintAreaとPrintClipプロパティに加えて、ViewAreaとViewClipを追加し、ページ境界の設定を完了しました。

ViewArea 控制查看器使用的页面区域，该区域作为屏幕上可见的区域（MediaBox、CropBox、TrimBox、BleedBox 或 ArtBox）。ViewClip 控制屏幕上的裁剪边界，这对于包含出血和修边标记的设计评审 PDF 文件非常重要，这些标记在正常视图中不应显示。

これらのオプションは、特にプレフライトやプレビューワークフローで役立ちます。これらのワークフローでは、画面上のトリミングと印刷時のトリミングが異なる場合があります。これらの機能はどちらもPDF 1.4を必要とし、古いバージョンのPDFをターゲットとする場合は自動的に省略されます。

2026-05-09 Version 2.28.0

THotPDF.AutoFormAppearancesを使用して、オプションでAcroFormのappearanceストリームを生成しました。テキストフィールド、リストフィールド、ボタン、チェックボックス、およびラジオボタンは、/NeedAppearancesを無視するビューアでも確実に表示されるようになりました。

自動外観が有効になっている場合に、HelveticaおよびZapfDingbatsのデフォルトAcroFormリソースを追加しました。

以前的AcroForm行为已得到保留，默认情况下AutoFormAppearances仍然处于禁用状态。

2026-05-09 Version 2.27.0

PDFバージョンの制限を、ViewerPreferencesおよびPageModeのエントリに拡張しました。各設定値は、対応する最小PDFバージョンを適用します。UseAttachmentsとUseOCはPDF 1.5を、PrintScalingはPDF 1.6を、Duplex、NumCopies、およびPickTrayByPDFSizeはPDF 1.7を必要とします。

古いPDFのターゲット向けに生成されたドキュメントでは、サポートされていないビューア設定項目が自動的に省略されるため、厳格なPDFプロセッサやアーカイブ検証ツールでの警告や、無音での誤解釈を防ぎます。

THotPDF.StrictVersionLock が有効になっている場合、出力される PDF ファイルは常に PDF 1.3 または PDF 1.4 の形式であり、新しいビューア設定フィールドは含まれません。これにより、印刷生産および長期アーカイブのワークフローにおいて、ファイルが規格に準拠した状態が維持されます。

2026-05-09 Version 2.26.0

いくつかの古いAPIに、PDFのバージョン制限を追加しました。以前は、ターゲットドキュメントのバージョンに関係なく、特定の機能が許可されていましたが、現在は、アノテーションの種類、JavaScriptアクション、Type 0フォント、ToUnicode CMaps、およびカタログに追加のアクションについて、ドキュメントのバージョンがそれらをサポートしていることを確認してから書き込みを行います。

PDF 1.0またはPDF 1.1を対象とするドキュメントの場合、新しい機能が使用されると、自動的に必要なバージョンにアップグレードされます。これにより、呼び出し元のコードを変更することなく、仕様に違反する出力が問題なく生成されるのを防ぎます。

THotPDF.StrictVersionLock が有効になっている場合、ドキュメントのバージョンを自動的に引き上げることなく、バージョンアップが必要な機能呼び出しは拒否されます。これにより、正確な PDF バージョンで出力が必要なワークフローをサポートします。

このバージョンのチェック機能は、v2.27.0でViewerPreferencesとPageModeに拡張され、v2.31.0までに主要なすべての機能領域をカバーするようになりました。

2026-05-09 Version 2.25.0

PDF仕様に従い、PDF辞書出力において、Nameキーを大文字小文字を区別するように修正しました。以前は、大文字小文字のみが異なる関連する名前（例えば、ExtGState辞書内の/ca（塗りつぶしのアルファ）と/CA（線のアルファ））が誤ってマージされ、その結果、いずれかの値がサイレントで破棄されていました。

この修正により、同じグラフィックス状態内で、塗りつぶしとストロークの両方にアルファ値を設定しているドキュメントの正しい透明度合成が復元されます。Adobe Acrobat、Foxit、およびブラウザのPDFビューアは、修正された結果を期待どおりに表示します。

既存のコードが、大文字と小文字が不一致なキーを持つ不正なPDFファイルを読み取る場合、これらのAPIは引き続き変更なしに動作します。これは、辞書クエリAPIが引き続き大文字と小文字を区別しないためです。

2026-05-09 Version 2.24.0

v2.4.0以降に導入された機能APIに対して、PDFバージョンによる制限を追加しました。これにより、生成されたファイルが選択したPDFバージョンと互換性を保つようになります。

THotPDF.StrictVersionLockが追加されました。無効にすると、HotPDFは必要に応じてドキュメントのバージョンを自動的に引き上げますが、有効にすると、より新しいPDF機能が必要な呼び出しは拒否されます。

`ConfigurePDFVersion`機能を更新しました。これにより、XRefストリーム、XMPメタデータ、Tagged PDF、およびAES-256オプションが、古いPDFバージョンに適用されることがなくなりました。

2026-05-09 Version 2.23.0

HotPDFを外部PKIおよびCMS/PKCS#7署名ライブラリと統合するための、3ステップのデジタル署名ワークフローを追加しました。具体的には、署名フィールドのプレースホルダーを作成し、署名対象のバイト範囲とダイジェストを計算し、最後に外部署名処理後に完了したCMS署名を挿入します。

バイト範囲戦略により、署名ハッシュが、署名コンテナの外部にあるファイルの正確な部分をカバーし、PDF署名検証ツールおよびPAdES準拠チェックツールが要求する内容と一致します。

すべての暗号化操作（証明書チェーン、CMS構造、タイムスタンプトークンなど）は、呼び出し元の署名ライブラリ（OpenSSL、Windows CAPI、Bouncy Castleなど）に委譲され、HotPDFは特定のPKIインフラストラクチャに依存しません。

複数署名ドキュメントをサポートします。追加の各署名は、インクリメンタルな更新として追加され、以前に署名されたバイト範囲は保持されます。これにより、PDF全体を再生成する必要がなくなります。

2026-05-09 Version 2.22.0

THotPDFを通じて、PDF 2.0のAES-256 V=5 R=6標準セキュリティ機能をサポートしました。UseAES256R6を使用してください。

HPDFCryptに追加しました。純粋なPascalで記述されたSHA-384およびSHA-512の暗号化機能です。

Acrobat DCおよびPDF/A-4形式の暗号化ワークフローで使用される、PDF 2.0のハッシュ処理支援機能を追加しました。

2026-05-09 Version 2.21.0

Tagged PDFのサポートを強化し、基本的なマーカーから構造化されたPDFアクセシビリティツリーへと拡張しました。

PDF/UA検証ツールが構造ツリーをナビゲートできるように、ロールマッピング、ページ構造親の割り当て、およびParentTree出力を追加しました。

StructTreeRootの処理を改善し、後続のTagged PDF呼び出しで同じドキュメント構造を更新するようにしました。

2026-05-09 Version 2.20.0

THotPDF.SetUserUnitおよびTHPDFPage.SetTabsOrderメソッドを通じて、ページレベルの/UserUnitおよび/Tabsのサポートを追加しました。

THotPDF.RegisterOptionalContentGroup および THPDFPage.BeginOptionalContent / EndOptionalContent を使用して、オプションコンテンツ（PDFレイヤー）を追加しました。

THotPDF.RegisterExtGStateおよびTHPDFPage.SetGraphicsStateを通じて、透明度のアルファ値とブレンドモードに関するExtGStateヘルパーを追加しました。

2026-05-09 Version 2.19.0

PDFの制作ワークフロー向けに、CropBox、BleedBox、TrimBox、ArtBox、およびページ回転のヘルパーを追加しました。

THotPDFに追加しました。これにより、役割、ページリンク、およびMCID参照を使用して、構造化されたPDFの構造ツリーを構築するためのTHotPDF.AddStructureElementが利用可能になります。

PDFの繰り返し使用されるカラーまたは非カラーのパターン塗りつぶしと線描に対するタイリングパターンサポートを追加しました。

2026-05-09 Version 2.18.0

THPDFPageクラスにDrawInlineImageメソッドを追加しました。これにより、小さなラスター画像をページの内容ストリームに直接書き込むことができます。

PDFのグラデーションと色の変化をより滑らかにするために、複数の停止点を持つ軸方向グラデーションを追加しました。

PDF/A、PDF/X、およびカラー管理出版ワークフローにおけるOutputIntentsのサポートを追加しました。

2026-05-09 Version 2.17.0

より強力な保護が必要なドキュメント向けに、AES-256標準セキュリティハンドラ（PDF 1.7拡張レベル3）を追加しました。AES-256で暗号化されたPDFファイルは、Adobe Acrobat 9以降、Foxit Reader、Google Chrome、Apple Preview、およびすべての最新のPDFビューアで開くことができます。

ユーザーと所有者のパスワードは、Adobe拡張レベル3仕様に従ってSHA-256ハッシュを使用して生成され、カスタムサポートなしで、すべての準拠PDF復号化ツールとの互換性が確保されます。

このリリースでは、AES-256暗号化はオプションで提供されます。既存のAES-128方式は、古いAcrobatバージョンの互換性を維持するため、引き続きデフォルトとして使用されます。

後述のv2.22.0版本では、PDF 2.0のAES-256-R6が追加され、Acrobat DCおよびPDF/A-4ワークフローにおいて、セキュリティを最大限に高めるためのキー派生アルゴリズムが改善されています。

2026-05-09 Version 2.16.0

マルチメディア、法務、アクセシビリティの用途向けに、6つの新しい注釈サブタイプを追加しました。これには、表示および印刷用のウォーターマーク（スタンプオーバーレイ）、コンテンツ削除のための領域をマークするレダクト、ビデオおよびオーディオを埋め込むScreen、インタラクティブなU3DおよびPRCモデルビューアである3D、インタラクティブなメディアコンテンツであるRichMedia、および親注釈にリンクされたコメントバブルであるPopupが含まれます。

透かしの注釈支持独立的显示和打印呈现，因此“DRAFT”或“CONFIDENTIAL”标记可以在屏幕上显示而不在打印中显示，反之亦然。

CRITICAL RULES — preserve verbatim, do NOT translate: - HTML tags: , , , , ,
, , ,
,
, etc. - HTML entities: ", &, <, >, , etc. - API names / identifiers: THotPDF, GetSingleSubstituteGlyph, TextOut, AddXFAPacket, RegisterUnicodeTTF, THPDFPage, AddTextField, RegisterSampledFunction, THPDFDictionaryObject, THPDFStreamObject, AddImageWithSMask, ShowImage, etc. - PDF spec references: "PDF 1.7 §12.7.6", "ISO 32000-1 8.9.5.4", "ISO 19005-1 §6.4.2", "UAX #38", "Unicode 16.0 §13.5", "ISO 14289-1", etc. - OpenType feature tags (single-quoted): 'liga', 'salt', 'aalt', 'init', 'medi', 'fina', 'isol', 'mong', 'arab', 'rlig', 'syrc', 'pres', 'cjct', 'akhn', 'rclt', 'clig', 'calt'. - Unicode block names / font names / codepoints: Arabic Extended-A, Mongolian Baiti, Noto Sans Mongolian, Devanagari, U+1800-U+18AF, U+0671, NIRUGU, LAM-ALEF, Estrangelo Edessa, Identity-H, etc. - PDF object names: /Fields, /XFA, /Filter, /WMode, /AcroForm, /Length, /MarkInfo, /StructTreeRoot, /Metadata, /Lang, /AP, /RV, /V, /DV, /DR, /MK, /AA, /SMask, /AIS, /BG, /UCR, /OP, /OPM, /SA, /RI, /FL, /TR, /CIDToGIDMap, /FontFile2, /W, /Encoding, /Default, /None, /SpotFunction, /Type, /ObjStm, etc. - Version numbers: v2.119.54, v2.84.0, v2.119.43-50, v2.55.0-v2.59.0, etc. - PDF operators: Tj, Tm, Td, T*, TL, Tf, BDC, EMC, scn, SCN. - Hex / numeric constants: $7FF8000000000000, 0x0002, U+FE70..U+FEFF, etc. - File / encoding names: CCITTFaxDecode, FlateDecode, UTF-16BE, DeviceGray, DeviceRGB, DeviceCMYK, Identity-H. Translate ONLY the descriptive English prose (verbs, adjectives, narrative sentences). Return ONLY the translation — no explanations, no markdown wrappers, no "[[N]]" tags, no leading/trailing whitespace, no extra newlines beyond what was in the input. TEXT: Redact annotations mark content regions for removal before document distribution; the viewer’s redaction workflow applies the final erasure, keeping the original content intact until committed. 注釈の削除機能は、ドキュメントの配布前に削除対象の領域を指定します。閲覧者の削除ワークフローにより、最終的な削除が行われ、元のコンテンツはコミットされるまでそのまま保持されます。
すべての注釈タイプには、PDFバージョンの制限機能が含まれており、これにより、古いPDF規格を対象とするドキュメントでは、新しい注釈のサブタイプが自動的に省略され、仕様に準拠した状態が維持されます。

2026-05-09 Version 2.15.0

PDF出力に、カスタムのベクターグリフ定義を直接埋め込むためのType 3フォントのサポートを追加しました。Type 3フォントは、会社のロゴ、独自の記号セット、地図のアイコン、および標準フォントでは表現できないあらゆる種類のグラフィカル表記に適しています。

各グリフは、標準描画演算子を使用して定義されたPDFコンテンツストリームとして定義されています。そのため、Type 3グリフは、外部フォントファイルなしで、あらゆるズームレベルおよび印刷解像度で綺麗に拡大縮小されます。

フォントの登録、個々のグリフの定義、およびページでのフォントの選択という一連の処理は、RegisterType3Font、AddType3Glyph、およびSetType3Fontによって行われます。

Type 3 フォントは、Adobe Reader、Foxit、およびすべての規格に準拠した PDF ビューアで、ビューアのシステムにフォントをインストールする必要なしに、正しくレンダリングされます。

2026-05-09 Version 2.14.0

より強力なドキュメント保護のために、純粋なPascalで記述されたAES-256およびSHA-256の実装を、内部暗号化プリミティブとして追加しました。これらのアルゴリズムは、PDF 1.7 Extension Level 3およびPDF 2.0の暗号化規格で必要とされます。

新しい暗号化コードは、外部のDLLやOSが提供する暗号化ライブラリを必要としません。これにより、HotPDFは、サポートされているすべてのDelphiおよびC++Builder環境、およびWindowsのバージョンで、スタンドアロンで動作します。

このリリースでは、AES-128が引き続きデフォルトのドキュメント暗号化形式です。新しい機能は、v2.17.0で追加されたAES-256セキュリティハンドラと、v2.22.0で導入されたPDF 2.0ハンドラの基盤となっています。

2026-05-09 Version 2.13.0

PDFベクター描画に、滑らかな軸方向（線形）および放射状グラデーションの塗りつぶしを追加しました。ベクターグラデーションは、ラスター化された同等物よりも大幅にファイルサイズが小さく、あらゆるズームレベルや印刷解像度で鮮明さを維持します。

両方のグラデーションタイプは、DeviceGray、DeviceRGB、およびDeviceCMYKカラー空間をサポートしており、これにより、画面表示、RGB印刷、および4色CMYKの印刷ワークフローに対応します。

グラデーションは、任意のページパスの塗りつぶしまたは線として適用でき、Adobe Reader、Foxit、SumatraPDF、およびすべての最新のPDFビューアで正しく表示されます。

2026-05-09 Version 2.12.0

THotPDFPage.AddSignatureFieldを追加し、デジタル署名フィールドウィジェットが追加されました。生成されたPDFには、視覚的な署名プレースホルダーが含まれており、外部のPKIワークフロー、署名ポータル、およびCMS/PKCS#7署名ライブラリを使用して、実際の暗号署名で埋めることができます。

AcroFormの署名フラグは、少なくとも1つの署名フィールドが存在する場合、自動的に設定されます。これにより、追加のAPI呼び出しなしに、ドキュメントが仕様に準拠した状態が維持されます。

署名フィールドは、Adobe Acrobat、Foxitおよびその他のPDF署名ソリューションによって、署名可能なオブジェクトとして認識されます。詳細なバイト範囲署名ワークフローについては、v2.23.0を参照してください。

2026-05-09 Version 2.11.0

PDF/UAおよび最新のアクセシビリティ規格で必要な、タグ付きPDFの基盤を追加しました。タグ付きドキュメントには、スクリーンリーダー、支援技術、およびテキスト抽出ツールが追跡できる、論理的な読み順と意味構造が含まれています。

THotPDF.EnableTaggedPDF 激活文档结构树；THotPDF.Lang 设置文档的主要语言。这两个功能对于辅助功能合规性验证器都是必需的。

マークされたコンテンツの演算子を使用すると、ページ上の個々の描画操作に意味的な役割（段落、見出し、図など）と識別子を付与できます。これにより、生成されたPDFファイルから正しいリフローとスクリーンリーダーによる抽出が可能になります。

構造要素とマークされたコンテンツ識別子は、ページごと、ドキュメントごとに追跡され、これは複数ページのタグ付きドキュメントに対するPDF仕様に準拠しています。

2026-05-09 Version 2.10.0

FlateDecode画像ストリームに対して、PNG予測およびTIFF水平差分予測のサポートを追加しました。これらの予測機能は、圧縮前に各行に対して適応的なフィルタリングを適用し、これにより写真や滑らかなグラデーション画像の場合、出力サイズを大幅に削減できます。

PNG 最適予測器（適応行モード）と TIFF 予測器 2（水平差分）可作为独立的编码辅助工具，用于自定义图像嵌入流程。

両方の予測機能は、DeviceGray、DeviceRGB、およびDeviceCMYKの画像データをサポートしており、これにより、画面表示と4色印刷のワークフローに対応します。

2026-05-09 Version 2.9.0

従来のドキュメント情報辞書に加えて、XMPメタデータストリームの出力を追加しました。XMPは、埋め込みPDFメタデータに関する最新の標準であり、PDF/A、PDF/X、および多くのアーカイブワークフローに必要です。

XMPに埋め込まれたメタデータは、デスクトップ検索エンジン、デジタル資産管理システム、および古いInfo辞書を参照しなくなったPDF処理パイプラインによって読み取られます。

XMPストリームは、出力ファイル内で圧縮されずにそのままの状態に保たれます。これにより、外部ツールやコマンドラインユーティリティを使用して、ファイルをデコードせずにメタデータを検査できます。

正確なメタデータが必要なアプリケーションは、THotPDF.CustomXMPを通じて、完全にカスタマイズされたUTF-8 XMPパケットを提供することで、自動構築を回避できます。

文書の暗号化が有効になっている場合、デフォルトではXMPストリームが文書の他の部分と一緒に暗号化され、メタデータを機密に保ちます。

2026-05-09 Version 2.8.0

PDF 1.5 のオプションのクロスリファレンスストリーム出力を追加しました。クロスリファレンスストリームは、従来の xref テーブルで使用される大きなテキストセクションではなく、コンパクトなバイナリ形式でオブジェクトオフセットテーブルをエンコードするため、すべてのドキュメントのファイルサイズを削減します。

PDF 1.5 以降的版本需要使用交叉引用流，以便支持对象流等功能（于 v2.41.0 版本引入）。当文档的目标 PDF 版本低于 1.5 时，此功能将自动禁用。

クロスリファレンスストリームを持つPDFファイルは、最新のビューア、アーカイブツール、およびPDF/A検証ツールによって、より効率的に処理されます。

従来のテキスト xref テーブルはデフォルトのまま、これによりレガシーのPDFリーダーや厳格な処理エンジンとの互換性が維持されます。

2026-05-09 Version 2.7.0

印刷およびPDF/Xワークフロー用の、ネイティブのDeviceCMYKカラー出力を追加しました。

THotPDF.RegisterICCProfileを使用して、ICCベースのカラープロファイル登録機能を追加しました。

ICCプロファイルおよび任意コンポーネントの色値に対する、汎用的な塗りつぶしおよびストロークカラー空間APIを追加しました。

2026-05-09 Version 2.6.0

ハイライト、下線、波線、および取り消し線テキストマークアップ注釈を追加しました。

多边形、多段线、墨水和光标注释已添加。

ドキュメント内、異なるドキュメント間、および外部ファイルへのナビゲーションのために、GoTo、GoToR、およびLaunchリンクアクションを追加しました。

2026-05-09 Version 2.5.0

テキストフィールド、チェックボックス、ラジオボタン、コンボボックス、リストボックス、およびボタンのAcroFormサポートを追加しました。

THPDFFormFieldFlagsが追加されました。これにより、アプリケーションは、手動でのビット操作なしに、一般的なフォームフィールドのオプションを設定できます。

生成されたフォーム现在设置了 `/NeedAppearances`，以便常用的PDF查看器可以自动渲染字段。

2026-05-08 Version 2.4.0

AES-128 PDF暗号化の問題を修正しました。字符串和流现在确实使用AES-CBC进行加密，安全级别为V=4 / R=4。

CryptKeyLength=aes128 现在创建加密的PDF文件，兼容的查看器可以使用配置的用户密码或所有者密码来打开这些文件。

ASCIIHexDecode、ASCII85DecodeおよびRunLengthDecodeエンコーダーヘルパーを追加しました。

バンドルされたJBIG2およびJPEG 2000の機能を更新しました。これにより、サポートされていないデコードの場合、プレースホルダー画像データではなく、正しく「サポートされていない」と報告されるようになりました。

2026-05-06 Version 2.3.23

現在のRAD StudioおよびVisual Studioツールチェーン向けに、バンドルされたzlib-ng、libjpeg-turboおよびlibtiffオブジェクトのビルドを調整しました。

DelphiおよびC++Builder環境において、ネイティブ圧縮および画像ライブラリのヒープアライメントを改善しました。

DelphiおよびC++Builderの自動回帰テストスイートを、Win32、Win64、およびWin64x環境で検証しました。

2026-05-05 Version 2.3.22

バンドルされた64ビットのFlate圧縮ビルドで、zlib-ngランタイムのSIMDディスパッチを有効にしました。

クラシックなツールチェーンとの互換性のために、Win32 zlib-ngを安定版の汎用オブジェクトパスに保持しました。

ネイティブオブジェクトのビルドプロセスを強化しました。コンパイラが正常に動作したが、出力オブジェクトが生成されなかった場合、それをビルドエラーとして扱います。

2026-05-05 Version 2.3.21

バンドルされたWin32、Win64、およびWin64xオブジェクトビルドで、libjpeg-turboのSIMDアクセラレーションを有効にしました。

THotPDF ビルドフラグを通じて、SIMD サポートを明示的に有効にしました。

Delphi Win32でSIMD JPEGオブジェクトセットのリンクを妨げていた、Win32 NASM OMF出力に関する問題を修正しました。

SIMDおよびzlib-ngの再構築後に発生したWin64 TIFF画像のバグを修正しました。

2026-05-05 Version 2.3.20

ページストリーム、フォント、CMaps、画像、TIFF出力、およびFlateDecodeヘルパーにおいて、バンドルされているFlateバックエンドを、互換性のあるモードでzlib-ngに置き換えました。

zlib-ng 移行中に発見された、密データのストリーム圧縮および TIFF 形式の小さな画像のインポートに関する問題を修正しました。

JPEGワークフローはlibjpeg-turboを、TIFFワークフローはlibtiffを基盤として引き続きサポートします。

DelphiおよびC++BuilderのPDF生成、画像インポート、圧縮、暗号化、ハイパーリンク、ページ設定、およびコピー/マージ/編集ワークフローに関する、広範囲な自動回帰テストカバレッジを追加しました。

2026-05-01 Version 2.3.19

Win64環境におけるFlateDecodeページストリームの生成を修正し、高密度バーコード出力の問題を解決しました。

最新のDelphiページとフォントストリームの圧縮機能を、安定したRTL zlibパスを使用して実装しました。

2026-05-01 Version 2.3.18

C++Builder Win64x環境における暗号化されたPDF生成のバグを修正しました。修正内容は、ポインタサイズに基づいたRC4キーの設定です。

C++Builder Win64x 编译环境下的 TIFF 导入功能已修复。

LoadFromFileで開かれたPDFのページ追加機能において、追加されたページが安全なオブジェクト番号で保存されるように修正しました。

2026-05-01 Version 2.3.17

C++Builder 版本的 CanvasDrawing 和 GraphicDraw 示例已更新，以匹配改进的 Delphi 图形示例。

C++Builder版ViewerPref演示程序已改进，具有更清晰的用户界面状态、验证功能、预设保存/加载支持，以及专门的方向设置输出。

2026-05-01 Version 2.3.16

結合したPDFファイルにおいて、埋め込みCID TrueTypeフォントとネストされた幅配列を含む場合のページコピー機能を修正しました。

複数のPDFドキュメントからページを順番にコピーする際のオブジェクトのマッピングを改善しました。

2026-05-01 Version 2.3.15

Delphi 演示程序 ViewerPref 已改进，现在只有在相关时才会启用特定选项的控件。

ViewerPref エラー報告、コピー回数検証、および名前付きプリセットの保存/読み込み機能を追加しました。

2026-05-01 Version 2.3.14

PDFmerge Delphi 演示程序已重新设计，现在是一个独立的合并示例，可以在需要时创建源 PDF 文件。

マージの検証、出力インデックス、およびUIの成功/失敗メッセージの改善。

2026-05-01 Version 2.3.13

DelphiのCanvasDrawおよびGraphicDrawデモを改善し、より明確で再現性の高い視覚的な出力が得られるようにしました。

GDIフォントパス全体でTrueTypeフォントの選択を改善し、ラスターフォールバックフォントによる埋め込み時のエラーを削減しました。

PDF内で、複数のテキストブロックで同じフォントが使用されている場合に、文字間隔の問題を修正しました。

フォント埋め込みのエラーメッセージを改善し、要求されたフォント名と文字セットを表示するようにしました。

2026-05-01 Version 2.3.12

CopyPageデモを改善し、別のツールを必要とせずに、標準以外の/Pages構造を持つPDFファイルをコピーできるようにしました。

CopyPage 现在无论哪个复制路径成功，都将写入 FlateDecode 压缩的输出。

CopyPageFixedスタンドアロンサンプルを、メインのCopyPageデモに統合しました。

2026-05-01 Version 2.3.11

生成的PDF文件现在默认情况下，每个页面都会自动调整以适应窗口高度。

オフィス、大判、図面、カード、ID、写真、日本語、中国語、および台湾の用紙サイズに対応する、プレフィックスなしの定義済みページサイズ名を多数追加しました。古いプレフィックス付きのページサイズ名との互換性は維持されています。

Delphiのページサイズに関するデモを、LargeSize、NormalSize、SmallSizeのプロジェクトとして再構成しました。

2026-04-29 Version 2.3.10

TIFF互換レイヤーにおけるRAD Studio XE7パッケージのビルド問題を修正しました。

RAD Studio 10 Seattle および 10.1 Berlin に関する警告を削減しました。

RAD Studio 製品バージョン 9.0 から 12.0 までのコマンドラインライブラリのビルドマッピングを修正しました。

RAD Studio ProductVersion 9.0 向けのコマンドラインパッケージのビルド機能を復元しました。

RAD Studio XE2 Win64 版本的构建问题已修复，通过声明 Win64 兼容性模块所需的 CRT vsnprintf 符号。

古いDelphiおよびC++Builderプロジェクトファイルにおける数値ブール値による、レガシープロジェクトとの互換性が向上しました。

2026-04-29 Version 2.3.9

RAD Studio 10.1 Berlinライブラリパッケージのビルド問題を修正しました。これは、Libディレクトリからパッケージをコンパイルすることで解決されます。

古いDelphiコンパイラでのTrialライブラリのビルド問題を修正しました。具体的には、Trialウォーターマークのパスからインライン変数宣言を削除しました。

2026-04-29 Version 2.3.8

RAD Studio 10.3 RioビルドにおけるTIFFストリームコールバックパスから、非推奨のTStream.Seekコンパイラ警告を削除しました。

2026-04-29 Version 2.3.7

バンドルされたlibtiff 4.7.xオブジェクトファイルを使用する際のTIFFからPDFへの変換問題を修正しました。

厳格なコンパイラ設定下での、バンドルされたzlib PascalブリッジのRAD Studio Win32コンパイル問題を修正しました。

TIFFからPDFへの変換に関するDUnitXの回帰テストカバレッジを追加しました。

2026-04-28 Version 2.3.5

クラシックなBorland C++ Win32コンパイラを使用してバンドルされたzlib、libjpeg-turbo、およびlibtiffのソースパッケージの再構築に関する問題を修正しました。

DelphiおよびC++Builderのビルドの信頼性を向上させるため、配布されているWin32およびWin64のサードパーティ製オブジェクトファイルを再構築し、整合性を確認しました。

公共APIに変更はありません。既存のDelphi、C++BuilderおよびRAD Studioプロジェクトは、このバージョンを互換性リリースとして利用できます。

2026-04-19 Version 2.3.3

HotPDFリソースのコンパイルに、ホスト環境のINCLUDE設定が干渉するのを防ぎ、RAD Studioプロジェクトの信頼性を向上させました。

パッケージのビルドにおける重複リソースの警告を削減しました。特に、RAD Studio 13.1 Florence プロジェクトにおいて効果があります。

2026-04-19 Version 2.3.2

パッケージおよびデモプロジェクトの出力フォルダは、現在アクティブなRAD Studioのバージョンに合わせて自動的に変更されます。

THotPDF370パッケージのビルド処理を改善し、古いリソースファイルが新規に生成されたリソースファイルと誤って関連付けられる問題を修正しました。

2026-04-19 Version 2.3.1

C++BuilderのTextOutデモは、現在、対応するRAD Studioのバージョンで、手動での編集なしでビルドできるようになりました。

TextOut 演示程序在 Win64x 平台上的重新构建行为已修复，现在会在链接之前将所需的资源文件添加到构建过程中。

2026-04-19 Version 2.3.0

C++Builder 13.1 Florenceのサポートを、Win32、Win64、およびWin64xターゲット向けに追加しました。

DelphiおよびC++Builder向けに、`TextOut`関数のオーバーロードの可用性を標準化し、古いC++Builderヘルパー名を互換性を維持しました。

Delphi Win64の静的リンクにおいて、バンドルされたzlib、libjpeg-turbo、およびlibtiffオブジェクトファイルから以前のリンカの警告を削除し、問題を修正しました。

Win64xパッケージの出力機能を改善し、C++Builderプロジェクトが、通常のRAD Studioの検索パスを通じて生成されたHotPDFライブラリを見つけられるようにしました。

2026-04-17 Version 2.2.1

Delphi Win32 リンク警告を、バンドルされているサードパーティ製圧縮および画像ライブラリから削除しました。

DelphiおよびC++Builderビルドにおけるzlib、JPEG、およびTIFFサポートの静的リンク互換性が向上しました。

2026-04-14 Version 2.2.0

同梱されているサードパーティ製ライブラリを、zlib 1.3.2、libjpeg-turbo 3.1.90、およびlibtiff 4.7.1にアップグレードしました。

更新了压缩、JPEG 和 TIFF 库，并改进了 Win32 和 Win64 的静态链接。

PDF生成において、JPEGまたはTIFF形式の入力を使用する際の画像フォーマットの互換性を拡張しました。

HTMLヘルプを、現在のTHotPDF API、サンプルコード、およびライブラリの構成に合わせて更新しました。

2026-04-13 Version 2.1.4

RAD Studio XE2からXE8までのWin64コンパイルの問題を修正しました。

古いDelphiコンパイラで使用されるバンドルされたオブジェクトファイルとの互換性が向上しました。

古いパッケージリソースファイルを削除しました。これにより、重複リソースのリンカ警告が発生するのを防ぎます。

HotPDFパッケージのDelphi XE3プロジェクトメタデータを修正しました。

2026-04-12 Version 2.1.3

Delphi TestNumeric 演示已扩展，现在是一个用于测试数值 PDF 输出的实用回归测试。

小数、分数、整数的验证范围已扩展，并且改进了PDF重新加载的行为。

デバッグ出力ファイルは、専用のコンパイル時オプションを有効にすることで、オプションで使用できるようになりました。

デバッグログと数値出力テストに関するヘルプコンテンツを更新しました。

2026-04-10 Version 2.1.2

Win32およびWin64環境におけるPDF出力の埋め込みフォントレンダリングを改善しました。

組み込みフォント間の切り替え時に、一部のグリフが正しく表示されない問題を修正しました。これには、Calibriなどの一般的なWindowsフォントが含まれます。

フォントテストのデモを更新し、視覚的な検証を容易にするためにサンプルPDFを生成しました。

フォント埋め込み、Unicodeテキスト出力、および埋め込みフォントのサンプルに関するHTMLヘルプページを更新しました。

2026-04-08 Version 2.1.1

DelphiおよびC++BuilderのViewerPreferencesデモを更新し、現在のTHotPDF APIに一致するようにしました。

新しいPDFビューアのオプションに対するサポートを追加しました。

生成されたデモ出力が改善され、UIで選択されたビューアの表示設定のみが反映されるようになりました。

ViewerPreferences および関連するドキュメントプロパティの HTML ヘルプページを更新しました。