HotPDF Docs
الصفحة الرئيسية المحتويات نظرة عامة ملاحظات الإصدار THotPDF THPDFPage

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 إلى أداة VCL GUI تفاعلية لسير عمل preflight لملف واحد.
  • تغطي الواجهة الآن تقارير text وJSON وHTML القياسية، وكلمات المرور الاختيارية، وملفات profile INI، وال presets المدمجة، والتحقق PDF/VT لملف واحد، وإخراج PDF مع embedded report، ومعاينة التقرير، وتسجيل الحالة، والتسمية التلقائية للإخراج، والوصول السريع إلى الملفات الناتجة.
  • تمت إزالة سلوك بدء التشغيل القديم الذي كان ينشئ تلقائيا sample PDF وتقريرا عند عدم توفير command-line arguments.

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 الآن استخدام مورد خط Type 0 الذي ينشئه RegisterUnicodeTTF لإخراج Unicode في المستويات التكميلية، بحيث يشترك نص الصفحة وتدفقات مظهر AcroForm في مسار ترميز CID الداخلي نفسه.
  • تحافظ خطوة الإنهاء المشتركة الآن على مزامنة إخراج SMP على مستوى الصفحة عبر FUnicodeUsedCps و/CIDToGIDMap وإدخال /W في الخط التابع و/ToUnicode، مع تجنب خريطة SMP المحلية القديمة الخاصة بالصفحة.

2026-05-24 Version 2.121.2

  • تم الآن توجيه الأحرف Unicode الموجودة في المستويات التكميلية من خلال خريطة أحرف (cmap) من النوع 12 المسجلة في خط الصفحة عند تحميل الخط النشط بواسطة `RegisterUnicodeTTF`. يتم إخراج الرموز التعبيرية والقيم العددية الأخرى الأكبر من U+10000 كرمز CID واحد في تدفق النص للصفحة بدلاً من رمزين نصيين بديلين.
  • تسجل سجلات CMap الخاصة بالخط المستخدم في الصفحة، والتي تحمل اسم /ToUnicode، رموز CIDs الخاصة برموز SMP مرة أخرى إلى زوج الوكيل الأصلي UTF-16BE، مما يحافظ على استخراج النص وإمكانية الوصول مع الحفاظ على المسار الحالي للخط المستخدم في الصفحة والذي يحمل اسم /CIDToGIDMap /Identity.

2026-05-24 Version 2.121.1

  • تقوم تدفقات مظهر AcroForm المبنية على RegisterUnicodeTTF الآن بعرض أحرف Unicode من المستوى التكميلي، مثل الرموز التعبيرية، من خلال CID داخلي واحد بدلاً من كتابة زوج بديل UTF-16 كمعرّفي CID من نوع Identity-H. تشير /CIDToGIDMap المولدة إلى glyph الحقيقي، وتعيد /ToUnicode ربطه بزوج UTF-16BE البديل الأصلي لاستخراج النص.
  • تحدّث مرحلة إنهاء خط Unicode كلًّا من /CIDToGIDMap و/W و/ToUnicode بعد تسجيل كل تدفقات المظهر لتعيينات CID الداخلية المتأخرة، بحيث تستخدم عملية تصغير 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 (يشير إلى تعليق Movie عبر /Annotation ويختار /Operation: Play / Stop / Pause / Resume).
  • تم الآن إرجاع قاموس التعليق التوضيحي الذي تم إنشاؤه بواسطة `AddScreenAnnotation` و `AddMovieAnnotation`، بحيث يمكن للمستخدمين ربطه بمساعد الإجراء المناسب. التغيير في التوقيع من `procedure` إلى `function` متوافق مع واجهة برمجة التطبيقات (ABI) لـ Delphi، وبالتالي فإن المستخدمين الحاليين الذين يستدعون هذه الدوال ويتجاهلون النتيجة لا يزال بإمكانهم تجميع التعليمات البرمجية وإنشاء ملفات PDF متطابقة تمامًا.
  • عمق التنفيذ القياسي: تقوم كل وظيفة مساعدة بإخراج الإدخالات الإلزامية المحددة في المواصفة بالإضافة إلى الحقول الاختيارية الأكثر استخدامًا (الصوت / مستوى الصوت / التكرار / المزامنة؛ العرض / JavaScript). يتم استبعاد معلمات تشغيل الوسائط ومعلمات شاشة الوسائط ومحدد العرض والصوت / المزج عن قصد - حيث تغطي الإعدادات الافتراضية للقارئ 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" بأذونات الوسائط "/P /TF (TEMPACCESS)" وفقًا للفقرة §13.2.6.1، الجدول 280، وهي الحد الأدنى من مستوى الأذونات الذي يسمح للمستخدم بتمرير البيانات إلى برامج الترميز الصوتية/الفيديو الخاصة بالنظام الأساسي.
  • تُعيّن تدفقات الإجراءات الصوتية القيم الافتراضية للحقول الاختيارية وفقًا للمواصفات (الحجم=1.0، التكرار=خطأ، متزامن=خطأ) وتقوم بإخراجها فقط عندما يمرر المتصل قيمًا غير افتراضية، مما يحافظ على حجم قاموس الإجراء صغيرًا في الحالة الشائعة.
  • 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` (التغطية الشاملة لجميع أنواع الإجراءات الأربعة بالإضافة إلى ربط التعليقات التوضيحية للشاشة/الفيديو) و `smoke_multimedia_actions_pdfa_pdfx` (8 تأكيدات تغطي 3 إجراءات × PDF/A + PDF/X). لا يزال اختبار `smoke_button_actions` يعمل بشكل صحيح بعد إعادة هيكلة الإجراءات `AddScreenAnnotation` و `AddMovieAnnotation`.

2026-05-23 Version 2.120.15

  • تم إصلاح مشكلة تسببت في أن عملية تسلسل كائن PDF انتهت قبل تشغيل اثنين من أدوات التعديل اللاحقة (أداة تقليل حجم خط TrueType من الإصدار v2.84.0 وأداة إضافة علامات التبويب التلقائية وفقًا للمواصفة PDF/UA-1 §7.18.3 من الإصدار v2.94.0)، وبالتالي لم يتم تطبيق أي من هذه التغييرات على الملف الناتج. في المستندات التي استخدمت RegisterUnicodeTTF + AddTextField، تم تضمين ملف الخط الكامل (حوالي 1 ميجابايت للغة اللاتينية وحوالي 14 ميجابايت للغة الصينية/اليابانية/الكورية) بدلاً من الخط المصغر (حوالي 150 كيلوبايت / حوالي 500 كيلوبايت)، وافتقر البادئة الفرعية المكونة من ستة أحرف "AAAAAA" إلى حقل /BaseFont، وكانت تدفق /CIDSet الخاص بـ PDF/A في وصف الخط مفقودًا (مما أدى إلى فشل veraPDF وفقًا للمواصفة ISO 19005-1 §6.3.5 / -2 -3 §6.2.11)، وكانت ملفات PDF/UA-1 التي تفتقر إلى المفتاح §7.18.3 /Tabs /S في الصفحات التي تحتوي على تعليقات تثير قاعدة الفحص 21-001 في Matterhorn وقاعدة PAC 3 المتعلقة بـ "Tabs".
  • كلا من أدوات التعديل تعمل الآن قبل عملية الحفظ إلى التدفق (SaveToStream) أو الملف (SaveToFile). تقوم هذه الأدوات بمعالجة قائمة الكائنات غير المباشرة وكتابة ملف PDF. يكون الناتج مطابقًا تمامًا للإصدار v2.120.14 للمستندات التي لا تسجل خط Unicode TTF أو لا تقوم بتمكين توافق PDFUA؛ وكانت أدوات التعديل هذه تعمل بالفعل كعمليات غير فعالة في تلك الحالات، لذا فإن إعادة ترتيبها تغير فقط المستندات التي كان فيها إخراج الإصدار v2.120.14 معيبًا.
  • تم التحقق من ذلك باستخدام `Win32 smoke_unicode_ttf_subset` (حيث يمثل الجزء الفرعي 33.6٪ من حجم Arial المخزن على القرص - تم توفير 676 كيلوبايت - /BaseFont، والبادئة `UYENHH+ArialMT` متسقة عبر `Type 0 /CIDFontType2 /FontDescriptor.FontName`)، و `Win32 smoke_pdfua_annot_structparents` (حيث تم وضع الطابع `/Tabs /S` على القاموس للصفحة التي تحتوي على تعليقات توضيحية، وكانت جميع التأكيدات الخمسة المتعلقة بـ §7.18.3 وهيكلة التعليقات التوضيحية خضراء).

2026-05-23 Version 2.120.14

  • تطبيق صارم لقواعد البنية والدور (ISO 14289-1 §7.7 + ISO 32000-1 §14.7.3): عند تمكين خيار PDFUACompliance، تقوم الدالة AddStructureElement الآن برفض أي دور "/S" ليس أحد الأنواع القياسية المحددة في الجدول 333 من القسم 14.8.4 من PDF 1.7 (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)، أو ليس دورًا مخصصًا قام المستخدم بتسجيله مسبقًا باستخدام الدالة AddStructRoleMap. تتضمن الاستثناءات التشخيصية اسم الدور المخالف، وتشير إلى القسم 7.7 من PDF/UA-1 / الجدول 333، وتقترح حل استخدام الدالة AddStructRoleMap. يتم أيضًا رفض الدور الفارغ برسالة مخصصة. بدون هذا الفحص، ستظهر الأدوار غير المتوافقة بشكل غير متوقع في شجرة البنية، مما يؤدي إلى فشل أدوات veraPDF / PAC في الكشف عن "نوع بنية غير معروف".
  • يتم تشغيل البوابة الجديدة فقط عندما تكون قيمة PDFUACompliance هي True؛ تحتفظ الاستدعاءات غير المتوافقة مع UA بسلوك "freeform-role" كما كان في الإصدارات الأقدم من v2.120.14. تتحد جميع أربع عمليات تحميل لـ AddStructureElement (الإصدار الأساسي ذو المعاملات الأربعة من نوع AnsiString، والإصدار ذو المعاملات الستة من v2.88.0 لـ /Alt و /ActualText، والإصدار ذو المعاملات السبعة من v2.95.0 لـ /ID، والإصدار ذو المعاملات من v2.119.41 من نوع THPDFStandardStructureType) على نفس المسار، لذا يكفي حارس واحد. دائمًا ما يمرر إصدار التعداد اسمًا من الجدول 333، وبالتالي دائمًا ما يمرر الفحص؛ يفضل المستخدمون هذا الإصدار لتجنب الأخطاء الإملائية/مشكلات حساسية حالة الأحرف (مثل 'Para' مقابل 'P'، و 'Lbody' مقابل 'LBody') في وقت الترجمة.
  • تم بالفعل تضمين تعداد THPDFStandardStructureType في الإصدار v2.119.41 (41 اسمًا محددًا مجمعة في 5 مجموعات أدوار PDF: §14.8.4.1 التجميع / §14.8.4.2 مستوى الكتلة / §14.8.4.3 مستوى مضمن / §14.8.4.4 روبي وواريتشو / §14.8.4.5 رسم توضيحي)، ووظيفة StandardStructureTypeToName(T) للبحث عن الاسم المقابل للتعداد، ووظيفة IsStandardStructureType(Name) للتحقق من الصحة من جانب المتصل؛ في الإصدار v2.120.14، تم دمج هذه الإمكانات في نقطة الدخول AddStructureElement بحيث يتم التحقق الصارم تلقائيًا. أضيفت وظيفة مساعدة خاصة جديدة، وهي _IsCustomRoleInRoleMap، والتي تتصفح المصفوفة الديناميكية FStructRoleMap باستخدام CompareMem الآمن للبيانات الثنائية، وتطابق أسماء الأدوار المخصصة غير 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

  • تمكين ميزة التشكيل للمجموعة الفرعية (إكمال المرحلة 8f): THotPDF.EnableShapingFeatureForSubset (FeatureTag) / the تكرار التحميل الزائد لـ THPDFShapingFeature، مع فحص كل بحث GSUB مرتبط بالميزة المطلوبة ضمن الإصدار v2.119.49. تعيين حالة اختيار GSUBScript / SetGSUBLanguage، وفحص كل معرف GID بديل محتمل عبر LookupType 1 (Single — Format 1 delta over Coverage glyphs + Format 2 substituteGlyphIDs array)، وLookupType 2 (Multiple — Sequence.substituteGlyphIDs[])، وLookupType 3 (Alternate — AlternateSet.alternateGlyphIDs[])، وLookupType 4 (Ligature — Ligature.ligatureGlyph)، وLookupType 5 / 6 (Contextual / Chained Contextual — التكرار في التسجيلات الفرعية التسلسلية مع حد عمق 8)، وLookupType 7 (Extension — إلغاء التفاف تلقائي إلى نوع البحث الفعلي)، وLookupType 8 (Reverse Chained — substituteGlyphIDs[]). دمج معرّفات GID باستخدام عملية OR في FUnicodeExtraUsedGlyphs، بحيث يقوم أداة إنشاء المجموعة الفرعية v2.84.0 بسحب كل حرف يمكن أن تنتجه الميزة إلى المجموعة الفرعية من الخط المضمن. تكمل المرحلة 8f وظيفة MarkUnicodeGlyphUsed على مستوى الحرف في الإصدار v2.119.50، مع خيار الاشتراك المجمع على مستوى الميزة للمستخدمين الذين يمكّنون الميزة عالميًا في مسار الإنتاج الخاص بهم.
  • يُرسل هذا التعديل لكل قيمة من قيم تعداد `THPDFShapingFeature` إلى مجموعة علامات OpenType المكونة من 4 بايت: `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`. يقبل هذا التعديل أيضًا أي علامة OpenType مكونة من 4 بايط لتحديد دقيق يتجاوز حالات التعداد المضمنة. تحذير بشأن التضخم الناتج عن التضمين: قد يؤدي تمكين الميزات الواسعة (مثل `aalt`، والذي يقوم بتحميل كل حرف في النص) إلى تضمين جزء كبير من مجموعة أحرف الخط، مما يلغي تحسين حجم الإصدار `v2.84.0`. يجب على المستخدمين تفضيل `Phase 9 MarkUnicodeGlyphUsed` عندما يعرفون معرفات الأحرف الدقيقة. الإعداد الافتراضي هو "إيقاف"، ويتطلب التفعيل صراحةً. يغلق هذا التعديل المرحلة الفرعية الأخيرة من "خريطة طريق محرك GSUB" المرحلة 8.
  • تتوافق العقود الدفاعية مع الإصدار v2.119.50: لا يتم تسجيل أي خط، ولا توجد جدول GSUB، وعلامة غير 4 بايت، والميزة غير موجودة في مسار (البرنامج النصي، اللغة)، وسلسلة البحث فارغة - كل حالة "لا يوجد شيء للقيام به" هي عملية غير مؤثرة (لا يوجد استثناء). المكالمات المتكررة هي عمليات متطابقة (يتم دمج الخريطة النقطية باستخدام OR). يتم تأجيل الاستدعاءات المتداخلة من النوع الفرعي السياقي 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`) إدخالًا واحدًا (تسلسل الاستبدال ← المصدر). تشمل حالات الاستخدام النموذجية ما يلي: بعد الاستبدال المتعدد (GID واحد → N GID)، يتم إخراج تسلسل الاستبدال، ويتم تسجيل التعيين العكسي بحيث يمكن للقارئ المستهلك نسخ/لصق البيانات وإعادتها إلى نقطة الترميز الأصلية؛ بعد استبدال الحروف المتصلة (N GID → حرف متصل واحد)، يتم إخراج الحرف المتصل، ويتم تسجيل نقطة ترميز الحرف المتصل بحيث يتم عكسها إلى تسلسل المصدر المكون من N عنصرًا (على سبيل المثال، يمكن عكس حرف متصل سياقي `CALT` إلى نقاط الترميز المكونة له). تقوم الدالة `ClearToUnicodeReverseMappings` بإزالة جميع التسجيلات التي قام بها المتصل؛ وتعرض الدالة `ToUnicodeReverseMappingCount` عدد التسجيلات المعلقة.
  • يُضيف الأمر `EndDoc emit` إدخالات مسجلة بواسطة المستخدم ككتل `bfchar` إضافية بعد الكتلة المضمنة المكونة من 35 إدخالًا، ويتم تقسيمها تلقائيًا إلى كتل فرعية مكونة من 100 إدخال لكل خريطة أحادية اللون (CMap) وفقًا لمواصفات ملفات `CIDFont` (ملاحظة فنية رقم 5014) §1.4.2، مع مراعاة حد عامل التشغيل `bfchar`. تُصدر نقاط الترميز `BMP` أربعة أرقام سداسية عشرية؛ بينما تُصدر نقاط الترميز `SMP` زوجًا بديلًا `UTF-16BE` (ثمانية أرقام سداسية عشرية) وفقًا لمواصفات خريطة أحادية اللون (CMap) الخاصة بـ Adobe. يتم الحفاظ على ترتيب التسجيل، بحيث تضمن دلالات "آخر كتابة يفوز" لخريطة أحادية اللون (CMap) في برامج قراءة PDF سلوك تجاوز حتمي للمستخدمين في حالة حدوث تعارض مع الـ 35 إدخالًا المضمنة (على سبيل المثال، يؤدي تسجيل المستخدم لخريطة مخصصة لـ `` "fi" إلى تجاوز الإعداد الافتراضي v2.119.65 في برنامج القراءة). تحتفظ المستخدمون الذين لا يستدعون الأمر `RegisterToUnicodeReverseMapping` بخريطة `ToUnicode` متطابقة تمامًا مع الإصدار الأساسي v2.120.10. يؤدي تعيين `SetFormUnicodeFontDict ('', nil)` إلى مسح سجل المستخدم، مما يضمن أن تسجيل الخط Unicode التالي يبدأ من جديد.

2026-05-23 Version 2.120.10

  • تسجيل نص ميزمار (المرحلة 8f.10): يسجل نص ميزمار (علامة OpenType mymr) باعتباره النص الهندي العاشر والأخير في HotPDF، ويغطي كل من كتلة ميزمار الأساسية (U+1000-U+109F: بورمي، مون، سغاو كارين، غربي بو، شان، روماي بالونغ، باو) وكتلة Extended-A (U+AA60-U+AA7F). تمت إضافة ApplyMyanmarReorder لإعادة ترتيب المرحلة الأولية و GetMyanmarCategory للبحث عن نقطة الترميز، ويمكن إعادة استخدامها من خلال موزع ApplyIndicReorder.
  • أكثر الهياكل التآلفية تعقيدًا في المجموعة: Kinzi 3-CP تم اكتشاف البادئة (U+1004 + U+103A + U+1039) في بداية التآلف، وتم الاحتفاظ بها وإخراجها في بداية الإخراج وفقًا للقاعدة R8؛ ينتقل حرف العلة الأساسي E (U+1031) إلى بداية التآلف وفقًا للقاعدة R10؛ يتم جمع أربعة حروف علة وسيطة Y / R / W / H (U+103B-U+103E) وإخراجها بترتيب ثابت Y → R → W → H وفقًا للقاعدة R9، بغض النظر عن ترتيب المصدر.
  • يتم التعامل مع كل من ASAT (U+103A) و VIRAMA (U+1039) على أنهما virama للتعامل مع الحروف الساكنة المكدسة. يتم عرض DOT BELOW (U+1037) أسفل الحرف الأساسي؛ بينما يتم عرض علامات النغمة الأخرى أعلى الحرف. يتم عرض ANUSVARA (Bindu) أعلى الحرف، ويتم عرض VISARGA بعد الحرف. لا يوجد Repha.
  • تمت إضافة إدخالين في سجل `IndicScripts` (الكتلة الرئيسية والكتلة الممتدة) يشتركان في نفس وظائف إعادة ترتيب ميانمار، وبالتالي تظهر الحروف الممتدة من مجموعة الأبجدية الميانمار وعلامات النبرة بلغة باو كارين بشكل متسق من خلال نظام التوزيع.
  • **يكمل معالجة دفعة النصوص الهندية غير المستخدمة لنظام Devanagari، والتي تتكون من 11 مرحلة** (المراحل 8f.0-8f.10): تتضمن البنية التحتية بالإضافة إلى 10 نصوص هندية مسجلة، وهي: Devanagari، والبنجابية، والوجايية، والتاميلية، والتيلجو، والكنادية، والماليالامية، والسينغالية (عائلة Brahmic SIA)، والكمبودية، و ميانمار (جنوب شرق آسيا).
  • وفقًا لمعيار Unicode 16.0 §16.3 (ميانمار) ومواصفات تشكيل النص الميانماري في OpenType.

2026-05-23 Version 2.120.9

  • تسجيل خط الخمير (المرحلة 8f.9): يسجل خط الخمير (علامة OpenType `khmr`، كتلة Unicode U+1780-U+17FF) كخامس خط إنديكي في HotPDF وأول خط في جنوب شرق آسيا. يقوم `ApplyKhmerReorder` الجديد بترتيب مرحلة أولية و `GetKhmerCategory` بالبحث عن نقطة الترميز، ويمكن إعادة استخدامه من خلال `ApplyIndicReorder`.
  • بنية مقطع لفظي مستقلة (وليست نمط Brahmic R1-R5 المستخدم في الإصدارات 8f.1-8f.8): تتحرك حروف العلة الأساسية (E / AE / AI / OE / OO / AU) إلى بداية المقطع؛ وتوجه الرموز المتغيرة (MUUSIKATOAN، TRIISAP) وغيرها من الرموز الموجودة فوق الأساس إلى المخزن المؤقت الخاص بها؛ ويتم عرض Bindu (NIKAHIT) فوق النص؛ ويتم عرض Visarga (REAHMUK، YUUKALEAPINTU) بعد النص.
  • معالجة الأحرف التابعة (subscript) في COENG: كل حرف COENG (U+17D2) بالإضافة إلى زوج الحروف الساكنة يشكل مجموعة حروف ساكنة مكدسة تبقى في المخزن المؤقت الأساسي بالترتيب الأصلي، مما يسمح لميزات 'pres' / 'blws' في نظام استبدال الحروف (GSUB) بالتعامل مع موضع الأحرف التابعة. يتم دعم الأحرف التابعة المتداخلة.
  • لا يوجد Repha: لا تشكل النصوص الخمير شكلًا مرئيًا لـ Repha، لذا يظل التسلسل `Ra + COENG + Consonant` في الترتيب الأصلي بدلاً من الدوران ليصبح في نهاية المقطع.
  • وفقًا لمعيار Unicode 16.0 §16.4 (الخميرية) ومواصفات OpenType الخاصة بتشكيل النصوص الخميرية.

2026-05-23 Version 2.120.8

  • PAdES **adbe-revocationInfoArchival** CMS يصدر سمة موقعة (PAdES المرحلة 9): يصدر معرف الكائن الخاص بشركة Adobe 1.2.840.113583.1.1.8 والذي يحتوي على قيم إلغاء المصادقة من CRL و OCSP داخل توقيع CMS نفسه. تفضل Adobe Acrobat إعطاء الأولوية لهذه السمة للتحقق من صحة التوقيع، مقارنةً بعمليات البحث في قاموس DSS وجلب OCSP/CRL من الشبكة - وهو أمر بالغ الأهمية لملفات PDF التي يمكن التحقق من صحتها في وضع عدم الاتصال وأفضل توافق مع Adobe Acrobat.
  • تمت إضافة حقول جديدة إلى `THPDFCMSSignOptions`:
    • AdobeCRLsDER: array of TBytes - كل عنصر هو ترميز DER لقائمة الشهادات X.509 (RFC 5280)، بنفس تنسيق تدفقات `/CRLs` في DSS.
    • AdobeOCSPsDER: array of TBytes - كل عنصر هو تسلسل `BasicOCSPResponse` (RFC 6960 §4.2.1) بتنسيق DER. ملاحظة: *ليس* الغلاف الخارجي `OCSPResponse` - يجب على التطبيقات التي تتعامل مع استجابات OCSP كاملة فك ضغط سلسلة بايت `responseBytes.response` أولاً لاستخراج `BasicOCSPResponse`.
  • التنشيط: يتم إصدار هذا الخاصية عندما يكون واحد على الأقل من المصفوفين غير فارغ. القيمة الافتراضية هي فارغة (كلا المصفوفين)، مما يحافظ على استقرار مستوى البايت في الإصدار v2.120.7.
  • وفقًا لمواصفات Adobe، يتم التعامل مع ASN.1 DER على النحو التالي: 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] (otherRevInfo لأنظمة الإبطال غير X.509) تظل خارج النطاق.
  • شكل السلك (مع ملء كلا الفرعين): 30 A0 30 <...> A1 30 <...>
  • **يتوافق مع قاموس DSS:** هذا السمة هي *موازية* لـ (وليس بديلاً لـ) قاموس PAdES-B-LT DSS (على مستوى الكتالوج `/DSS /Certs /OCSPs /CRLs /VRI`، والذي تم تقديمه في الإصدار v2.110.0). تميل أدوات التحقق الصارمة من PAdES (EU DSS، mTOM) إلى احترام DSS؛ ويحترم Adobe Acrobat `adbe-revocationInfoArchival`. لتحقيق أقصى قدر من التوافق، املأ كلا الطبقتين بنفس بايتات CRL / OCSP عبر AddPAdESDSSCRL / AddPAdESDSSOCSP بالإضافة إلى AdobeCRLsDER / AdobeOCSPsDER.
  • يقوم الم wrapper الخاص بـ `HPDFCMSBuildSignedData` ذي المعاملات الأربعة بتهيئة الحقول الجديدة إلى الصفر، وذلك للحفاظ على تطابق الحزم القديمة من CMS من حيث حجم البايت.
  • وفقًا لمراجع Adobe Acrobat PDF بالإضافة إلى RFC 5280 (قائمة الإبطال) و RFC 6960 (OCSP).

2026-05-23 Version 2.120.7

  • تم توقيع سمة **content-time-stamp** الخاصة بـ PAdES باستخدام CMS، وهي سمة من المرحلة 8: يتم إصدار `id-aa-ets-contentTimestamp` (معرف الكائن 1.2.840.113549.1.9.16.2.20، وفقًا لـ ETSI EN 319 122-1 §5.2.8 + RFC 5126 §5.11.4) والذي يحمل رمز TimestampToken مسبق التوقيع وفقًا لـ RFC 3161، مما يثبت أن محتوى المستند كان موجودًا في الوقت الذي زعمته TSA *قبل* أن يقوم الموقع بتوقيعه. وهو يختلف عن `signature-time-stamp` (سمة غير موقعة من المرحلة 4، بعد التوقيع).
  • تمت إضافة حقل جديد `THPDFCMSSignOptions`. `GetContentTimeStamp: THPDFCMSTimestampCallback`. تم تصميم هذا الإصدار على غرار الإصدار v2.120.3. `GetSignatureTimeStamp`: يقوم HotPDF باستدعاء الدالة (callback) مع تجزئة SHA-256 للمستند (نفس القيمة التي يحملها سمة `messageDigest` الموقعة)، ويقوم بتضمين رمز الوقت (TimeStampToken) بتنسيق DER كقيمة لسمة `content-time-stamp` داخل `SignedAttributes`.
  • القيمة الافتراضية لـ nil تعني عدم إرسال طابع زمني للمحتوى. يجب على المستخدمين الذين يرغبون في ذلك تعيين دالة (closure) تقوم بتشغيل خادم TSA (Time-Stamping Authority) وفقًا لمعيار RFC 3161 عبر 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 تجارية؛ وتعمل التوقيعات غير القانونية مع نقاط النهاية المجانية (مع وجود قيود على المعدل ولكنها مناسبة لمعظم سير العمل).
  • آلية الاستدعاء: يتم استدعاؤها مرة واحدة لكل عملية توقيع. قبل إغلاق السمات الموقعة (SignedAttributes). تصبح بايتات TST جزءًا مما يتم توقيعه، وبالتالي فإن التوقيع نفسه يغطي الطابع الزمني للمحتوى - هذا هو السبب في أنها سمة موقعة (بدلاً من الطابع الزمني للتوقيع، وهو غير موقع ويوجد في unsignedAttrs بعد التوقيع).
  • تُعدِّل هذه المجموعة من الأدوات المساعدة `HPDFCMSBuildSignedData` التي تتطلب 4 وسائط، قيمة `GetContentTimeStamp` لتكون `nil`، وذلك للحفاظ على تطابق الحزم القديمة من CMS على مستوى البايت.
  • مسؤولية المتصل: يجب أن تحتوي حقول PAdES على `ContentsBytes` بحجم مناسب لتوقيع الشهادة بالإضافة إلى طابع الوقت للمحتوى (TST) (حجمه عادةً من 4 إلى 8 كيلوبايت). بالنسبة لعمليات سير عمل B-T التي تجمع بين طابع الوقت للمحتوى و طابع الوقت للتوقيع، يجب مراعاة كلا الطابعين الزمني (TST). القيمة الافتراضية لـ `AddPAdESSignatureField(Profile='B-T')` وهي 16 كيلوبايت، تغطي معظم الحالات.
  • وفقًا لمعايير 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]** الفرع (مرحلة PAdES 7): إغلاق الحقل الاختياري SignerAttributeV2. يسمح للموقع إرفاق تأكيدات موقعة (مثل تأكيدات SAML 2.0، ورموز JWT المدمجة، وشهادات OAuth، ورموز الشهادات الخاصة بالمؤسسة) داخل التوقيع CMS.
  • تمت إضافة سجل `THPDFSignedAssertion` جديد: يحتوي على `SignedAssertionID` (معرف OID لتحديد نوع التأكيد) بالإضافة إلى `AssertionBody: TBytes` (بيانات بايتية مُرمّزة مسبقًا وفقًا لمخطط المعرف OID - عادةً سلسلة بايت تغلف XML الخاص بـ SAML أو الشكل المضغوط لـ JWT). إذا كانت `AssertionBody` فارغة، فسيتم حذف حقل ANY، مما يترك `signedAssertionID` وحده (وهو أمر صالح وفقًا للمواصفات للتأكيدات من النوع البوليان المسجلة بواسطة OID).
  • تمت إضافة حقل جديد `THPDFCMSSignOptions`. `SignedAssertions: array of THPDFSignedAssertion`. يتم دعم عدة تأكيدات؛ تقوم HotPDF بتغليف التسلسل في `[2] EXPLICIT` (علامة `0xA2`).
  • يؤدي شرط إطلاق `SignerAttributeV2` الآن إلى تشغيله عند أي من الحقول الثلاثة الاختيارية. يؤدي ملء جميع الحقول الثلاثة إلى إنتاج: `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 }. الشكل المستخدم لنقل إعلان واحد مع النص: A2 30 30 06 .
  • تستخدم الدالة `CMSEncodeOIDFromString` (الإصدار v2.120.1) لترميز معرفات الكائنات (OID) المستخدمة في عمليات التحقق - أي معرف كائن مكتوب بنظام النقاط مقبول.
  • يقوم الم wrapper الخاص بـ `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]` (المرحلة 6 من PAdES): يتم الآن إصدار شهادات X.509 للسمات داخل التسلسل `SignerAttributeV2`، إما بالإضافة إلى أو بدلاً من `claimedAttributes [0]` الموجود في الإصدار `v2.120.4`. يتيح ذلك للموقع إرفاق شهادات دور "سلطة السمات" (AA) التي تدعم بشكل تشفير هوية/قدرات الموقع.
  • تمت إضافة حقل جديد `THPDFCMSSignOptions`: `CertifiedAttributeCertsDER: array of TBytes`. كل عنصر هو نسخة كاملة مشفرة بتنسيق DER من `AttributeCertificate` (RFC 5755) والتي استلمها المستخدم من الجهة المصدرة. تقوم HotPDF بإخراجها كما هي في تسلسل `CertifiedAttributesV2` ومحاطة بـ `[1] EXPLICIT` (الوسم `0xA1`).
  • تم الآن إصدار السمة `signer-attributes-v2` عندما يكون إما `ClaimedRoles` أو `CertifiedAttributeCertsDER` غير فارغ. يؤدي ملء كليهما إلى إنشاء تسلسل `SignerAttributeV2` يحمل `[0]` و `[1]` بترتيب مطابق للمواصفات.
  • تنسيق ASN.1 DER (لـ `CertifiedAttributesV2` فقط): A1 30 حيث يمثل كل ACn التسلسل AttributeCertificate كما تم توفيره من قبل المتصل. يتم حل الاختيار بين AttributeCertificate و OtherAttributeCertificate بناءً على إدخال DER المقدم من المتصل (يبدأ كلا البديلين بتسمية SEQUENCE وهي 0x30؛ لا يقوم THotPDF بالتحقق من التفاصيل الداخلية).
  • يقوم الم wrapper الخاص بـ `HPDFCMSBuildSignedData` ذي المعاملات الأربعة بتهيئة الحقل الجديد إلى الصفر، وذلك لضمان بقاء حزم CMS القديمة متطابقة تمامًا من حيث البايت مع الإصدار v2.119.27.
  • النطاق: عمليات التحقق الموقعة [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 (معرف الكائن 0.4.0.19122.1.1، ETSI EN 319 122-1 §5.2.6)، مما يسمح للموقع بالإعلان عن الأدوار المعلنة (مثل "المدير المالي" أو "الممثل المفوض") داخل حزمة CMS. يحل هذا الإصدار محل signerAttr (RFC 5126 §5.10) القديم، والذي تم إيقافه، للتوقيعات الجديدة.
  • تمت إضافة سجل `THPDFClaimedRole` جديد: `RoleOID` (معرف نوع السمة بتنسيق النقطة، عادةً ما يكون معرف دور تنظيمي أو `1.3.6.1.5.5.7.20.1 id-id-aa-PERMrole`) + `RoleValue` (سلسلة UTF-8 تحمل تسمية الدور التي يمكن قراءتها).
  • تمت إضافة حقل جديد `THPDFCMSSignOptions`. `ClaimedRoles`: مصفوفة من `THPDFClaimedRole`. تدعم هذه الخاصية وجود أدوار متعددة، حيث يصبح كل دور سمة (`Attribute`) داخل التسلسل `claimedAttributes [0]`. المصفوفة الفارغة (الافتراضية) تقمع هذه السمة، مما يحافظ على الاستقرار على مستوى البايت للإصدار 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 }. يشير التسمية التوضيحية إلى أن القيمة 0xA0 تغلف التسلسل الداخلي SEQUENCE OF حرفيًا (يتم الحفاظ على التسمية التوضيحية الداخلية 0x30).
  • تم ترميز نص OID يدويًا: 04 00 81 95 32 01 01 (قوس 0.4.0.19122.1.1؛ نظام العد الأساس 128). يمكن استخدام القيم المخصصة المستقبلية لدالة CMSEncodeOIDFromString بدءًا من الإصدار v2.120.1.
  • **النطاق:** فقط تم تنفيذ `claimedAttributes [0]` في هذه المرحلة. تتطلب `certifiedAttributesV2 [1]` (شهادات السمات X.509 وفقًا لـ RFC 5755) و `signedAssertions [2]` (رموز على غرار SAML / JWT) آليات إضافية وتظل خارج النطاق حتى ظهور طلب ملموس.
  • يقوم الغلاف `HPDFCMSBuildSignedData` ذو المعاملات الأربعة بتهيئة الأصفار لطول `ClaimedRoles` بحيث تظل حزم CMS القديمة متطابقة تمامًا مع الإصدار v2.119.27.
  • وفقًا لمعايير ETSI EN 319 122-1 V1.2.1 §5.2.6 بالإضافة إلى EN 319 142-1 V1.2.1، الجدول 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) داخل المجموعة [1] IMPLICIT unsignedAttrs في SignerInfo. يوفر مسار signature-time-stamp لخدمة الوقت الموثوقة PAdES-B-T (الجدول 1: يجب توفير B-T عبر signature-time-stamp أو document-time-stamp).
  • تمت إضافة نوع جديد من الدوال المجهولة `THPDFCMSTimestampCallback`: `reference to function(const SigValueSHA256: TBytes): TBytes`. تستدعي HotPDF هذه الدالة مع قيمة SHA-256 لـ `SignerInfo.signatureValue` (وهي بصمة الرسالة وفقًا لـ RFC 3161، القسم 2.4.2)، وتُضمّن رمز الطابع الزمني DER الذي تم إرجاعه كقيمة للسمة.
  • تمت إضافة حقل جديد `THPDFCMSSignOptions` باسم `GetSignatureTimeStamp`. القيمة الافتراضية هي `nil`، مما يعني عدم وجود طابع زمني. في حالة استخدام استدعاءات PAdES-B-T، يتم تعيين دالة تقوم بتنفيذ التفاعل مع خادم TSA وفقًا لـ HTTP/RFC 3161 وإرجاع بايتات الطابع الزمني (TST). إذا تم إرجاع بايتات فارغة، فسيتم تخطي العملية دون حدوث خطأ (على سبيل المثال، إذا كان خادم TSA غير متاح، ولكن يجب إنشاء التوقيع).
  • تظل معالجة الشبكة والمصادقة وحسابات TSA في التعليمات البرمجية الخاصة بالمُستدعي؛ بينما تقوم HotPDF فقط بتمرير النتيجة إلى `unsignedAttrs`. يتوافق هذا بشكل طبيعي مع حجم الحقل المحدد مسبقًا `AddPAdESSignatureField(Profile='B-T', ContentsBytes >= 16384)`.
  • في تنسيق ASN.1، التسلسل `SignerInfo` يحمل الآن اختياريًا مجموعة `[1] IMPLICIT SET OF Attribute` (الوسم `0xA1`) تحتوي على سمة `signature-time-stamp`، وقيمتها هي `TimeStampToken ContentInfo` التي يوفرها المستخدم كما هي.
  • تُعدِّل هذه المجموعة من الأدوات المساعدة `HPDFCMSBuildSignedData` التي تتطلب 4 وسائط، قيمة `GetSignatureTimeStamp` لتكون `nil`، وذلك للحفاظ على تطابق الحزم القديمة من نوع CMS على مستوى البايت.
  • وفقًا لـ RFC 3161 §6 بالإضافة إلى ETSI EN 319 122-1 §5.3 + EN 319 142-1، الإصدار 1.2.1 §6.3 الجدول 1 ملاحظة q (يمكن لـ B-T استخدام إما ختم الوقت أو ختم المستند للوقت الموثوق).

2026-05-23 Version 2.120.2

  • تأكيد الالتزام (commitment-type-indication) في PAdES CMS: تمت إضافة دعم للسمة (SignedAttribute) (مرحلة PAdES الثالثة): يتم إصدار السمة `id-aa-ets-commitmentType` (معرف الكائن 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` (ستة معرفات قياسية `id-cti-ets-*` من RFC 5126 §5.11.1، نطاق `1.2.840.113549.1.9.16.6.{1..6}`)، و `ctCustom` (يوفر المستخدم معرف OID اختياري عبر الحقل الجديد `CommitmentTypeOID`).
  • التفعيل: يتم إصداره في كل مرة عندما `THPDFCMSSignOptions.CommitmentType` ليس `ctNone`. الإعداد الافتراضي الفارغ يحافظ على استقرار مستوى البايت في الإصدار v2.120.1 للمستخدمين الذين لم يختاروا التفعيل.
  • **مسؤولية المتصل (PAdES الجزء 1 §6.3 الجدول 1 ملاحظة د):** عند إرسال إشارة نوع الالتزام، يجب ألا يكون إدخال `‎/Reason` في قاموس التوقيع (mutual exclusion). لا يراقب HPDFCMS حالة قاموس التوقيع، بل يختار المتصل أحد الخيارين إما عن طريق استخدام `AddPAdESSignatureField(Reason='', ...)` بالإضافة إلى `CommitmentType` أو عن طريق ترك `CommitmentType=ctNone` وتوفير `Reason`.
  • بنية ASN.1 DER: CommitmentTypeIndication SEQUENCE { commitmentTypeId OBJECT IDENTIFIER }. تم حذف CommitmentTypeQualifier (RFC 5126 §5.11.2) نظرًا لأن ستة معرفات الكائنات القياسية id-cti-ets-* لا تحدد المؤهلات. يمكن للالتزامات المخصصة التي تتطلب مؤهلات توسيع الوحدة المساعدة.
  • تقوم الدالة `HPDFCMSBuildSignedData` التي تأخذ 4 وسائط بتهيئة قيمة الحقل الجديد `CommitmentType` إلى الصفر، وذلك لضمان بقاء حزم CMS القديمة متطابقة تمامًا من حيث البايت مع الإصدار v2.119.27.
  • وفقًا لمعايير ETSI EN 319 122-1 §5.2.3 بالإضافة إلى RFC 5126 §5.11 و ETSI EN 319 142-1 V1.2.1 §6.3، الجدول 1، ملاحظة د.

2026-05-23 Version 2.120.1

  • تدعم سمة SignedAttribute (مرحلة PAdES الثانية): تقوم بإصدار السمة `id-aa-ets-sigPolicyId` (معرف الكائن 1.2.840.113549.1.9.16.2.15، وفقًا لـ ETSI EN 319 122-1 §5.2.9 و RFC 5126 §5.8) والتي تحدد سياسة التوقيع المستخدمة لإنشاء التوقيع. هذه السمة مطلوبة في PAdES-E-EPES (الجزء 2، الإصدار V1.2.1، الجدول 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 للمستند السياسي).
  • التفعيل: يتم إصدار سمة السياسة فقط عندما يتم تعبئة كل من `SignaturePolicyOID` و `SignaturePolicyHash` بواسطة المستخدم. القيم الافتراضية الفارغة تعني أن السمة يتم إخفاؤها - تظل التوقيعات الأساسية ثابتة على مستوى البايت مع الإصدار v2.120.0.
  • تمت إضافة وظيفة مساعدة جديدة `CMSEncodeOIDFromString` تقوم بترميز معرفات الكائنات (OIDs) بتنسيق النقطة المتقطعة إلى تنسيق DER وفقًا لـ X.690 §8.19 (حيث يتم دمج القوسين الأولين على أنه `40*arc1 + arc2`، وتستخدم الأقواس اللاحقة نظام العد الأساس 128 مع بتات الاستمرار). معرفات الكائنات الخاصة بالسياسات خاصة بالعمليات التجارية، وبالتالي لا يمكن للمنتج ترميزها كقيم حرفية بايت.
  • بنية ASN.1 DER: SignaturePolicyId SEQUENCE { sigPolicyId OBJECT IDENTIFIER, sigPolicyHash OtherHashAlgAndValue [, sigPolicyQualifiers SEQUENCE OF SigPolicyQualifierInfo] }. المؤهل SPuri يغلف عنوان URL كسلسلة IA5 (علامة 0x16) داخل SigPolicyQualifierInfo.
  • التوافق: إصدار v2.120.0 يضمن أن المكالمات التي لم تملأ الحقول الجديدة للسياسة تنتج مخرجات متطابقة تمامًا. تقوم الدالة `HPDFCMSBuildSignedData` ذات المعاملات الأربعة بتهيئة الحقول الجديدة إلى الصفر، مما يحافظ على سلامة حزم 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

  • تمت الآن مطابقة سمة نظام إدارة الهويات الأساسي (CMS) لمعيار PAdES (PAdES Phase 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 Table 1 هذه السمة على أنها يجب توفيرها لجميع المستويات الأساسية (B-B / B-T / B-LT / B-LTA).
  • تم الآن استبعاد السمة `signing-time` الخاصة بـ CMS افتراضيًا في معيار PAdES الأساسي. تحدد الجدول 1 أن الحد الأقصى للعدد هو 0 لملفات التعريف الأساسية (يتم حمل وقت التوقيع المعلن بواسطة إدخال `Signature Dictionary /M` وفقًا للملاحظة g في الجدول 1). تضمنت الإصدار السابق v2.119.27 السمة `signing-time` بغض النظر عن ملف التعريف، وهو ما ترفضه أدوات التحقق الصارمة من PAdES (مثل EU DSS ووضع PAdES الأساسي في Adobe Acrobat).
  • تمت إضافة واجهة برمجة تطبيقات (API) عامة جديدة: `THPDFPAdESLevel` (تحتوي على 8 قيم تغطي المستويات الأساسية B-B / B-T / B-LT / B-LTA، والمستويات المتقدمة E-BES / E-EPES / E-LTV، والنسخ القديمة `adbe.pkcs7`)، و`THPDFCMSSignOptions` (تتضمن مستوى التوقيع، ووقت التوقيع، وخيارات الشهادة v2، وختم زمني بتوقيت عالمي منسق)، و`HPDFCMSDefaultOptions(Level)` (مساعد يقوم بإرجاع القيم الافتراضية المتوافقة مع المواصفات لكل مستوى)، و`HPDFCMSBuildSignedDataEx` (أداة إنشاء CMS تعتمد على الخيارات).
  • التوافق مع الإصدارات السابقة: تم الحفاظ على توقيع `HPDFCMSBuildSignedData` ذي الأربعة معاملات في الإصدار v2.119.27 كطبقة تغليف خفيفة، ويصدر مخرجات متطابقة تمامًا من حيث البايت (شهادة التوقيع v2 غير موجودة، ووقت التوقيع كما هو مطلوب). تظل الاختبارات التي تقوم فيها التطبيقات بعمل تجزئة (hash) لحزمة CMS في الإصدار v2.119.27 خالية من الأخطاء.
  • تم تغيير سلوك الإخراج الموقّع لملفات PDF: أي استدعاء لـ `THotPDF.SignPDFWithPFX` مقابل عنصر نائب PAdES (باستخدام `AddPAdESSignatureField`، و `SubFilter ETSI.CAdES.detached`) ينتج الآن توقيعات تجتاز اختبارات التحقق الصارمة لـ PAdES. يجب على المستخدمين الذين يرغبون في استخدام مجموعة السمات القديمة v2.119.27 استدعاء `HPDFCMSBuildSignedDataEx` مباشرةً باستخدام `HPDFCMSDefaultOptions(palLegacy_adbePkcs7)`.
  • بنية ASN.1 DER وفقًا لـ RFC 5035 §3: `SigningCertificateV2 SEQUENCE { certs SEQUENCE OF ESSCertIDv2 }` مع خوارزمية SHA-256 AlgorithmIdentifier المحذوفة (قاعدة DER الافتراضية في X.690 §11.5)، وهاش الشهادة SHA-256، و`IssuerSerial` الذي يعيد استخدام استخراج مُعرّف الجهة المصدرة والرقم التسلسلي الحالي من `CMSExtractIssuerAndSerial`.
  • وفقًا لمعيار 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) هي الثامنة بين اللغات الهندية المسجلة. تم إضافة طريقتين جديدتين إلى THotPDF: ApplySinhalaReorder و GetSinhalaCategory.
  • تتضمن ميزات السنهالية: وجود حرف "Repha" (Ra=U+0DBB + Halant=U+0DCA AL-LAKUNA). كما تتضمن ثلاثة أحرف أساسية (E=U+0DD9, EE=U+0DDA, AI=U+0DDB) - وهي فريدة من نوعها بوجود ثلاثة أحرف أساسية. بالإضافة إلى ذلك، توجد 3 أحرف مقسمة (U+0DDC O, U+0DDD OO, U+0DDE AU) مع تجزئة Unicode قياسية؛ حيث أن U+0DDD OO تتكون من ثلاثة أجزاء (E + AA + AL-LAKUNA).
  • يقوم مُوَجِّه `ApplyIndicReorder` الآن بمعالجة اللغة السنهالية بشكل تلقائي (تم الآن تسجيل أنظمة الكتابة الهندية في مصفوفة ذات عناصر من 0 إلى 7).
  • تمت إضافة 21 اختبارًا جديدًا لـ DUnitX. إجمالي عدد الاختبارات التي اجتازت هو 187 من 187 اختبارًا على أنظمة Win32 و Win64.
  • وفقًا لمعيار Unicode 16.0 §12.11 (اللغة السنهالية) ومواصفات تشكيل اللغة السنهالية في OpenType.

2026-05-23 Version 2.119.76

  • تمت إضافة أداة تشكيل اللغة المالايالامية (المرحلة 8f.7). أصبحت اللغة المالايالامية ('mlym'، U+0D00-U+0D7F) هي السابعة من اللغات الهندية المسجلة. تم إضافة طريقتين جديدتين إلى THotPDF: ApplyMalayalamReorder و GetMalayalamCategory.
  • تتضمن ميزات اللغة المالايالامية: وجود حرف "Repha" (حيث Ra = U+0D30 + Halant = U+0D4D، أي CHANDRAKKALA). حرف "I-matra" (U+0D3F) يتبع الحرف الأساسي، مثل اللغة التاميلية (وهو فريد مقارنةً باللغات Devanagari/Bengali/Gujarati التي تستخدم قاعدة أساسية قبل الحرف). وجود قواعد أساسية للأحرف "E/EE/AI". ثلاثة أحرف "matras" منفصلة (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).
  • تمت إضافة 21 اختبارًا جديدًا لـ DUnitX، بما في ذلك تغطية الفئة chillu/DOT-REPH. إجمالي عدد الاختبارات التي اجتازت هو 166 من 166 اختبارًا على أنظمة Win32 و Win64.
  • وفقًا لمعيار Unicode 16.0 §12.10 (اللغة المالايالامية) ومواصفات تشكيل النص المالايالامية في OpenType.

2026-05-23 Version 2.119.75

  • تمت إضافة دعم للغة الكانادا (خطة عمل محرك GSUB المرحلة 8f.6). أصبحت لغة الكانادا ('knda'، U+0C80-U+0CFF) السكريبت الهندي السادس المسجل. تم إضافة طريقتين عامتين جديدتين، وهما ApplyKannadaReorder وGetKannadaCategory، إلى واجهة THotPDF.
  • في اللغة الكانادا، توجد أحرف Repha (مثل Ra=U+0CB0 + Halant=U+0CCD) على غرار اللغات الديفاناغاري/البنغالية/الغوجاراتية/التيلجو. مثل اللغة التيلجو، لا تحتوي اللغة الكانادا على أحرف علوية أساسية؛ كل حرف علوي في اللغة الكانادا يقع فوق القاعدة أو تحتها أو بعدها أو مقسمًا.
  • تم تقسيم خمسة أحرف "matra" باستخدام التحلل القياسي Unicode 16.0: 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، بما في ذلك جميع حالات "split-matra" الخمس، بالإضافة إلى اختبار مخصص للتحقق من "three-part-OO". إجمالي عدد الاختبارات التي تم اجتيازها هو 145 من 145 اختبارًا على أنظمة Win32 و Win64.
  • وفقًا لمعيار Unicode 16.0 §12.9 (اللغة الكانادا) ومواصفات تشكيل النص بلغة OpenType للغة الكانادا.

2026-05-23 Version 2.119.74

  • تمت إضافة دعم للغة التيلجو (خطة عمل محرك GSUB، المرحلة 8f.5). أصبحت لغة التيلجو ('telu'، U+0C00-U+0C7F) هي السكربت الهندية الخامسة المسجلة. تم إضافة طرق عامة جديدة وهي ApplyTeluguReorder وGetTeluguCategory في THotPDF.
  • في لغة التيلجو، توجد أحرف تشبه Repha (حيث Ra=U+0C30 + Halant=U+0C4D) كما هو الحال في لغات ديناغاري/البنغالية/الغوجاراتية. على عكس جميع السكريبتات الهندية السابقة: لا توجد علامات تشكيل أساسية؛ كل علامة تشكيل في لغة التيلجو تكون إما فوق الأساس، أو أسفل الأساس، أو مقسمة.
  • فوق الحروف الأساسية (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).
  • تم تقسيم علامة "matra" إلى: U+0C48 (AI) والتي تتحلل إلى U+0C46 (حرف "E" فوق القاعدة) + U+0C56 (علامة طول "AI" أسفل القاعدة) أثناء إعادة الترتيب.
  • يقوم مُوَجِّه `ApplyIndicReorder` تلقائيًا بتحديد لغة التيلوجو من خلال سجل النظام (الآن array[0..4]).
  • الاختبارات: تمت إضافة 17 حالة اختبارية جديدة باستخدام DUnitX. إجمالي عدد الاختبارات التي اجتازت هو 124 من 124 اختبارًا على أنظمة Win32 و Win64.
  • وفقًا لمعيار Unicode 16.0 §12.8 (لغة التيلوجو) ومواصفات تشكيل لغة التيلوجو في OpenType.

2026-05-23 Version 2.119.73

  • تمت إضافة دعم للغة التاميلية (خطة عمل محرك GSUB، المرحلة 8f.4). أصبحت التاميلية ('taml'، U+0B80-U+0BFF) هي السكريبت الهندية الرابعة المسجلة. تم إضافة طرق عامة جديدة، وهما ApplyTamilReorder وGetTamilCategory، في THotPDF.
  • تختلف اللغة التاميلية عن غيرها من اللغات الهندية-آرية في النقاط التالية: لا يوجد حرف "Repha" (في اللغة التاميلية، لا يتم تكوين حرف "Repha" بصريًا تقليديًا). حرف "I-matra" (U+0BBF) يوضع بعد الحرف الأساسي، وهو فريد من نوعه بين اللغات الهندية-آرية. حرف "II" (U+0BC0) يوضع فوق الحرف الأساسي. حروف "E/EE/AI" (U+0BC6-U+0BC8) توضع قبل الحرف الأساسي. توجد ثلاثة أنواع من حروف "matra" المقسمة (U+0BCA O = U+0BC6+U+0BBE، U+0BCB OO = U+0BC7+U+0BBE، U+0BCC AU = U+0BC6+U+0BD7).
  • في اللغة التاميلية، يُشار إلى Halant بالاسم PULLI عند U+0BCD. `ApplyIndicReorder` يقوم الموزع تلقائيًا باكتشاف اللغة التاميلية من خلال سجل النظام (الآن في array[0..3]).
  • الاختبارات: تمت إضافة 20 حالة اختبارية جديدة من نوع DUnitX. إجمالي عدد الاختبارات هو 107، وجميعها اجتازت بنجاح على أنظمة Win32 وWin64.
  • وفقًا لمعيار Unicode 16.0 §12.7 (لغة التاميلية) ومواصفات تشكيل النص التاميلية لـ OpenType.

2026-05-23 Version 2.119.72

  • تمت إضافة أداة تشكيل اللغة الغوجاراتية (خريطة طريق محرك GSUB، المرحلة 8f.3). أصبحت اللغة الغوجاراتية ('gujr'، U+0A80-U+0AFF) ثالث نظام كتابة هندية مسجل بعد الديفاناغاري والبنجابية. تم إضافة طرق عامة جديدة ApplyGujaratiReorder و GetGujaratiCategory إلى THotPDF.
  • إعادة ترتيب القواعد: القاعدة 1: Repha (Ra=U+0AB0 + Halant=U+0ACD)، القاعدة 2: ما قبل الأساس (U+0ABF I)، القاعدة 3: فوق الأساس (U+0AC5 CANDRA E، U+0AC7 E، U+0AC8 AI - لاحظ أن "فوق الأساس" في اللغة الغوجاراتية مشابه للغة الديفاناغاري، وليس "ما قبل الأساس" مثل البنغالية)، القاعدة 4: تحت الأساس (U+0AC1-U+0AC4، U+0AE2-U+0AE3)، القاعدة 5: بعد الأساس (U+0ABE AA، U+0AC0 II، U+0AC9 CANDRA O، U+0ACB-U+0ACC O/AU). لا توجد علامات تشكيل منفصلة.
  • يقوم مُوَجِّه `ApplyIndicReorder` تلقائيًا بتضمين لغة الغوجاراتية من خلال سجل `IndicScripts` (الذي أصبح الآن مصفوفة [0..2]). تتيح عمليات الدمج مع `BuildUnicode*FieldContent`، جنبًا إلى جنب مع `sfIndicShaping`، دعمًا للغة الغوجاراتية دون الحاجة إلى أي تغييرات في عمليات الدمج.
  • الاختبارات: تمت إضافة 18 حالة اختبار جديدة باستخدام DUnitX، بما في ذلك تغطية R3 تتجاوز الأساس لتحديد كيفية تعامل لغة الغوجاراتية مع الأحرف "E/AI" مقارنة بلغة البنغالية. إجمالي عدد الاختبارات هو 87، وجميعها اجتازت بنجاح على أنظمة Win32 وWin64.
  • وفقًا لمعيار Unicode 16.0 §12.6 (لغة غوجاراتي) ومواصفات تشكيل خط غوجاراتي لـ OpenType.

2026-05-23 Version 2.119.71

  • تمت إضافة أداة تشكيل اللغة البنغالية (خريطة طريق محرك GSUB، المرحلة 8f.2). اللغة البنغالية ('beng'، U+0980-U+09FF) أصبحت ثاني نظام كتابة هندية مسجل بعد نظام كتابة ديوناغاري. تم إضافة طرق عامة جديدة وهي ApplyBengaliReorder و GetBengaliCategory في واجهة برمجة التطبيقات (API) الخاصة بـ THotPDF، وهي تماثل واجهة برمجة التطبيقات (API) الخاصة بنظام كتابة ديوناغاري في المرحلة 8e.
  • قواعد إعادة ترتيب البنغالية: 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` البنغالية جنبًا إلى جنب مع الديواني، دون أي تغييرات في التكامل.
  • الاختبارات: تمت إضافة 18 حالة اختبارية جديدة من نوع DUnitX تغطي خصائص Bengali R1/R2/R4/R5، والتحليل، والحفاظ على الأحرف المركبة، ونقل النصوص المختلطة، والخاصية التكرارية، وتكافؤ الموزع. إجمالي عدد الاختبارات الناجحة هو 69 من 69 اختبارًا على أنظمة Win32 وWin64.
  • وفقًا لمعيار Unicode 16.0 §12.2 (البنغالية) ومواصفات تشكيل البنغالية لـ OpenType.

2026-05-23 Version 2.119.70

  • تم تحديث نظام تشكيل نص Devanagari (خريطة طريق محرك GSUB، المرحلة 8f.1): تم الآن تطبيق قاعدة إعادة الترتيب الكاملة المكونة من 5 قواعد (`ApplyDevanagariReorder`) بدلاً من المجموعة الفرعية المكونة من R1 و R2 فقط الموجودة في الإصدار v2.119.55. يتم الآن ترتيب المجموعات بناءً على المقاطع الصوتية: `[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 pre-base I-matra (وهي مجموعة فرعية من الإصدار v2.119.55) إلى إخراج مطابق تمامًا من حيث البايت.
  • تمت إضافة 8 حالات اختبار جديدة من نوع DUnitX تغطي بشكل فردي R3 و R4 و R5، وترتيب الأحرف المتعددة، والحفاظ على الأحرف المركبة تحت الأحرف المتعددة، ومزيج من Repha والأحرف الموجودة فوقها وتحتها، بالإضافة إلى خاصية التكرار للأحرف المتعددة. إجمالي عدد الاختبارات التي تم اجتيازها هو 51 من 51 اختبارًا على أنظمة Win32 و Win64.
  • وفقًا لمعيار Unicode 16.0 §12.1 (Devanagari) ومواصفات تشكيل Devanagari الخاصة بـ OpenType.

2026-05-23 Version 2.119.69

  • تمت إعادة هيكلة الوحدة v2.119.55 / v2.119.67 الخاصة بترتيب الأحرف الديفاناغاري في المرحلة 8f.0 من خريطة طريق البنية التحتية لتشكيل الأحرف الهندية، وتحويلها إلى إطار عمل موحد ومستقل عن البرامج النصية. تم إضافة أنواع جديدة وهي `TIndicScriptInfo` / `TIndicCategoryFunc` / `TIndicFindSyllableFunc` / `TIndicReorderFunc`، بالإضافة إلى سجل جديد باسم `IndicScripts`، مما يتيح للبرامج النصية الهندية القادمة التكامل من خلال مؤشرات الدوال.
  • تمت إضافة طريقة عامة جديدة `ApplyIndicReorder(Wide)` تقوم بتمرير كل نقطة رمز في `Wide` إلى البرنامج النصي المسجل المطابق وتطبيق استدعاءات البرنامج النصي الخاصة بالسيلاب + إعادة الترتيب. يتم تمرير المحتوى غير الهندي كما هو دون تغيير.
  • أصبحت الآن الدالات المساعدة الثلاث `BuildUnicode*FieldContent` تستدعي `ApplyIndicReorder` (بدلاً من الغلاف المخصص للغة Devanagari فقط) عندما تكون `sfIndicShaping` موجودة في `FShapingFeatures`. الإصدار 8f.0 يتضمن دعمًا للغة Devanagari فقط؛ بينما تضيف الإصدارات اللاحقة 8f.2 إلى 8f.10 دعمًا للغات البنغالية، والجوجاراتية، والتاميلية، والتيلجو، والكانادا، والماليالامية، والسينغالية، والكيمرية، والبورمية، دون تغيير هذا التكامل.
  • تم الحفاظ على الأمر `ApplyDevanagariReorder` الموجود كطبقة تغليف خاصة باللغة Devanagari فقط لضمان التوافق مع الإصدارات السابقة v2.119.55. لم تتغير المخرجات من الإصدار v2.119.67.
  • وفقًا لمعيار Unicode 16.0 §12 (الخطوط الهندية الجنوبية) و ISO 32000-1 §9.10.

2026-05-22 Version 2.119.68

  • المرحلة 8c.6 - إرسال رموز GID على مستوى المنتج من خلال تعيين نقاط الترميز التركيبية في منطقة الاستخدام الخاصة: توفر واجهة THotPDF الآن طريقتين عامتين جديدتين تسمحان للمستخدمين بإرسال رموز GID بديلة ليس لها نقطة ترميز Unicode طبيعية، وذلك عن طريق تخصيص نقاط ترميز PUA (U+E000-U+F8FF) عند الطلب. تقوم الدالة AssignSyntheticCodepointForGID (GID; out SyntheticCP): Boolean بتخصيص المساحة المتاحة التالية في PUA، وتعكس هذا التعيين في جداول FUnicodeCpToGid و FAcroFormUnicodeAdvances بالإضافة إلى جدول بحث جديد FUnicodeSyntheticCpForGID لكل رمز GID، بحيث يقوم مسار ترميز السداسي العشري الحالي على جانب المنتج بإرسال نقطة الترميز التركيبية كرمز سداسي عشري مكون من 4 أرقام، والتي يقوم برنامج القراءة الخاص بالمستهلك بحلها من خلال /CIDToGIDMap إلى الرمز البديل. تقوم الدالة GetSyntheticCodepointForGID (GID): Word بالاستعلام عن التعيينات الموجودة (وتعيد القيمة 0 عندما لا يكون هناك تعيين تركيبي). كلا الطريقتين لهما نفس التأثير - فإن استدعاءات متكررة بنفس رمز GID ستعيد نفس نقطة الترميز التركيبية.
  • يفتح هذا الإصدار إمكانية إخراج بدائل GSUB الخاصة بالخطوط والتي لا تحتوي على نقاط ترميز Unicode Presentation Form: مثل أشكال التجمعات في خط Devanagari (غالبًا ما تظهر مخرجات 'akhn' / 'rphf' / 'pres' / 'blws' / 'psts' / 'haln' على GIDs الداخلية للخط)، والبدائل الأسلوبية ('salt' / 'ss01-20' بدون نقاط ترميز)، والربطات الاختيارية ('dlig' / 'hlig' وهي أحرف خاصة بالخط)، وبدائل تسلسل الأحرف الأيضائية CJK. وبالتزامن مع واجهات برمجة تطبيقات محرك GSUB v2.119.43-50 ووحدة التجميع MarkUnicodeGlyphUsed v2.119.50، يمكن للمستخدمين الآن إنشاء مسارات تشكيل كاملة من جانب المنتج، والتي تُخرج معرفات أحرف بديلة (GIDs) عشوائية من خلال مسار hex القائم على نقاط الترميز الحالية.
  • تستمر الخرائط الاصطناعية حتى يتم استدعاء `RegisterUnicodeTTF` مرة أخرى أو يتم بدء المستند (كلا الإجراءين يعيد تهيئة حالة الخط). يوفر نطاق PUA `U+E000-U+F8FF` 6400 فتحة، وهو ما يكفي لأي مجموعة استبدال `GSUB` عملية للخط. يقع على عاتق المتصل مسؤولية إنشاء خريطة عكسية لـ `ToUnicode`؛ لا تحتوي نقاط الرمز PUA الاصطناعية على نقاط رمز مصدر يمكن عكسها؛ يجب على المتصلين الذين يشعرون بالقلق بشأن استخراج النص تضمين النص المنبعث في المحتوى المسمى في PDF باستخدام خاصية `/ActualText` لتحديد نقاط الرمز المصدر الأصلية. تنتج ملفات PDF التي لا يستدعي فيها المتصل `AssignSyntheticCodepointForGID` مخرجات متطابقة تمامًا مع إصدار `v2.119.67` (الطرق الجديدة هي مساعدات استعلام غير متزامنة / تخصيص صريح؛ لا توجد آثار جانبية تلقائية). يكمل هذا التغيير مصفوفة إمكانيات المرحلة 8 لخريطة عمل محرك `GSUB`.

2026-05-22 Version 2.119.67

  • إعادة ترتيب Devanagari وتطبيقها تلقائيًا (خطة تطوير محرك GSUB المرحلة 8e): الآن، تستدعي الوظائف الثلاث `BuildUnicode*FieldContent` تلقائيًا طريقة `ApplyDevanagariReorder` الإصدار v2.119.55 عندما يتم تضمين `sfIndicShaping` في `FShapingFeatures`. تقوم هذه العملية بفحص الإدخال من اليسار إلى اليمين، وتطبق عمليتي إعادة ترتيب خاصتين بـ Devanagari (نقل حرف Ra-Halant في بداية المقطع، وتحريك حرف I-matra U+093F إلى بداية مجموعة المقاطع الخاصة به) بحيث يتطابق تدفق نقاط الترميز الناتجة مع ترتيب القراءة المرئي. ثم يقوم محرك GSUB الخاص بقارئ المستهلك بتطبيق سلسلة تشكيل Indic ('nukt' / 'akhn' / 'rphf' / 'rkrf' / 'pref' / 'half' / 'vatu' / 'cjct' / 'pres' / 'blws' / 'abvs' / 'psts' / 'haln') على نقاط الترميز المعاد ترتيبها لإنتاج الرموز النهائية للمجموعات.
  • النطاق: الإصدار 8e يوفر فقط إعادة الترتيب من جانب المُنتج. تطبيق سلاسل GSUB من جانب المُنتج (حيث يقوم المُنتج بتحديد شكل المجموعة في وقت إخراج PDF بدلاً من الاعتماد على القارئ) مؤجل للإصدار 8c.6 لأن معظم بدائل GSUB الخاصة باللغة Devanagari تستخدم معرفات GID خاصة بالخط ولا تحتوي على نقطة رمز Unicode Presentation Form. على عكس اللغة العربية/اللاتينية حيث توفر مجموعات Forms-A/Forms-B بدائل يمكن الوصول إليها من خلال نقاط الرمز، لا توجد نطاقات Presentation Form مكافئة للغة Devanagari في Unicode. سيؤدي تعيين نقطة رمز PUA الاصطناعية في الإصدار 8c.6 إلى تمكين إخراج GSUB من جانب المُنتج للغة Devanagari واللغات الهندية/جنوب شرق آسيا الأخرى حيث تكون معرفات GID الخاصة بالبدائل خاصة بالخط.
  • تمرر المحتوى غير المكتوب بالخط Devanagari عبر `ApplyDevanagariReorder` دون أي تغيير في البايتات (الطريقة تتعامل فقط مع مقاطع Devanagari؛ يتم إخراج نطاقات نقاط الترميز الأخرى دون تغيير). ملفات PDF التي لا يقوم فيها المستخدمون بتفعيل `sfIndicShaping` (وهو الإعداد الافتراضي) تنتج مخرجات متطابقة تمامًا مع إصدار v2.119.66. بالإضافة إلى طبقة الإمكانات v2.119.55 (التي تتضمن `GetDevanagariCategory` و `ApplyDevanagariReorder` كطرق عامة)، يكمل هذا التغيير تكامل إعادة ترتيب Devanagari من جانب المنتج: لم يعد المستخدمون الذين يقومون بتفعيل `sfIndicShaping` بحاجة إلى إعادة الترتيب مسبقًا أو استدعاء `ApplyDevanagariReorder` يدويًا قبل `BuildUnicode*FieldContent` — يقوم HotPDF بذلك تلقائيًا.

2026-05-22 Version 2.119.66

  • تم دمج ميزة 'rclt' (البدائل السياقية المطلوبة) تلقائيًا في THotPDF. تعمل الطريقة الجديدة THotPDF.ApplyArabicGSUBContextualRefinement (Wide) بشكل مشابه للطريقة v2.119.63 ApplyArabicGSUBRefinement، ولكنها تطبق الاستبدال السياقي (GSUB من النوع 5/6) باستخدام واجهة برمجة التطبيقات v2.119.47 ApplyContextualSubst بدلاً من استبدال الأحرف المتصلة (النوع 4). ترمّز ميزة 'rclt' للاستبدالات المطلوبة التي تعتمد على السياق - وتستخدم عادةً في خطوط اللغة العربية لإضافة اختلافات موضعية إضافية تتجاوز خريطة Forms-B الثابتة المستخدمة في الإصدار v2.85.0، كما تستخدمها أيضًا خطوط جنوب شرق آسيا/الهند لإعادة ترتيب الأشكال على مستوى المجموعة والتي تعتمد على السياق المحيط.
  • معالجة الإخراج ذي الطول المتغير: على عكس `ApplyLigatureSubstitution` (حيث ينتج عنه حرف بديل واحد من N حرفًا)، يمكن لـ `ApplyContextualSubst` أن ينتج M حرفًا بديلاً من N حرفًا. عندما يتم تطبيق قاعدة سياقية، يجب أن تكون جميع الأحرف البديلة قابلة للوصول من خلال نقاط الترميز الخاصة بـ Unicode Presentation Form من خلال خريطة عكسية (FB00-FDFF + FE70-FEFF، يتم فحص حوالي 770 نقطة ترميز) حتى يتم تطبيق الاستبدال؛ إذا كان أي حرف بديل يفتقر إلى خريطة عكسية، فإن نافذة الإدخال تمر دون تغيير (سيؤدي الإخراج الجزئي إلى إتلاف التسلسل). تم توسيع نطاق الخريطة العكسية لتغطية أشكال العرض اللاتينية/الأرمنية/العبرية (FB00-FB4F) بالإضافة إلى النطاقات العربية الكاملة، بحيث يمكن إخراج الأحرف البديلة الخاصة بـ 'rclt' من أي نظام كتابة.
  • تمت إضافة عضو جديد إلى تعداد `THPDFShapingFeature` وهو `sfContextualAlternates` (تمت إضافته في النهاية لضمان التوافق مع الإصدارات السابقة - لن تتأثر الاستدعاءات الحالية التي تستخدم `FShapingFeatures` عند التجميع مع التعداد المكون من 5 عناصر في الإصدار v2.119.59). تم دمج هذا التغيير في ثلاث دوال مساعدة `BuildUnicode*FieldContent`، وهي مشروطة بـ `sfContextualAlternates` في `FShapingFeatures` (اختياري، القيمة الافتراضية هي "إيقاف"). هذا التغيير مستقل عن `FAutoShapeArabic` - يمكن تطبيق قاعدة `'rclt'` على نصوص غير عربية (مثل اللاتينية أو العبرية أو الهندية). يتم تمرير معرفات الأحرف البديلة عبر `MarkUnicodeGlyphUsed` لـ `subsetter` في الإصدار v2.84.0. يتم تنفيذ عملية غير مؤثرة إذا كان الخط لا يحتوي على قواعد `'rclt'` أو إذا كانت معرفات الأحرف البديلة تفتقر إلى نقاط الترميز الخاصة بـ "Presentation Form". ملفات PDF التي لا يتم فيها تفعيل `sfContextualAlternates` ستنتج نفس الإخراج تمامًا مثل الإصدار v2.119.65.

2026-05-22 Version 2.119.65

  • تقوم ميزات الربط القياسية (GSUB engine roadmap المرحلة 8ب) بإصدار ما يلي: الطريقة الجديدة THotPDF.ApplyLatinLigatureRefinement (Wide) تعمل بالتوازي مع v2.119.63 ApplyArabicGSUBRefinement ولكنها تستهدف الأشكال التقديمية الأبجدية اللاتينية / الأرمنية / العبرية في U+FB00-U+FB4F. تقوم بمعالجة السلسلة المدخلة الواسعة، وتقوم بإنشاء مصفوفة GID متوازية عبر FUnicodeCpToGid، وتستعلم عن ميزة 'liga' (الربط القياسي) في GSUB في الخط عبر واجهة برمجة التطبيقات v2.119.43-50 ApplyLigatureSubstitution في كل موضع. إذا تم تطبيق استبدال الربط ورمز النقطة البديل يمكن الوصول إليه من خلال نقطة رمز شكل أبجدي Unicode، يتم استبدال نافذة نقطة الرمز المصدر بنقطة رمز البديل. تم دمج هذا في ثلاث مساعدات BuildUnicode*FieldContent (سطر واحد، متعدد الأسطر، ومساعد بناء تدفق المظهر AcroForm /AP) مع التحكم في sfStandardLigatures في FShapingFeatures (اختياري، ومستقر من حيث البايت عند عدم التعيين).
  • تعديل اختياري للمرور الثاني لـ 'clig' (الوصلات السياقية): عندما يتم تضمين `sfContextualLigatures` أيضًا في `FShapingFeatures`، تقوم الطريقة بإعادة معالجة النتيجة بعد تطبيق 'liga' مع تطبيق 'clig' لاكتشاف وصلات سياقية خاصة بالخط تتجاوز المجموعة القياسية fi / fl / ffi / ffl. يتم تمرير كل معرف GID بديل تم إنشاؤه عبر `MarkUnicodeGlyphUsed` لـ TTF subsetter في الإصدار v2.84.0. يتم إجراء فحص خطي لعكس cmap على حوالي 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) ذاكرة التخزين المؤقت /W للإصدار v2.76.0، مما يسمح للمستخدمين الذين يقومون بإنشاء حسابات مخصصة لتقسيم الكلمات خارج الدالة المساعدة BuildUnicodeMultilineFieldContent بالاستعلام عن القيمة الفعلية للارتفاع النسبي لأي نقطة برمجية، والتي يتم اشتقاقها من جدول hmtx الخاص بالخط من خلال خريطة cmap المخزنة مؤقتًا. بعد سلسلة المعالجة اللاحقة الثابتة للروابط v2.119.32 / v2.119.58 / v2.119.60 / v2.119.62 وتحسين GSUB على مستوى GID v2.119.63، والتي تنتج نقاط برمجية للروابط (LAM-ALEF FEF5-FEFC، YEH-HAMZA FBEA-FBFB، Allah FDF2، Bismillah FDFD، والأشكال التقديمية البديلة في FB50-FDFF / FE70-FEFF)، تُرجع الطريقة القيمة الفعلية لارتفاع الرمز للرابط - والتي عادة ما تكون أضيق من مجموع قيم ارتفاع النقاط البرمجية المصدر - بحيث تتوافق ميزانيات تقسيم المستخدمين مع عملية العرض من جانب المستهلك.
  • تحسين آلية الاستبدال البديلة لإنشاء محتوى حقول Unicode متعدد الأسطر: في الإصدار v2.65، كانت مسار الاستبدال البديل (المستخدم عندما يكون ذاكرة التخزين المؤقت /W غير متوفرة، على سبيل المثال، مسار RegisterUnicodeFontDict بدلاً من RegisterUnicodeTTF) تعامل سابقًا مع جميع نقاط الترميز الأكبر من أو تساوي U+2E80 على أنها واسعة (1.0 em). في الواقع، الأحرف العربية التقديمية (FB50-FBFF Forms-A letters، FC00-FDFF Forms-A ligatures + Quranic FDF0-FDFD، FE70-FEFF Forms-B basic shapes + LAM-ALEF) هي ضيقة (~0.55 em في المتوسط عبر الخطوط العربية الشائعة)، وليست واسعة. في الإصدار v2.119.64، يتم توجيه هذه النطاقات الثلاثة من الأحرف العربية التقديمية إلى المسار الضيق (0.5 em) في آلية الاستبدال البديلة، مما يحل مشكلة خاصة حيث كانت الأحرف العربية المترابطة التي تم إنشاؤها بواسطة الإصدارات v2.119.32 / v2.119.58 / v2.119.60 / v2.119.62 / v2.119.63 كانت ستتلقى تقدمًا خاطئًا بمقدار 1.0 em عندما لا يتم ملء ذاكرة التخزين المؤقت.
  • يُرجع 0 للمسار القياسي الذي لا يوفر معلومات (لم يتم تسجيل الخط، لم يتم ملء ذاكرة التخزين المؤقت بعد، نقطة الرمز أعلى من BMP، لا توجد حرفة لنقطة الرمز في خريطة الأحرف للخط). دالة خالصة، لا توجد آثار جانبية، وآمنة للاستدعاء من أي سياق بعد نجاح RegisterUnicodeTTF. ملفات PDF التي تم تحميل الخط الخاص بها وذاكرة التخزين المؤقت /W الخاصة به ممتلئة والتي لا تستخدم طريقة الاستعلام الجديدة، تنتج مخرجات متطابقة تمامًا مع إصدار v2.119.63. تغلق المرحلة 8c.5 خريطة طريق محرك GSUB §8c، وتوفر خط أنابيب تشكيل GSUB تلقائيًا من جانب المنتج على مستوى القدرات - معًا، توفر المرحلة 8c.1-8c.5 تمريرات لاحقة لجدول ثابت (4 عائلات من الأحرف المتصلة) + تعيين عكسي ToUnicode + تحسين GSUB على مستوى GID + استعلام عام عن التقدم، وكلها تعمل معًا لجعل عرض الأحرف المتصلة باللغة العربية من جانب المنتج دقيقًا تمامًا من حيث البايت مع العرض من جانب المستهلك.

2026-05-22 Version 2.119.63

  • تحسينات على مستوى GID لـ 'rlig' في محرك GSUB (خريطة طريق محرك GSUB المرحلة 8c.2): الطريقة الجديدة `THotPDF.ApplyArabicGSUBRefinement (Wide)` تفحص السلسلة النصية الواسعة من اليسار إلى اليمين، وتقوم بإنشاء مصفوفة GID متوازية باستخدام خريطة الأحرف المخزنة مؤقتًا (FUnicodeCpToGid)، وفي كل موضع له قيمة GID غير صفرية، تستعلم عن ميزة 'rlig' (الوصلات المطلوبة) في الخط عبر واجهة برمجة التطبيقات `ApplyLigatureSubstitution` الإصدار v2.119.43-50. إذا تم تطبيق استبدال للوصلة وكان الـ GID البديل قابلاً للوصول من خلال نقطة ترميز Unicode للعرض العربي (فحص عكسي لخريطة الأحرف عبر U+FB50-U+FDFF + U+FE70-U+FEFF، أي حوالي 690 نقطة ترميز)، يتم استبدال نطاق نقطة الترميز المصدر بنقطة الترميز البديلة. يتم أيضًا تمرير الرموز البديلة عبر `MarkUnicodeGlyphUsed` لإنهاء عملية تقليل حجم ملف TTF للإصدار v2.84.0.
  • تم دمج هذا التغيير في ثلاثة مساعدين لـ BuildUnicode*FieldContent مباشرةً بعد سلسلة المعالجة الثابتة على مستوى نقاط الرموز (LAM-ALEF / YEH-HAMZA / Allah / Bismillah) للإصدارات v2.85.0 / v2.119.32 / v2.119.58 / v2.119.60 / v2.119.62. يُكمل هذا التغيير الجدول الثابت من خلال استخراج قواعد 'rlig' الخاصة بالخط، والتي لا يتم ترميزها في العائلات الأربعة المحددة مسبقًا. تتضمن الأمثلة الشائعة الاختلافات السياقية في خطوط الفارسية / الأردية / السندية / الكردية (Vazirmatn, Markazi Text, Lateef, Scheherazade, Amiri) والتي تتوافق مع أشكال العرض Unicode التي تتجاوز مجموعة LAM-ALEF / YEH-HAMZA / Allah / Bismillah. يعمل هذا فقط عندما تكون FAutoShapeArabic صحيحة و sfArabicGSUB ليست موجودة في FShapingFeatures (يضمن التناقض مسار "المدفوع من قبل المُستدعي" للإصدار v2.119.59) وأن الخط الذي تم تحميله يحتوي على جدول GSUB.
  • النطاق المحدود: يتم إخراج البدائل فقط التي يمكن الوصول إلى معرفاتها (GIDs) من خلال نقطة التعليمات البرمجية للنموذج التقديمي عبر خريطة الأحرف (cmap). لا يمكن إخراج بدائل GSUB الخاصة بالخط والتي تقع على معرفات أحرف عشوائية (بدون خريطة عكسية لنقطة التعليمات البرمجية) من خلال هذا المسار؛ فهي تحتاج إلى إخراج كامل على مستوى المعرف (GID) في خط أنابيب الإنتاج المخصص للإصدار 8c.5 والإصدارات الأحدث. تتضمن الخريطة العكسية فحصًا خطيًا لحوالي 690 نقطة تعليمات برمجية لكل محاولة استبدال؛ وعادةً ما تكون عمليات الاستبدال نادرة، لذا فإن التكلفة ضئيلة. بالنسبة لملفات PDF التي لا تحتوي على محتوى 'rlig' في GSUB في الخط الذي تم تحميله أو التي لا تحتوي بدائله على نقاط تعليمات برمجية للنموذج التقديمي، يتم إخراجها بنفس البايتات مثل إصدار 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.
  • تم توسيع خريطة CMap الخاصة بـ ToUnicode بإضافة إدخال 28th 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 حرفًا بدلاً من حرف الربط الواحد، مما يكمل سلوك "الذهاب والإياب" لعائلات حروف الربط الأربعة ذات الجداول الثابتة (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؛ وإدخال واحد لـ Allah، U+FDF2 (الإصدار v2.119.60) → تسلسل المصدر المكون من أربعة رموز: ALEF + LAM + LAM + HEH. مع هذه المجموعة، اكتملت عملية النسخ/اللصق/إمكانية الوصول ذهابًا وإيابًا للعائلات الثلاث للربط التي تعتمد على الجداول الثابتة.
  • تم تحسين الثبات لغير المحتوى العربي: يضيف كتلة "bfchar" حوالي 700 بايت من النص البرمجي غير المضغوط إلى دفق CMap، والذي تقلله عادةً عملية "FlateDecode" إلى حوالي 150-200 بايت. لا تزال ملفات PDF التي لا تحتوي على محتوى عربي تنتج نفس تخطيط الدفق "/ToUnicode" - الإضافة تتم ضمن نفس كائن دفق "FlateDecode" غير المباشر. تقوم جميع برامج القراءة (مثل Adobe Reader وFoxit وPDF.js وApple Preview) بتفضيل "bfchar" على "bfrange" وتطبق التعيين العكسي بشكل صحيح. يتم ترميز الكتلة المكونة من 27 إدخالًا بشكل ثابت في نص CMap (لا توجد حاجة إلى تخصيص لكل ملف PDF). في المرحلة المستقبلية 8c.4، سيتم إضافة إدخالات "bfchar" إضافية لربط "Bismillah" U+FDFD.

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، المرحلة 8أ): يمثل التعداد الجديد THPDFShapingFeature ونوع المجموعة THPDFShapingFeatures علامات الميزات المخطط لها لدمج تشكيل النص من جانب المنتج في المرحلتين 8أ إلى 8هـ. تتضمن أعضاء التعداد الخمسة ما يلي: sfArabicGSUB (تم تنفيذه في هذا الإصدار)، و sfStandardLigatures (المرحلة 8ب، مستقبلًا)، و sfContextualLigatures (المرحلة 8ب، مستقبلًا)، و sfStylisticAlternates (المرحلة 8د، مستقبلًا)، و sfIndicShaping (المرحلة 8هـ، مستقبلًا). اكتسبت THotPDF خاصية ShapingFeatures من النوع THPDFShapingFeatures بقيمة افتراضية وهي [] (جميع الميزات معطلة). بالنسبة للإصدار v2.119.32-58، سترى نفس المخرجات تمامًا طالما أن الخاصية تركت بقيمتها الافتراضية.
  • يعمل `sfArabicGSUB` كحاجز ضد وحدة تشكيل اللغة العربية الثابتة v2.85.0. عندما يتم تضمين `sfArabicGSUB` في `ShapingFeatures`، تتخطى الدوال الثلاث المساعدة `BuildUnicode*FieldContent` (للأحادي، والمتعدد الأسطر، وبناء تيار المظهر `AcroForm /AP` المدمج) تطبيق `_ApplyArabicShaping` بالكامل - لا يوجد إعادة كتابة نقاط الترميز الأربعة الخاصة بـ v2.85.0، ولا يوجد تمرير لاحق لـ `LAM-ALEF` الخاص بـ v2.119.32، ولا يوجد تمرير لاحق لـ `YEH-HAMZA + vowel` الخاص بـ v2.119.58. يتحمل المتصل مسؤولية التحكم في اختيار تشكيل اللغة العربية من خلال واجهات برمجة التطبيقات (APIs) الخاصة بمحرك `GSUB` v2.119.43-50 (باستخدام `SetGSUBScript ('arab')` بالإضافة إلى `GetSingleSubstituteGlyph` مقابل علامات الميزات `'init' / 'medi' / 'fina' / 'isol'` بالإضافة إلى `MarkUnicodeGlyphUsed` لإغلاق مجموعة الأحرف v2.84.0). بالاقتران مع `sfArabicGSUB`، يمكن للمتصلين الذين يستخدمون خطوط مثل `Noto Sans Arabic / Amiri / Scheherazade / Markazi Text` أو خطوط عربية مماثلة الآن التحكم في تشكيل اللغة العربية الكامل من جانب الخط في وقت الإنتاج بدلاً من الاعتماد على الحل الاحتياطي للجدول الثابت.
  • 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

  • تمت إضافة معالجة لاحقة لربط الحرف "يه-همزة" مع حرف العلة: تقوم وحدة تشكيل اللغة العربية من الجانب الخاص بالمنتج (الإصدار v2.85.0) الآن بدمج 8 أزواج من الرموز المرتبطة المشفرة في نطاق "Arabic Presentation Forms-A" (من U+FBEA إلى U+FBFB) في رموز ارتباطية واحدة، وذلك بعد معالجة "المسار ذي الأربع مواضع" والمعالجة اللاحقة لـ "LAM-ALEF" (الإصدار v2.119.32). تستخدم نفس النموذج والتكامل كما في "LAM-ALEF" (استبدال ثابت إلزامي، وإخراج شكلين لكل رمز ارتباط). الأزواج المغطاة هي: "يه-همزة" + "ألف" -> FBEA/FBEB (العربية/الفارسية/الأردية)، "يه-همزة" + "أ" (U+06D5) -> FBEC/FBED (الكشميرية/الأويغورية)، "يه-همزة" + "واو" -> FBEE/FBEF (العربية)، "يه-همزة" + "أُو" (U+06C7) -> FBF0/FBF1 (الأويغورية/الكازاخية/القرغيزية)، "يه-همزة" + "أُو" (U+06C6) -> FBF2/FBF3 (نفس الشيء)، "يه-همزة" + "يُو" (U+06C8) -> FBF4/FBF5 (نفس الشيء)، "يه-همزة" + "إ" (U+06D0) -> FBF6/FBF7 (نفس الشيء)، "يه-همزة" + "ألف مقصورة" -> 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 أو الشكل المتوسط FE8C (أي أنه يسبقه حرفان يتصلان معًا)، يتم إخراج الحرف المتصل في شكله النهائي؛ وإلا يتم إخراج الشكل المنفصل.
  • تحدد حدود النطاق: فقط الأشكال المعزولة والنهائية (إخراج ثنائي الشكل) يتم إنشاؤها بواسطة هذه المرحلة الإضافية. لا يتم إنتاج الأشكال الأولية المعرفة في Unicode وهي FBF8 (YEH-HAMZA + E) و FBFB (UIGHUR YEH-HAMZA + ALEF MAKSURA) - يجب على المستخدمين الذين يحتاجون إلى هذه المتغيرات الثلاثية استخدام عمليات بحث GSUB المتسلسلة 'rlig' / 'clig' من خلال ApplyContextualSubst. تتطلب مناطق الربط العربية الأخرى (Allah U+FDFA / FDFB، والربطات الزخرفية الموجودة في FC00-FDC7) عمليات بحث GSUB 'rlig' / 'dlig' وتظل خارج نطاق أداة التشكيل المستندة إلى الجداول الثابتة. تنتج ملفات PDF التي لا تحتوي على YEH-HAMZA متبوعة بواحد من ثمانية حروف علة مدعومة نفس النتائج تمامًا مثل الإصدار v2.119.57؛ تعمل المرحلة الإضافية الجديدة فقط على تسلسل نقاط الرمز المحدد المكون من نقطتي رمز.

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 منها على إدخالات ثابتة لـ "Presentation Forms-A" في النطاقات U+FB52-U+FBFC، ويتم الآن ربطها مباشرةً بواسطة وحدة التشكيل الثابتة دون الحاجة إلى وحدة تشكيل 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" ويتكون من شكلين (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 ذكرًا خاصًا لأن خانات "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 الذي ربط الخانات بالحروف المصدر الصحيحة، فإن سجل التدقيق نظيف وتم حل التداخل بشكل دائم. لا تزال الأحرف الموجودة في النطاق U+0672-U+06D5 والتي لا تحتوي على إدخالات "Presentation Forms-A" في Unicode 16 (حوالي 50 نقطة ترميز إضافية، وهي في الغالب أشكال مختلفة من الأحرف REH / DAL / SEEN / SAD / TAH / AIN / FEH / QAF / KAF بدون أشكال مُبرمجة مسبقًا) تشارك في تحليل فئة الربط بحيث تتشكل الأحرف المجاورة بشكل صحيح؛ تمر الأحرف نفسها كنقاط ترميز خام وتعتمد على جداول بحث GSUB الخاصة بالخط لتحديد شكلها الخاص باستخدام محرك GSUB v2.119.43-50. تم تجميعه في 78018 سطرًا؛ ملفات PDF التي لا تحتوي على نقاط الترميز الجديدة هذه تنتج نفس البايت تمامًا مثل v2.119.56.

2026-05-22 Version 2.119.56

  • تم إصلاح خطأ في تنسيق اللغة العربية: أدت النسخة v2.119.52 إلى تعيينات غير صحيحة لأحرف اللغة العربية من مجموعة "Presentation Forms-A" لحرفين من منطقة لغة الأوردو/السند. تم تعيين الحرف U+06C2 HEH GOAL WITH HAMZA ABOVE إلى FBAA-FBAD، وهو في الواقع نطاق نقاط الترميز لـ U+06BE HEH DOACHASHMEE؛ وكانت برامج القراءة سترسم حرف "الهدف-هي-مع-همزة" الأردي كحرف "هي-دو-تششمي" الأردي القياسي. تم تعيين الحرف U+06C3 TEH MARBUTA GOAL إلى FBAE-FBAF، وهو في الواقع نطاق نقاط الترميز لـ U+06D2 YEH BARREE؛ وكانت برامج القراءة سترسم حرف "تي-ماربوتا-هدف" ككلمة أردية تنتهي بـ "يه-باريه". وفقًا لمعيار Unicode 16.0، لا يحتوي أي من الحرفين U+06C2 ولا U+06C3 على إدخالات مسبقة لـ "Presentation Forms-A"؛ يجب أن يمر كلاهما دون تغيير كنقاط ترميز خام (تعرض برامج القراءة هذه الأحرف بشكل صحيح من خلال خريطة الأحرف في الخط وأي تنسيق يعتمد على GSUB).
  • تم إصلاح الإدخالات الخاطئة في جدول بحث "ArabicShape Presentation Forms-A" المستخدم في معالج اللغة العربية من جهة الإنتاج في الإصدار v2.85.0؛ تمت إزالة الإدخالات الخاطئة. الآن، تتدفق القيم U+06C2 و U+06C3 إلى مسار التمرير وتُصدر دون تغيير. تم الاحتفاظ بإدخالات فئة الربط من الإصدار v2.119.52 (D لـ U+06C2 و R لـ U+06C3) بحيث تظل الأحرف المجاورة تختار الأشكال الموضعية الصحيحة عند ظهور هذه الأحرف في كلمة. يؤثر هذا الإصلاح فقط على ملفات PDF التي تحتوي على U+06C2 أو U+06C3 مع تمكين "AutoShapeArabic". ملفات PDF التي لا تحتوي على هاتين النقطتين البرمجيتين هي نفسها تمامًا من حيث البايتات مثل إصدار v2.119.55. يوفر الإصدار المصاحب v2.119.57 تغطية موسعة لـ "Forms-A" لتشمل أحرفًا إضافية من اللغات الفارسية والأردية والسندية والكشميرية والأويغورية والكازاخستانية والكيرغيزية، بما في ذلك HEH DOACHASHMEE و YEH BARREE المشفرين بالفعل باستخدام "Forms-A" واللذين كان الخطأ في الإصدار v2.119.52 يخلطهما.

2026-05-22 Version 2.119.55

  • إمكانية تشكيل النصوص الهندية بلغة ديوناغاري: تم إضافة طريقتين جديدتين عامتين إلى THotPDF لتغطية نموذج تشكيل النصوص الهندية الذي لا يتناسب مع آلية "المتجول" المستخدمة في تحديد الفئات المكونة من أربعة مواضع، والتي تستخدم للغة العربية/السريانية/المنغولية (الإصدار v2.85.0 + v2.119.32-54). تقوم الدالة GetDevanagariCategory (CP) بإرجاع الفئة الصوتية الهندية المبسطة (0 = أخرى، 1 = حرف ساكن، 2 = حرف متحرك مستقل، 3 = ماترا، 4 = فيراما، 5 = نوكتا، 6 = بيندو، 7 = فيزارغا، 8 = داند، 9 = رقم، 10 = ZWJ، 11 = ZWNJ، 12 = مُعدِّل) وفقًا لـ Unicode 16.0 §12.1 بالإضافة إلى ملف IndicSyllabicCategory.txt؛ وتغطي هذه الجدولة كامل نطاق ديوناغاري 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) إلى نهاية المقطع، بحيث تستبدله ميزة GSUB 'rphf' في الخط بالحرف Repha الذي يظهر بصريًا فوق ويمين قاعدة المقطع؛ (2) Pre-base I-matra — يتم نقل U+093F إلى بداية المقطع (بعد إزالة Repha إن وجدت) بحيث ترى معالجة GSUB من اليسار إلى اليمين هذا الحرف قبل مجموعة الحروف الساكنة، مما يطابق ترتيب عرضه البصري.
  • تتضمن سلسلة العمليات التي يقوم بها البرنامج ما يلي: تطبيق إعادة ترتيب نصوص ديوناغاري -> تعيين علامة "deva" -> معالجة نقاط الترميز المعاد ترتيبها وتطبيق ميزات GSUB ('nukt' / 'akhn' / 'rphf' / 'rkrf' / 'half' / 'vatu' / 'cjct' / 'pres' / 'blws' / 'abvs' / 'psts' / 'haln') باستخدام GetSingleSubstituteGlyph و ApplyLigatureSubstitution و ApplyContextualSubst -> إخراج معرفات الأحرف (GIDs) الناتجة إلى تدفق النص في ملف PDF مع استدعاء MarkUnicodeGlyphUsed (GID) لكل إخراج، وذلك لإصدار v2.84.0. مع اكتمال المرحلة أ (v2.119.52 Arabic Extended-A) والمرحلة ب (v2.119.53 Syriac) والمرحلة ج (v2.119.54 Mongolian) والمرحلة د (v2.119.55 Devanagari Indic)، تم سد الفجوة في "تشكيل النصوص المونغولية/السورية/ديوناغاري" بالكامل. خارج نطاق العمل: نصوص ديوناغاري الأخرى (البنغالية، التاميلية، التيلجو، الغوجاراتية - لكل منها بيانات وإرشادات إعادة ترتيب خاصة)، وإرشادات إعادة الترتيب التي تتجاوز Repha و pre-base I-matra، والتشكيل التلقائي لنصوص ديوناغاري من جانب المُنتج داخل TextOut / BuildUnicode*FieldContent (محجوزة للمرحلة 8 من خريطة طريق محرك GSUB).

2026-05-22 Version 2.119.54

  • إمكانية تشكيل النص المونغولي: تعرض طريقتان عامتان جديدتان في THotPDF وظائف لتشكيل النص المونغولي (U+1800-U+18AF)، بما في ذلك البحث عن فئة الربط وتحليل السياق ذي الأربع مواضع، بحيث يمكن للمستخدمين التحكم في عملية تشكيل النص المونغولي من جانب البرنامج. ترجع الدالة GetMongolianJoiningClass (CP) فئة الربط المونغولية (0 = حرف غير مرتبط، 2 = حرف ذو ربط مزدوج، 4 = حرف شفاف / محدد تباين) لأي نقطة ترميز وفقًا للمواصفة Unicode 16.0 §13.5؛ وتغطي هذه الفئة المونغولية الأساسية بالإضافة إلى امتدادات حروف Todo وSibe وManchu وAli Gali (U+1820-U+1878 + U+1887-U+18A8 + ALI GALI DAGALGA U+18A9 + MANCHU ALI GALI LHA U+18AA) وتصنف NIRUGU (U+180A) وثلاثة محددات التباين الحرة FVS1-FVS3 (U+180B-U+180D) وعلامات حروف العلة Ali Gali BALUDA / THREE BALUDA (U+1885-U+1886) على أنها شفافة. تقوم الدالة GetMongolianPosition (Wide, Index) بفحص النص المحيط، متجاوزةً العلامات الشفافة، وتعيد القيمة 0 = معزول، أو 1 = نهائي، أو 2 = أولي، أو 3 = وسيط للحرف الموجود في الفهرس (يبدأ من الصفر).
  • تمامًا مثل لغة السريانية (v2.119.53)، لا تحتوي اللغة المنجوقية على أي أشكال عرض مُبرمجة مسبقًا في Unicode. بدلاً من ذلك، تستخدم جميع الخطوط التي تدعم اللغة المنجوقية (مثل Mongolian Baiti و Noto Sans Mongolian و Noto Serif Mongolian، إلخ) التشكيل الموضعي من خلال عمليات بحث OpenType GSUB في ميزات 'init' و 'medi' و 'fina' و 'isol' تحت علامة البرنامج النصي 'mong'. لذلك، تتبع v2.119.54 نموذج القدرات فقط الموجود في v2.119.53. يقوم المستخدمون بدمج الإخراج الموضعي مع واجهات برمجة تطبيقات محرك GSUB (SetGSUBScript ('mong')، و GetSingleSubstituteGlyph مقابل علامة ميزة التشكيل المناسبة، و MarkUnicodeGlyphUsed لمجموعة الأحرف v2.84.0) لإنتاج معرفات الأحرف المشكلة التي يتم إخراجها مباشرةً في تيار نص PDF.
  • تُكتب اللغة المنجوقية عموديًا من الأعلى إلى الأسفل في نظام الكتابة الأصلي الخاص بها؛ ويعمل هذا البرنامج بناءً على ترتيب نقاط الترميز المنطقي (السابق/اللاحق في تدفق نقاط الترميز)، بغض النظر عن الاتجاه المرئي. يتم التعامل مع العرض الفعلي من الأعلى إلى الأسفل في وقت إخراج ملف PDF من خلال استخدام /WMode 1 (الكتابة العمودية) أو تدوير مصفوفة الخط، وليس بواسطة برنامج التشكيل. تصنيف "Free Variation Selectors" على أنه شفاف يعني أن البرنامج يتعامل بشكل صحيح مع الأشكال الموضعية حتى عندما يتبع حرف "FVS"; يقوم البحث عن GSUB في الخط تلقائيًا باختيار المتغير المشروط بـ "FVS" عندما يظهر "FVS" في سلسلة الإدخال. يظل تشكيل Devanagari (اللغة الهندية) مخصصًا للإصدارات المستقبلية لأنه يتطلب تمريرة إعادة ترتيب خاصة باللغة الهندية وفقًا لـ UAX #38 (إعادة ترتيب علامة التشكيل/مجموعة الحروف الساكنة/القاعدة)، وهو ما لا يتوافق مع برنامج التشكيل ذي الأربع مواضع المستخدم في اللغة العربية/السريانية/المنجوقية. يظل التشكيل التلقائي للغة المنجوقية داخل TextOut / BuildUnicode*FieldContent مخصصًا للمرحلة 8 من خارطة طريق محرك GSUB.

2026-05-22 Version 2.119.53

  • القدرة على تشكيل النص السرياني: تعرض طريقتان عامتان جديدتان في THotPDF وظائف للغة السريانية (U+0700-U+074F) لتحديد فئة الربط وتحليل السياق ذي الأربع مواضع، مما يسمح للمستخدمين بالتحكم في عملية تشكيل النص السرياني من جانب البرنامج. تقوم الدالة GetSyriacJoiningClass (CP) بإرجاع فئة الربط الخاصة بلغة السريانية من ملف Unicode 16.0 SyriacShaping.txt (حيث 0 = غير مرتبط، و 1 = مرتبط من اليمين، و 2 = مرتبط بشكل مزدوج، و 4 = شفاف / NSM) لأي نقطة ترميز؛ وتغطي هذه الجداول جميع أحرف السريانية الـ 35 الموجودة في الكتلة الأساسية بالإضافة إلى الامتدادات الفارسية والسغدية (حرف بيرسي BHETH / GHAMAL / DHALATH في U+072D-U+072F، وحرف سغدي ZHAIN / KHAPH / FE في U+074D-U+074F) وتصنف الحرف ALAPH العلوي (U+0711) وعلامات السريانية المدمجة (U+0730-U+074A) على أنها شفافة. تقوم الدالة GetSyriacPosition (Wide, Index) بفحص النص المحيط، متجاوزة العلامات الشفافة، وتعيد القيمة 0 = معزول، أو 1 = نهائي، أو 2 = أولي، أو 3 = وسيط للحرف الموجود في الفهرس (يبدأ من الصفر).
  • على عكس اللغة العربية (التي تحتوي على مجموعات أحرف "Presentation Forms-B" المشفرة مسبقًا U+FE70-U+FEFF و "Forms-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 فقط طبقة الإمكانات؛ يقوم المستدعي بدمج الإخراج الموضعي مع واجهات برمجة تطبيقات محرك GSUB v2.119.43-50 (SetGSUBScript ('syrc') و GetSingleSubstituteGlyph مقابل علامة ميزة التشكيل الموضعي المناسبة و MarkUnicodeGlyphUsed لمجموعة الأحرف v2.84.0) لإنتاج معرفات الأحرف المشكلة التي يتم إخراجها مباشرةً في دفق النص الخاص بـ PDF.
  • تحديد نطاق شكل حرف الألف: يصف القسم 9.3 من Unicode ميزتين نهائيتين تعتمدان على السياق (يتم تطبيق 'fin2' بعد حرفي دالات وريش، ويتم تطبيق 'fin3' بعد حرف لاماد النهائي) تستخدمها خطوط السرياقية لتبديل حرف الألف النهائي. في الإصدار v2.119.53، يتم تصنيف حرف الألف (U+0710) على أنه حرف أساسي يميل إلى اليمين، ويعيد 0 (معزول) أو 1 (نهائي) فقط؛ يجب على البرامج التي تحتاج إلى التمييز بين 'fin2' و 'fin3' استخدام عمليات البحث السياقية المتسلسلة في الخط من خلال ApplyContextualSubst مع علامات الميزات هذه. لا يزال تشكيل المونغولية والديڤاناغاري (الهندية) مخصصًا للإصدارات المستقبلية: تستخدم المونغولية أدوات اختيار التباين الحرة بالإضافة إلى تناغم حروف العلة، ويتطلب الديڤاناغاري تمرة إعادة ترتيب خاصة باللغات الهندية وفقًا لـ UAX #38، ولا يتطابق أي منهما مع خوارزمية البحث المكونة من 4 مواضع المستخدمة في خطوط السرياقية. يظل التشكيل التلقائي للسرياقية داخل TextOut / BuildUnicode*FieldContent مخصصًا للمرحلة 8 من خريطة طريق محرك GSUB.

2026-05-22 Version 2.119.52

  • توسيع دعم تنسيق خطوط اللغة العربية: الإصدار v2.85.0 يوفر الآن، من جانب المزود، تنسيقًا ثابتًا للغة العربية يغطي الأحرف المتبقية من مجموعة "Arabic Extended-A" (مثل: ALEF WASLA U+0671، NOON GHUNNA U+06BA، وأنواع HEH U+06C0-U+06C3)، ومجموعة "Arabic Supplement" U+0750-U+077F (أحرف عربية أفريقية تستخدم في لغات الهوسا والوولوف وغيرها من اللغات الأفريقية)، والمنطقة الجديدة "Arabic Extended-A" U+08A0-U+08FF (العربية القرآنية + أحرف موسعة للهوسا والوولوف + علامات دمج قرآنية). يتم استخلاص فئات الربط من ملف ArabicShaping.txt في Unicode 16.0، ويتم تطبيقها أثناء تحليل المواضع الأربعة في الإصدار v2.85.0، بحيث تختار الأحرف المجاورة الشكل الصحيح (init / medi / fina / isol) بغض النظر عن نوع العربية الموجودة بجوارها.
  • تُترجم الآن الأحرف التي تحتوي على أشكال عرض ثابتة ومُبرمجة مسبقًا في كتلة "Arabic Presentation Forms-A" (U+FB50-U+FBFF) مباشرةً إلى تلك الأشكال دون الحاجة إلى مُشكل OpenType GSUB: يتم تعيين "ALEF WASLA" إلى FB50/FB51 (وصلة يمين، شكلان)، و"NOON GHUNNA" إلى FB9E/FB9F (وصلة مزدوجة وفقًا لـ Unicode ولكن يوجد شكلان فقط مُبرمجان مسبقًا؛ تتراجع الأشكال "init/medi" بشكل جيد إلى "isol")، و"HEH WITH YEH ABOVE" إلى FBA4/FBA5 (وصلة يمين، شكلان)، و"HEH GOAL" إلى FBA6/FBA7/FBA8/FBA9 (وصلة مزدوجة، الأربعة أشكال الكاملة)، و"HEH GOAL WITH HAMZA ABOVE" إلى FBAA/FBAB/FBAC/FBAD (وصلة مزدوجة، الأربعة أشكال الكاملة)، و"TEH MARBUTA GOAL" إلى FBAE/FBAF (وصلة يمين، شكلان). بالإضافة إلى ذلك، مع التحديث v2.119.32 الذي يفرض استخدام الربط الإلزامي "LAM-ALEF" والتحديث v2.119.35 الذي يتضمن مجموعة فرعية أساسية مكونة من 9 أحرف للغة الفارسية/الأردية، يغطي المُشكل الثابت الآن جميع أنواع النصوص العربية الحديثة تقريبًا، بالإضافة إلى الفارسية، والأردية، والسندية، والبشتو، والكردية، والأويغورية، والنصوص القرآنية، واللهجات العربية الأفريقية (مثل الهوسا والوولوف).
  • تمت إضافة دعم للملحق العربي (U+0750-U+077F) ومنطقة الأحرف العربية الممتدة أ (U+08A0-U+08C7) الأحدث، ولكن لا توجد لها أشكال عرض ثابتة مسبقة التشفير. تسمح إدخالات فئة الربط لها بالحروف المجاورة بالتشكيل بشكل صحيح، ولكن تظل الأحرف نفسها كنقاط رمزية خام وتعتمد على خط يدعم GSUB (أو واجهات برمجة تطبيقات محرك GSUB v2.119.43-50 التي يتحكم فيها المتصل) لتشكيلها الخاص. يتم تصنيف منطقة علامات الدمج القرآنية العربية الممتدة أ (U+08CA-U+08E1، U+08E3-U+08FF) على أنها شفافة (ربط من النوع T)، لذلك تتخطى عملية تحليل موضع الجيران هذه، مما يطابق معالجة harakat الحالية (U+064B-U+065F). يظل النص الذي لا يتضمن هذه الأحرف الممتدة متطابقًا تمامًا مع إخراج الإصدار v2.119.51. يظل التشكيل الخاص باللغتين المنجوقية والسريانية واللغة الديفاناجاري (نماذج تشكيل مختلفة عن اللغة العربية) مخصصًا للإصدارات المستقبلية.

2026-05-22 Version 2.119.51

  • دعم حاويات XFA (بنية نماذج XML) من جانب المزود: يسمح معيار PDF 1.7 §12.7.6 + §12.7.8 لنموذج AcroForm بحمل إدخال /XFA بالإضافة إلى (أو بدلاً من) مصفوفة /Fields الثابتة. تقوم الدالة الجديدة THotPDF.AddXFAPacket (PacketName, XMLBytes) بتسجيل حزمة XFA مسماة - تتضمن الأسماء النموذجية 'template' (تخطيط النموذج + النصوص البرمجية)، و 'datasets' (ربط البيانات)، و 'config' (تكوين العارض)، و 'connectionSet'، و 'localeSet'، و 'stylesheet'، و 'xfdf'، و 'xmpmeta'، و 'signature'، و 'sourceSet'. تصبح كل حزمة مسجلة تيارًا مضغوطًا واحدًا باستخدام FlateDecode في نهاية المستند، وتتبادل مصفوفة /XFA سلاسل أسماء الحزم مع مراجع التدفق بترتيب التسجيل بحيث يكون التخطيط محددًا بالبايت. تكمل الدالتان THotPDF.ClearXFAPackets و THotPDF.XFAPacketCount واجهة برمجة التطبيقات.
  • يدعم HotPDF فقط مستوى الحاوية — فهو لا يحلل ملف XFA XML، ولا يقوم بتنفيذ محرك التخطيط الديناميكي لـ XFA، ولا ينفذ FormCalc أو JavaScript داخل قالب XFA، ولا يتحقق من صحة هيكل القالب. يقوم المستخدم بإنشاء ملف XFA XML بنفسه (عادةً باستخدام Adobe LiveCycle Designer أو عن طريق الإنشاء اليدوي وفقًا لمواصفات XFA 3.3)، ويقوم HotPDF بإخراج البايتات كما هي. تعرض برامج القراءة التي تحتوي على محرك XFA (مثل الإصدارات القديمة من Acrobat/Reader و FormsCentral وبعض منتجات الأكشاك) النموذج؛ بينما تعرض برامج القراءة التي لا تحتوي على محرك XFA (مثل Adobe Reader DC اعتبارًا من عام 2017، ومعظم برامج القراءة مفتوحة المصدر) حقول AcroForm الاحتياطية إذا كان المستند عبارة عن سير عمل هجين يجمع بين AcroForm و XFA.
  • تمت إضافة بوابات الامتثال لمعايير 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) برفع إصدار المستند تلقائيًا. الآن، يتم إخراج قاموس AcroForm إذا كان يحتوي على عنصر واحد على الأقل في /Fields أو إذا تم تسجيل حزمة XFA واحدة على الأقل. في الإصدارات الأقدم من v2.119.51، إذا لم يتم تسجيل أي حزم، فسيظل الإخراج مطابقًا تمامًا من حيث البايت لـ /AcroForm.

2026-05-22 Version 2.119.50

  • تمت إضافة آلية لإدراج أحرف TTF المستخدمة في عمليات استبدال GSUB: تستخدم الوظيفة الجديدة THotPDF.MarkUnicodeGlyphUsed (GID: Word) لتضمين حرف في مجموعة الأحرف الفرعية الخاصة بـ v2.84.0، بغض النظر عما إذا كانت خريطة الأحرف (cmap) تحتوي على نقطة رمزية مطابقة لهذا الحرف أم لا. تستمد هذه الآلية مجموعة الأحرف المستخدمة من FUnicodeUsedCps عبر خريطة الأحرف، وبالتالي، كانت الأحرف المستبدلة التي تم إدخالها بواسطة GSUB (مثل الأحرف البديلة الأسلوبية، والروابط، والتغيرات السياقية، وجميع النتائج الناتجة عن واجهات برمجة التطبيقات (APIs) للأسئلة من المرحلة 1 إلى 6) غير مرئية سابقًا للمجموعة الفرعية، وكان برنامج القراءة يعرض رمز .notdef بدلاً منها. بعد إخراج أي معرف حرف (GID) تم إرجاعه بواسطة GetSingleSubstituteGlyph / GetMultipleSubstituteGlyphs / GetAlternateGlyph / ApplyLigatureSubstitution / ApplyContextualSubst / ApplyReverseChainedContextualSubst في تدفق نص PDF، يقوم المتصل الآن باستدعاء MarkUnicodeGlyphUsed (GID) مرة واحدة لكل معرف حرف تم إخراجه، وذلك لضمان تضمينها في المجموعة الفرعية المضمنة.
  • تعتبر هذه الأداة ذاتية الإكمال (لا تحدث أي تغييرات عند استدعائها بشكل متكرر بنفس المعرف)، وآمنة (يتم تجاهل المعرفات غير الصالحة بهدوء، والاستدعاءات التي تتم قبل استدعاء RegisterUnicodeTTF لا تفعل شيئًا)، وتتكامل مع عملية إغلاق الرموز المركبة v2.84.0 داخل _BuildSubsetTTF. يجب على المستخدمين فقط تحديد المعرف الرئيسي للرمز البديل، حيث يتم استيراد المكونات المركبة تلقائيًا بواسطة عملية _TTFWalkCompositeClosure الحالية. يتم تخصيص المجموعة بشكل مؤجل عند الاستدعاء الأول، ويتم إعادة تعيينها إلى فارغة في كل مرة يتم فيها استدعاء RegisterUnicodeTTF ('', nil)، بالإضافة إلى بقية حالة المجموعة. مع تطبيق المرحلة 9، يمكن دمج أي استعلام API لـ GSUB من المرحلة 1-7 بأمان مع إخراج المجموعة دون أن تظهر الرموز البديلة خارج الخط المضمن.

2026-05-22 Version 2.119.49

  • واجهة برمجة تطبيقات (API) OpenType GSUB لاختيار النص/اللغة: توفر خمس طرق عامة جديدة في THotPDF تسمح للمستخدمين بتحديد جداول بحث GSUB لنص ولغة معينة بدلاً من الاعتماد على الإعدادات الافتراضية للنص/اللغة. تحدد الدالة 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` بإرجاع كل علامة نصية في ترتيب قائمة النصوص؛ وتقوم الدالة `GetGSUBLanguages (ScriptTag)` بإرجاع كل علامة لغة ضمن النص المحدد (مع وجود عنصر نائب فارغ في الفهرس 0 عندما يحتوي النص على نظام لغة افتراضي). تقوم الدالة `GetGSUBFeatures (ScriptTag, LangTag)` بإرجاع كل علامة ميزة (مثل 'liga'، 'salt'، 'aalt'، و 'ss01' إلى 'ss20') التي يعلن عنها المسار (النص، اللغة) بترتيب فهارس الميزات في نظام اللغة. عند استخدام علامة نصية أو علامة لغة فارغة، يتم استخدام نفس آلية التراجع الافتراضية كما هو الحال في واجهات برمجة التطبيقات الخاصة بالاستبدال، بحيث يمكن للمستخدمين استدعاء الدالة `GetGSUBFeatures ('', '')` لسرد ميزات المسار الافتراضي دون الحاجة إلى فحص قائمة النصوص أولاً.
  • آليات الاختيار بين القيم الافتراضية والقيم المحددة: عندما يتم تعيين علامة SetGSUBScript، لا تعلن الخطوط المحملة عن هذه العلامة، وبالتالي فإن استعلامات GSUB اللاحقة تُرجع نتائج فارغة أو لا تفعل شيئًا — المحرك لا يعود تلقائيًا إلى القيمة الافتراضية، بحيث يمكن للمستخدمين معرفة بوضوح أن السكربت المحدد غير متاح. عندما يتم تعيين SetGSUBLanguage إلى علامة غير معروفة، فإنه يعود إلى القيمة الافتراضية للسكربت وفقًا للتوصية في مواصفات OpenType. تحتفظ الطرق السبعة الحالية للاستبدال في GSUB (GetSingleSubstituteGlyph / GetMultipleSubstituteGlyphs / GetAlternateGlyphCount / GetAlternateGlyph / ApplyLigatureSubstitution / ApplyContextualSubst / ApplyReverseChainedContextualSubst) بتواقيعها العامة كما هي دون تغيير؛ فقط الدالة المساعدة الداخلية _GSUBFindFeatureLookups تكتسب معلمتين إضافيتين في النهاية، وتوجه جميع المواقع التي تستدعي هذه الدالة الآن من خلالهما. مع واجهة برمجة التطبيقات (API) للسكربت / LangSys ومصفوفة أنواع البحث من 1 إلى 8، فإن محرك GSUB مكتمل الميزات للاستخدام الذي يعتمد على الإمكانات فقط؛ تستهدف المراحل المتبقية من خطط التطوير (خط أنابيب التشكيل التلقائي + أداة تقليل حجم ملفات TTF) التكامل من جانب المنتج بدلاً من إضافة واجهات استعلام جديدة.

2026-05-22 Version 2.119.48

  • تمت إضافة نوع بحث استبدال GSUB جديد، وهو "OpenType GSUB Reverse Chained Contextual Single Substitution" (النوع 8): الدالة الجديدة `THotPDF.ApplyReverseChainedContextualSubst (const InputGIDs; StartIndex; FeatureTag; out OutGID): Boolean` هي آخر نوع بحث GSUB تم إضافته. يقوم هذا النوع باستبدال أحادي بسيط يعتمد على السياق، حيث يتم تحديد الحرف البديل بناءً على فهرس التغطية للحرف المدخل، والميزة المميزة هي أن المستخدمين يجب عليهم تطبيق هذا الاستبدال بترتيب مسح عكسي على سلسلة من الأحرف (من النهاية إلى البداية) لأن كل حرف بديل قد يعتمد على السياق المستقبلي الذي لم يتم استبداله بعد. هذه الدالة هي تطبيق لنقطة واحدة، حيث يتحكم المستخدم في حلقة المسح العكسي. تدعم هذه الدالة تنسيق التغطية 1 و 2، وعلامات البحث التي تحترم (التخطي للبيانات المدخلة والعودة إلى الخلف والتطلع إلى الأمام)، بالإضافة إلى التغليف (كما هو الحال في النوع 7).
  • حالة الاستخدام الأساسية: بعض الأحرف العربية/السريانية/N'Ko/الهندية التي تعتمد شكلها النهائي على شكل الحرف التالي. تستخدم بعض الخطوط أيضًا هذه الميزة لتوضيح تسلسل الأحرف اللاتينية. على عكس LookupType 5/6، لا يحتوي النوع 8 على آليات بحث متداخلة، حيث أن الاستبدال هو بشكل أساسي علاقة 1:1. إذا لم يتم العثور على تطابق، يتم إرجاع قيمة "False"، و OutGID = InputGIDs[StartIndex] (مطابقة تقريبية تتوافق مع واجهة GetSingleSubstituteGlyph v2.119.43).
  • يغلق مصفوفة LookupType: اعتبارًا من الإصدار v2.119.48، تمت إضافة إمكانية عامة مخصصة لكل نوع LookupType في OpenType GSUB (من 1 إلى 8) في THotPDF. لا تزال واجهة برمجة التطبيقات (API) لاختيار النص/اللغة، والتكامل التلقائي لخطوط التشكيل، وسحب أحرف بديلة تلقائيًا من TTF مخصصة للمرحلة 7-9. لا يزال المستخدم مسؤولاً عن تحديد الأحرف البديلة المختارة في مجموعة الخطوط المضمنة، وإجراء عملية المسح العكسي بنفسه.

2026-05-22 Version 2.119.47

  • OpenType GSUB: إضافة استبدال سياقي وسلسلي (LookupType 5 + 6): الدالة الجديدة `THotPDF.ApplyContextualSubst` (تأخذ `InputGIDs` ثابتة، و`StartIndex`، و`FeatureTag`، و`OutGIDs` كمتغير، و`ConsumedLen` كإخراج، وتعيد قيمة منطقية) هي نقطة دخول واحدة تغطي كلاً من LookupType 5 (السياق الخاص بالإدخال فقط) و LookupType 6 (السياق الذي يتضمن التراجع والإدخال والتطلع) عبر جميع التنسيقات الثلاثة للجداول الفرعية: التنسيق 1 (تسلسلات معرفات الأحرف الحرفية)، والتنسيق 2 (تسلسلات تعريف الفئات)، والتنسيق 3 (تسلسلات جداول التغطية، وهو الشكل القياسي المستخدم في معظم الخطوط الحديثة). المستخدمون القياسيون هم 'rclt' (البدائل السياقية المطلوبة - الأشكال الموضعية العربية init/medi/fina/isol عندما يقوم الخط بتطبيقها من خلال GSUB)، و 'clig' (الوصلات السياقية)، و 'calt' (البدائل السياقية)، وميزات التشكيل الهندية 'pres' / 'blws' / 'psts' / 'half' / 'pstf' / 'cjct'.
  • آلية توجيه البحث المتداخل في سجل البحث التسلسلي: عندما يتطابق قاعدة سياقية، تقوم إدخالات سجل البحث التسلسلي بتشغيل بحث متداخل في موضع معين داخل التسلسل الفرعي المطابق. تعمل الدالة المساعدة الجديدة `_GSUBApplyNestedLookup` على إعادة الدخول إلى قائمة البحث GSUB، وتعالج لفائف التوسيع بشفافية، وتقوم بتوجيه العمليات إلى التطبيقات الفردية (النوع 1) / المتعددة (النوع 2) / البديلة (النوع 3، البديل الأول) / الربط (النوع 4). يتتبع الموزع مؤشرات `MatchPositions[]` النشطة حتى تتمكن إدخالات سجل البحث التسلسلي اللاحقة من معالجة المواضع الصحيحة حتى عندما يؤدي استبدال متعدد إلى توسيع 1 إلى N أو يؤدي استبدال الربط إلى تجميع N إلى 1 من الرموز حولها. تم تأخير البحث المتداخل من النوع 5/6/8 (سياقي متكرر) عن قصد؛ معظم الخطوط الحقيقية تربط عمليات البحث المتداخلة بالنوع 1/4 على أي حال.
  • عندما يتم العثور على تطابق، تُرجع الطريقة القيمة True بالإضافة إلى تسلسل الرموز الذي يجب أن يحل محل InputGIDs[StartIndex..StartIndex+ConsumedLen-1]. يمكن أن يختلف طول OutGIDs عن ConsumedLen عندما يتم تفعيل عمليات البحث المتداخلة من النوع 1 إلى N أو N إلى 1. يمثل ConsumedLen دائمًا النطاق الإجمالي للمدخلات التي استوعبتها القاعدة السياقية (بما في ذلك العلامات التي تم تخطيها بواسطة LookupFlag بين الرموز المهمة). في حالة عدم وجود تطابق، تُرجع الطريقة القيمة False، و OutGIDs فارغة، و ConsumedLen = 1، وهو نفس سلوك "لا شيء" الآمن الموجود في الإصدارات v2.119.43-46. يتم تطبيق إعداد LookupFlag (المرحلة 4) طوال عملية المطابقة السياقية: عمليات التراجع / الإدخال / التطلع تتخطى جميع الرموز التي تم وضع علامة عليها لتجاهلها. تظل قيم Script / LangSys ثابتة عند القيمة الافتراضية DFLT لهذا الجزء؛ يقع نطاق واجهة برمجة التطبيقات (API) للتحديد في المرحلة 7.

2026-05-22 Version 2.119.46

  • تتيح عمليات بحث GSUB الممتدة (LookupType 7) الآن لمحرك GSUB فك ضغط الجداول الفرعية للاستبدال الممتدة تلقائيًا - وهي طبقة وسيطة تستخدمها مواصفات OpenType للخطوط الكبيرة جدًا بحيث يقع الجدول الفرعي للاستبدال الفعلي خارج نطاق الوصول المحدود بـ 16 بت لـ LookupList's Offset16. تتبع جميع واجهات برمجة التطبيقات (APIs) العامة v2.119.43-45 (GetSingleSubstituteGlyph / GetMultipleSubstituteGlyphs / GetAlternateGlyphCount / GetAlternateGlyph / ApplyLigatureSubstitution) تلقائيًا طبقة الوساطة Offset32 ذات الـ 32 بت للوصول إلى الجداول الفرعية الحقيقية من النوع 1 / 2 / 3 / 4. هذا التغيير في تخطيط البيانات الثنائي يزيل القيود المفروضة على خطوط OpenType CJK / Indic الكبيرة (مثل Noto Sans CJK و Noto Sans Devanagari) والتي تتجاوز جداول GSUB الخاصة بها حجم 64 كيلوبايت، والتي كانت في السابق تستخدم غلاف LookupType 7 لإخفاء عمليات البحث الخاصة بها؛ ونتيجة لذلك، كانت هذه الخطوط تبدو وكأنها لا تحتوي على أي ميزات في HotPDF.
  • تحسين تحليل جدول GDEF (تعريف الحرف) في OpenType: تقوم الدالة `RegisterUnicodeTTF` الآن أيضًا بتخزين جدول GDEF الخاص بالخط مؤقتًا عند وجوده. ثلاثة جداول فرعية لـ GDEF تتحكم في منطق `LookupFlag`: يقوم `GlyphClassDef` بتصنيف كل معرف حرف (GID) على أنه أساسي (1) / حرف ربط (2) / علامة (3) / مكون (4). يقوم `MarkAttachClassDef` بتصنيف كل حرف علامة بفئة ارتباط. يعلن `MarkGlyphSetsDef` (الإصدار 1.2 وما يليه) عن مجموعات مسماة من حروف العلامات. تم تنفيذ كلا التنسيقين من `ClassDef` (التنسيق 1: `startGlyphID` + `classValueArray` والتنسيق 2: `classRangeRecords` المرتبة). يتم قبول رؤوس GDEF للإصدارات 1.0 و 1.1 و 1.2 (يتم تجاهل `itemVariationStore` في الإصدار 1.3). بالنسبة للخطوط التي لا تحتوي على جدول GDEF، يتم الرجوع إلى سلوك الإصدار 2.119.43-45 (حيث "لا يتم تجاهل أي حرف") للحفاظ على نفس الإخراج للمستخدمين الذين يستخدمون خطوطًا تفتقر إلى GDEF.
  • تم الآن احترام علامة "LookupFlag" في عمليات بحث استبدال الخط (GSUB) في OpenType: تقوم جميع واجهات برمجة التطبيقات (APIs) العامة لـ GSUB الخمس الآن بقراءة قيمة "LookupFlag" لكل جدول بحث (بالإضافة إلى القيمة الاختيارية uint16 لـ "markFilteringSet" عندما يتم تعيين "useMarkFilteringSet" في "LookupFlag") وتتخطى الرموز المستخدمة التي تم وضع علامة عليها للإهمال. يتم احترام بتات العلامات المحددة في المواصفات: 0x0002 لتجاهل الرموز الأساسية (تخطي تعريف الفئة 1 في GDEF)، و0x0004 لتجاهل الرموز المدمجة (تخطي الفئة 2)، و0x0008 لتجاهل العلامات (تخطي الفئة 3)، و0x0010 لاستخدام "markFilteringSet" (فقط العلامات الموجودة في مجموعة "MarkGlyphSet" المسماة تشارك)، والبايت العلوي لـ "markAttachmentType" (فقط العلامات التي تنتمي إلى تعريف فئة "MarkAttachClassDef" المطلوبة تشارك). بالنسبة لاستبدال الرموز المدمجة (LookupType 4)، هذا له أهمية خاصة: الرموز المدمجة العربية 'rlig' / الرموز المدمجة الهندية 'akhn' التي تفصل بين مكوناتها رموز علامات (مثل LAM + Fatha + ALEF) تتطابق الآن بشكل صحيح عند تعيين "ignoreMarks" في "LookupFlag"، ويتضمن العدد المستهلك الذي تم إرجاعه العلامات التي تم تخطيها، بحيث ينتقل حلقة المسح الخاصة بالمستدعي إلى ما بعد كل رمز إدخال تم استيعابه. البت 0x0001 (من اليمين إلى اليسار) خاص بـ GPOS ويظل مهملًا لعمليات البحث GSUB.
  • تظل القيود الوقائية كما هي: الخطوط التي لا تحتوي على جدول GSUB، والمستخدمون الذين يمررون علامة غير مكونة من 4 بايت، والميزات التي لا يعلن عنها النص DFLT للخط، ورموز GID التي لا يغطيها أي جدول فرعي، والآن الرموز المستخدمة التي يتم تجاهلها بواسطة LookupFlag، كلها تُرجع النتيجة الآمنة v2.119.43-45. توقيعات واجهة برمجة التطبيقات (API) الخمس العامة مستقرة من حيث حجم البايت؛ فقط عملية البحث الداخلية تستخدم التوزيع الإضافي، واحترام علامة LookupFlag، وتصنيف GDEF. تظل واجهة برمجة التطبيقات (API) لاختيار النص/اللغة، والتكامل التلقائي لخطوط المعالجة، وسحب الخطوط الفرعية التلقائي للرموز البديلة، مخصصة للإصدارات المستقبلية.

2026-05-22 Version 2.119.45

  • تتيح ميزة استبدال التشكيل (Ligature Substitution) من نوع OpenType (LookupType 4) في THotPDF.ApplyLigatureSubstitution (const InputGIDs: array of Word; StartIndex; FeatureTag; out OutGID; out ConsumedCount): Boolean دمج سلسلة من الرموز المتعددة في رمز تشكيل واحد. المستخدمون الأساسيون هم 'liga' (التشكيلات القياسية - fi / fl / ffi / ffl)، و 'clig' (التشكيلات السياقية)، و 'dlig' (التشكيلات الاختيارية)، و 'hlig' (التشكيلات التاريخية)، و 'rlig' (التشكيلات المطلوبة - مثل LAM-ALEF العربية وما شابه ذلك عندما يتحكم الخط في التشكيل من خلال GSUB)، وميزات تشكيل النصوص الهندية ('akhn'، 'pres'، 'blws'، 'psts'). يقوم المتصل بتمرير تسلسل معرف الرمز (glyph-ID) بعد خريطة الألوان (cmap) وموضع بداية (يبدأ من 0). في حالة التطابق التام، تُرجع الدالة True، و OutGID = رمز التشكيل البديل، و ConsumedCount = العدد الإجمالي للمكونات المدخلة (عادةً >= 2). إذا لم يكن هناك تطابق، تُرجع الدالة False، و OutGID = 0، و ConsumedCount = 1، بحيث يمكن للمتصل التقدم خطوة واحدة والاستمرار في المسح. تلتزم التنفيذ بالاتفاقية القياسية لـ OpenType بأن إدخالات LigatureSet يتم سردها عادةً من الأطول إلى الأقصر، مما يسمح للخطوط التي تحتوي على بادئات متداخلة (مثل تشكيل 'ffi' بثلاثة مكونات إلى جانب تشكيل 'ff' بمكونين) بالحصول على التطابق الأطول. نفس القيود الوقائية الموجودة في المساعدات v2.119.43/.44: العلامات الفارغة / غير 4 بايت، عدم وجود GSUB، والميزة غير المعلن عنها، وموضع البداية خارج النطاق، وعدم وجود جدول فرعي من النوع 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`، والمخرجات: `OutGIDs`) تُرجع حرف إدخال واحد كسلسلة من أحرف الاستبدال. المستخدم الأساسي هو ميزة "Glyph Composition / Decomposition" المسماة 'ccmp'، والتي تقسم الأحرف اللاتينية المسبقة التركيب إلى حرف أساسي بالإضافة إلى علامات مدمجة لتحديد موضع العلامات اللاحقة. تقوم الوظيفة المساعدة بتتبع نفس مسار البرنامج النصي الافتراضي (DFLT)، ونظام اللغة الافتراضي (LangSys)، وقائمة الميزات (FeatureList)، وقائمة عمليات البحث (LookupList) كما في `GetSingleSubstituteGlyph` في الإصدار v2.119.43، وتطبق كل جدول فرعي من النوع 2 (LookupType 2) مرتبط بالميزة المطلوبة بالنسبة إلى `InputGID`؛ والفوز يذهب إلى أول تطابق. يتم إعادة تعيين `OutGIDs` عند الدخول، بحيث لا يحتاج المستخدمون إلى مسحها مسبقًا. يتم الإبلاغ عن التسلسل الفارغ المسموح به في المواصفات (glyphCount = 0، حذف حرف Unicode القياسي) على أنه `Result = True` مع `Length(OutGIDs) = 0`، بحيث يمكن للمستخدم حذف حرف الإدخال من التسلسل.
  • تمت إضافة ميزتين جديدتين في OpenType GSUB Alternate Substitution (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 للخط، ورموز GID التي لا يغطيها الجدول الفرعي من النوع 2/3، كلها تُرجع العملية الآمنة (False + OutGIDs فارغة لـ Multiple؛ 0 / InputGID لـ Alternate). يتم تجاهل الجداول الفرعية من النوع 1 و 4-8 التي تمت مواجهتها في سلسلة البحث الخاصة بالميزة في هذا الجزء بصمت. تظل علامات LookupFlag الخاصة بالتصفية، وتكامل GDEF GlyphClassDef، وواجهة برمجة التطبيقات (API) لاختيار النص/اللغة، والتكامل التلقائي لخط الأشكال، وسحب الخطوط الفرعية التلقائي للخطوط البديلة المحددة مخصصة للإصدارات المستقبلية؛ لا يزال المستخدمون مسؤولين عن وضع علامة على الخطوط البديلة المختارة في مجموعة الخطوط المضمنة.

2026-05-22 Version 2.119.43

  • تحديث لـ OpenType GSUB: الآن، تستخدم الدالة `THotPDF.GetSingleSubstituteGlyph (InputGID, FeatureTag)` لسرد سلسلة قوائم GSUB (ScriptList / FeatureList / LookupList) في الخط، ضمن نظام اللغة الافتراضي (LangSys) للبرنامج النصي الافتراضي (DFLT)، وتطبق كل جدول فرعي من النوع 1 (استبدال واحد) مرتبط بالميزة المطلوبة، وتعيد معرف الرمز البديل. تشمل العلامات الشائعة لميزات البدائل الأسلوبية: 'salt' (البدائل الأسلوبية)، و 'ss01' إلى 'ss20' (مجموعات أسلوبية 1-20)، و 'aalt' (استخدام جميع البدائل)، و 'titl' (بدائل العنوان)، و 'subs' / 'sups' (أسفل/فوق)، و 'frac' (كسور)، و 'ordn' (أرقام ترتيبية). يتم دعم أي علامة ميزة OpenType مكونة من 4 بايت تحتوي سلسلة الميزات الخاصة بها على جداول فرعية من النوع 1. يتم احترام كلا التنسيقين 1 (مصفوفة رموز مرتبة، يتم البحث فيها باستخدام البحث الثنائي) والتنسيق 2 (سجلات النطاق). يتم تنفيذ كلا التنسيقين 1 و 2 للاستبدال الفردي (دلتا ومصفوفة بديلة). تقوم الدالة `RegisterUnicodeTTF` الآن بتخزين إزاحة/طول جدول GSUB جنبًا إلى جنب مع cmap، بحيث تتجنب عمليات البحث عن GSUB في وقت الاستعلام إعادة فحص دليل الجدول. إذا لم يكن الخط يحتوي على جدول GSUB، أو إذا قام المتصل بتمرير علامة مكونة من 4 بايت لا يعلن عنها البرنامج النصي الافتراضي للخط، أو إذا كانت معرفات الرموز غير موجودة في تغطية البحث، فسيتم إرجاع `InputGID` دون تغيير، مما يجعل واجهة برمجة التطبيقات (API) آمنة للاستخدام كبديل أو تمرير مباشر. يتم تخطي الجداول الفرعية من النوع 2 إلى 8 الموجودة في سلسلة البحث الخاصة بالميزة في هذه المرحلة الأولية - سلاسل الاستبدال المتعددة/البديلة/الترابطية ودمج خط الأنابيب التلقائي للتشكيل محفوظة للإصدارات المستقبلية.

2026-05-22 Version 2.119.42

  • تتيح الآن موارد AcroForm /DR قبول خطوط Unicode متعددة. في الإصدار v2.56.0، تقوم الدالة SetFormUnicodeFontDict بتتبع خط واحد فقط يتم توفيره من قبل المستخدم ويصبح الخط الافتراضي لـ AcroForm /DA. كانت النماذج متعددة اللغات التي تتطلب نصوصًا مختلفة لكل حقل (مثل العربية واللغات الصينية واللاتينية في ملف PDF واحد) تحتاج إلى إنشاء قاموس /DR /Font يدويًا. تقوم الدالة الجديدة THotPDF.RegisterAcroFormFont (LogicalName, FontDict) بتسجيل خط Unicode إضافي بأي اسم منطقي، وتجعله متاحًا لسلاسل /DA لكل حقل (مثل 12 Tf)، وتقوم بإصداره في قاموس /DR /Font الخاص بـ AcroForm جنبًا إلى جنب مع الخط الافتراضي في الإصدار v2.56.0. يتم الحفاظ على ترتيب التسجيل بحيث يكون القاموس /DR الناتج متسقًا. تؤدي تضارب الأسماء مع الخط الافتراضي لـ SetFormUnicodeFontDict أو خط مسجل مسبقًا إلى ظهور خطأ باستخدام الاسم المخالف. كما يؤدي استخدام اسم منطقي فارغ أو FontDict فارغ إلى ظهور خطأ. تقوم مسار إعادة الضبط لـ SetFormUnicodeFontDict ('', nil) الآن أيضًا بمسح سجل الخطوط الإضافية، مما يضمن بدء سير عمل Unicode جديد من حالة نظيفة معروفة. مسموح به في جميع مستويات PDF/A و PDF/X - الخطوط متعددة Unicode هي بيانات وصفية هيكلية للنموذج، وليست نصوصًا تفاعلية.

2026-05-22 Version 2.119.41

  • تغطي هذه القائمة التعدادية (enum) للهياكل القياسية، والتي تغطي القسم 14.8.4 من مواصفات PDF 1.7، الجدول 333: يمثل التعداد الجديد `THPDFStandardStructureType` حوالي 40 دورًا هيكليًا محددًا في المواصفة، وهي مجمعة حسب دورها في PDF (التجميع: مستند / جزء / مقالة / قسم / قسم / اقتباس / عنوان / جدول المحتويات / جدول محتويات تفصيلي / فهرس / غير هيكلي / خاص؛ مستوى الكتلة: عنوان / H1-H6 / فقرة / قائمة / عنصر قائمة / تسمية / نص فقرة / جدول / صف / رأس خلية / خلية / رأس الجدول / جسم الجدول / تذييل الجدول؛ مستوى مضمن: امتداد / اقتباس / ملاحظة / مرجع / إدخال ببليوغرافي / كود / رابط / تعليق؛ روبي وواريتشو: روبي / RB / RT / RP / واريتشو / WT / WP؛ رسم توضيحي: شكل / معادلة / نموذج). تستخدم أداتان تعملان على مستوى الوحدة لتحويل التعداد إلى أسماء PDF دقيقة وفقًا للمواصفات - `StandardStructureTypeToName` (T) ترجع الاسم الحساس لحالة الأحرف المستخدم كـ "/S" للعنصر الهيكلي، و `IsStandardStructureType` (Name) تتحقق مما إذا كانت سلسلة AnsiString عشوائية تتطابق مع المجموعة القياسية، بحيث يمكن للمستخدمين التحقق مسبقًا من أسماء الأدوار المخصصة وتوجيهها من خلال `AddStructRoleMap` عند الحاجة. تقبل نسخة جديدة من `AddStructureElement` تأخذ `THPDFStandardStructureType` مباشرةً، مما يلغي خطر الأخطاء الإملائية / حساسية حالة الأحرف ("Para" مقابل "P"، "Lbody" مقابل "LBody") الموجودة في النسخ التي تستخدم سلاسل نصية، مع توجيهها إلى نفس التنفيذ الأساسي. تظل النسخ الموجودة التي تعتمد على سلاسل AnsiString متطابقة تمامًا من حيث البايت للمستخدمين الذين يستخدمون أسماء مخصصة أو أسماء موجهة عبر RoleMap.

2026-05-22 Version 2.119.40

  • تتيح أدوات تعيين سمات عناصر الهيكل الثلاثة الجديدة إمكانية ملء سمات النص في ملف PDF لكل عنصر، وهي السمات التي تتوافق مع الإصدارين v2.88.0 /Alt و /ActualText، والإصدار v2.95.0 /ID. تقوم الدالة THotPDF.SetStructureElementLanguage (Elem, BCP-47 Lang) بكتابة قيمة /Lang وفقًا للمواصفة PDF 1.7 §14.9.2، مما يتيح تجاوز اللغة الافتراضية للمستند للمحتوى الموجود أسفل هذا العنصر، حتى يتم تطبيق تجاوز /Lang آخر. الاستخدام النموذجي هو المقاطع المقتبسة بلغة أخرى أو أقسام المحتوى المختلطة. تقوم الدالة THotPDF.SetStructureElementExpansionText (Elem, ExpansionText) بكتابة قيمة /E وفقًا للمواصفة §14.9.5، وهي التوسعة التي يقرأها قارئات الشاشة بدلاً من الاختصارات ('NASA' → 'National Aeronautics and Space Administration')، والقيمة التي يتم استخراجها بواسطة أدوات استخراج المحتوى. تقوم الدالة THotPDF.SetStructureElementTitle (Elem, Title) بكتابة قيمة /T وفقًا للمواصفة §14.7.5.2، وهي العنوان الذي يمكن قراءته والذي يميز العنصر عن العناصر الأخرى ذات الدور المماثل في شجرة الهيكل (يعرض جزء "Tags" في برنامج Acrobat قيمة /T بجوار اسم الدور). جميع هذه الأدوات هي أدوات تعيين بسيطة، ولا تفعل أي شيء إذا كانت القيمة فارغة، وترفع خطأ إذا كانت قيمة Elem فارغة، وهي مسموح بها في جميع مستويات PDF/A و PDF/X نظرًا لأن المفاتيح تمثل بيانات وصفية هيكلية.

2026-05-22 Version 2.119.39

  • إكمال مجموعة مشغلات حقول النموذج في AcroForm: ثلاثة مساعدين جدد ينضمون إلى AttachFieldKeyStrokeAction (v2.119.37) لإغلاق الجدول 12.7.5.3 من PDF 1.7. يقوم THotPDF.AttachFieldFormatAction بتثبيت /AA /F (حدث التنسيق، يتم تشغيله عندما تحتاج قيمة العرض للحقل إلى إعادة تنسيق بعد الالتزام - الاستخدام النموذجي هو تطبيق أقنعة العملة أو التاريخ أو الفاصلة الآلاف عبر AFNumber_Format / AFDate_FormatEx). يقوم THotPDF.AttachFieldValidateAction بتثبيت /AA /V (حدث التحقق، يتم تشغيله بعد أن يقوم المستخدم بإدخال قيمة جديدة - الاستخدام النموذجي هو التحقق من النطاق أو التحقق من صحة الإدخال باستخدام التعبير النمطي عبر event.rc := false). يقوم THotPDF.AttachFieldCalculateAction بتثبيت /AA /C (حدث الحساب، يتم تشغيله عندما يتغير أي حقل تابع وفقًا لترتيب الحساب في /Catalog /AcroForm /CO - الاستخدام النموذجي هو تجميع الإجماليات أو حساب الضرائب). تشترك جميع المساعدات الأربعة في نفس البحث /T في FFormFields، وآليات الاستبدال المتطابقة "آخر استدعاء يفوز"، وحمايات JavaScript لـ PDF/A + PDF/X. يتم الحفاظ على مفاتيح المشغلات الأخرى الموجودة في نفس القاموس /AA (مثل /E /X /D /U /Fo /Bl لمشغلات التعليقات التوضيحية وثلاثة مشغلات حقول النموذج الأخرى) دون تغيير. إعادة هيكلة داخلية: الآن، تفوض AttachFieldKeyStrokeAction إلى مساعد مشترك يسمى _InstallFieldTriggerJSAction؛ سترى رسائل استثناء متطابقة تمامًا من قبل المستخدمين الحاليين لـ v2.119.37.

2026-05-22 Version 2.119.38

  • تسجل وظيفة RegisterUnicodeTTF الآن مطابقة بين نقاط الترميز في المستوى متعدد اللغات التكميلي (SMP، U+10000-U+10FFFF) والرموز في جدول cmap من النوع 12 في الخط المستخدم. في الإصدارات السابقة، كانت هذه الإدخالات يتم تجاهلها بصمت لأن مصفوفة البحث عن الرمز كانت بحجم BMP فقط؛ الإصدار v2.119.38 يضيف قائمة متفرقة موازية (FUnicodeCpToGidSMP) يتم ملؤها جنبًا إلى جنب مع مصفوفة BMP. تعرض الطريقة العامة الجديدة GetUnicodeGlyphForCodepoint(Cp) معرف الرمز لأي نقطة ترميز Unicode تصل إلى U+10FFFF (تستخدم البحث الثنائي في قائمة SMP لنقاط الترميز التي تقع فوق BMP)، أو 0 (.notdef) عندما لا يتم تعيين نقطة الترميز في جدول cmap الخاص بالخط المستخدم. هذه ميزة إضافية فقط: لا تزال خطوط ترميز السداسي المستخدمة في الجانب المنتج، وتدفق /CIDToGIDMap، و ToUnicode CMap مرتبطة بـ BMP، لذلك يتطلب تضمين حرف من SMP في تدفق نص PDF من المستخدمين إرسال أزواج بديلة UTF-16BE بأنفسهم. سيتم توفير إرسال تدفق نص كامل يدعم البدائل في إصدار مستقبلي. تحصل الخطوط التي تستخدم التنسيق 4 فقط على قائمة SMP فارغة كما هو متوقع.

2026-05-22 Version 2.119.37

  • تمت إضافة أداة مساعدة جديدة لتشغيل إجراءات عند الضغط على مفتاح في نموذج AcroForm: `THotPDF.AttachFieldKeyStrokeAction(FieldName, JavaScriptBody)` تقوم بتحديد عنصر النموذج المحدد بناءً على قيمته `/T` وتثبيت إجراء JavaScript في `/AA /K` بحيث يقوم برنامج قراءة ملفات PDF بتشغيل البرنامج النصي في كل مرة يتم فيها الضغط على مفتاح أثناء إدخال النص. تشمل حالات الاستخدام التحقق من صحة الإدخال في الوقت الفعلي (للأرقام أو التواريخ أو التعبيرات النمطية)، وإخفاء الإدخال، وتحديث الحقول المحسوبة بناءً على التغييرات في حقل آخر. هذه الأداة لا تحدث أي تغييرات غير مرغوب فيها: الاستدعاءات المتكررة تستبدل إدخال `/K` مع الحفاظ على أي مفاتيح تشغيل أخرى موجودة بالفعل في قاموس `/AA` (مثل `/F` لتنسيق، `/V` للتحقق من الصحة، `/C` لإعادة الحساب، `/Bl` عند فقدان التركيز، `/Fo` للتركيز، إلخ). تحظر جميع مستويات PDF/A (ISO 19005-1 §6.6.1، -2/-3 §6.5.1) وجميع مستويات PDF/X (ISO 15930 للطباعة) إجراءات JavaScript، لذلك تظهر الأداة رسالة خطأ فورية مع الإشارة إلى المواصفة ذات الصلة إذا كانت أي علامة امتثال موجودة. تعتمد هذه الأداة على قاموس أحداث التشغيل `PDF 1.7 §12.6.3` والجدول 246 الخاص بمفتاح الحقل `/K` في `§12.7.5.3`.

2026-05-22 Version 2.119.36

  • بدأً من الآن، تقبل الدالة `BeginTaggedContent` أربعة خصائص اختيارية لسلسلة المحتوى المحدد وفقًا لجدول 322 في القسم 14.8.4 من مواصفات PDF 1.7 (Lang / Alt / ActualText / ExpansionText) وتقوم بإخراجها كقاموس خصائص BDC مضمن واحدًا مع إدخال MCID الحالي. تحمل الخاصية `Lang` علامة اللغة الطبيعية وفقًا لمعيار BCP-47 المستخدمة بواسطة برامج قراءة الشاشة واستخراج النصوص التي تدعم اللغات. تمثل الخاصية `Alt` الوصف البديل للنصوص غير النصية أو الزخرفية. تمثل الخاصية `ActualText` النص البديل المستخدم في استخراج المحتوى والنسخ واللصق بدلاً من تسلسل الرموز المرئية (وهو أمر ضروري للرموز المتصلة والرموز المزخرفة حيث يختلف الحرف المرئي عن النص الدلالي الأساسي). تحمل الخاصية `ExpansionText` المفتاح `/E` الذي يقوم بتوسيع الاختصارات. تتخطى المعلمات الفارغة الإدخال المقابل، وبالتالي يحتوي القاموس المضمن فقط على المفاتيح التي يقوم المتصل بملئها بشكل صريح، وتبقى مسار الاستدعاء القديم ذو الوسيطين متطابقًا تمامًا مع إخراج الإصدار v2.119.35. يتم الآن التعامل مع تجنب سلاسل الأحرف الحرفية في PDF (الأقواس وعلامة الخط المائل العكسي) تلقائيًا. بالنسبة لأحمال العمل غير ASCII (مثل `ActualText` باللغات الصينية واليابانية والكورية، أو `Alt` باللغات الهندية)، يقوم المتصل بترميز بايتاته مسبقًا كـ UTF-16BE مع BOM U+FEFF ويقوم بتعبئة النتيجة في وسيطة `AnsiString`. يتم أيضًا توفير واجهة برمجة تطبيقات `BeginMarkedContentMCIDProps` على مستوى الصفحة للعملاء الذين يحتاجون إلى تحكم مباشر في BDC دون الحاجة إلى ربط `StructElem` على مستوى أعلى.

2026-05-22 Version 2.119.35

  • تشارك مجموعة الأحرف الأساسية المكونة من 9 أحرف من الفارسية/الأردية، والتي تنتمي إلى مجموعة "Arabic Extended-A"، الآن في وحدة تشكيل النصوص رباعية المواقع الموجودة على جانب الإنتاج في الإصدار v2.85.0. عند تمكين "AutoShapeArabic"، يتم تعيين الأحرف التالية إلى أحرف "Arabic Presentation Forms-A" المقابلة لها في النطاق U+FB50-U+FBFF، بناءً على نفس خوارزمية السياق الربطي المستخدمة لمجموعة الأحرف العربية الأساسية: 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

  • تم الآن فك ترميز تسلسلات الهروب ISO 32000-1 #XX عند استيراد أو نسخ كائنات PDF. يتم الآن التعامل مع أسماء الموارد، وأسماء الألوان الخاصة، وأسماء الأدوار الهيكلية، وغيرها من كائنات الأسماء مثل /PANTONE#20216#20CVC، بحيث تمر عبر HotPDF بقيم البايت المقصودة بدلاً من نسخها مرة أخرى مع علامة رقم مزدوجة.

2026-05-22 Version 2.119.33

  • تتعامل معالجة التواريخ في ملفات PDF الآن بشكل أقرب إلى قواعد سلسلة التواريخ في معيار ISO 32000-1. تستخدم معلومات المستند، والتواريخ المستمدة من XMP، وعلامات التوقيت الخاصة بالتوقيع الآن قيمة `TDateTime` التي يوفرها البرنامج بدلاً من استبدالها بصمت بوقت النظام الحالي، بينما يقبل المحلل الحقول الاختيارية للتواريخ واللاحقات الزمنية القياسية دون إتلاف حقول التاريخ/الوقت المحلية.
  • تم الآن تحسين معالجة مرشحات استيراد ملفات PDF من خلال إضافة أدوات مساعدة صريحة لـ ASCIIHexDecode و ASCII85Decode و RunLengthDecode، كما تم الآن ضبط قيمة "EarlyChange" الافتراضية لـ LZWDecode لتتوافق مع الإعداد الافتراضي لملفات PDF وهو 1. هذا يحسن التوافق مع الصفحات المستوردة أو المنسوخة التي تستخدم مرشحات التدفق القديمة في ملفات PDF.

2026-05-21 Version 2.119.32

  • تتم الآن معالجة ربط الأحرف الإجبارية العربية LAM-ALEF وتضمينها في وحدة تشكيل النصوص من جهة المزود (shaper) بالإصدار v2.85.0. عند تفعيل ميزة AutoShapeArabic، يتم دمج أي تسلسل يبدأ بحرف LAM (U+0644) بأي من أشكاله الأربعة (سواء بالشكل الأصلي أو بأي من أشكاله الأربعة المشكلة) متبوعًا بواحد من أشكال حرف ALEF الأربعة (MADDA U+0622، HAMZA فوق U+0623، HAMZA تحت U+0625، أو الشكل العادي U+0627؛ سواء بالشكل الأصلي أو بعد التشكيل) في حرف ربط واحد من النطاق U+FEF5-U+FEFC. يتم اختيار شكل حرف الربط (المتصل أو المنفصل) بناءً على ما إذا كان حرف LAM قد تم تشكيله كحرف نهاية (FEDE) أو حرف وسط (FEE0) بواسطة وحدة التشكيل. لا تزال ربطات الأحرف الإجبارية العربية الأخرى (مثل Allah U+FDFB والربطات الزخرفية) تتطلب محرك GSUB كامل وتظل خارج نطاق نموذج التشكيل باستخدام الجداول الثابتة. تظل النصوص التي لا تحتوي على LAM-ALEF والمستخدمون الذين يقومون بتعطيل AutoShapeArabic متطابقة تمامًا مع مخرجات الإصدار v2.119.31. ترث ثلاثة مساعدين لـ AcroForm Unicode /AP (سطر واحد، متعدد الأسطر، ومزيج) هذا التغيير تلقائيًا من خلال نقطة الدخول المشتركة _ApplyArabicShaping.

2026-05-21 Version 2.119.31

  • تمت إضافة محول تصدير جديد لنظام DevExpress ExpressPrinting: `dxHotPDFExportReportLinkToFile` و `dxHotPDFExportReportLinkToStream`. تستقبل هذه المحولات أي كائن `TBasedxReportLink` (وهو العائلة المجردة من الروابط التي تربط بين مكونات مثل cxGrid و cxRichEdit و cxScheduler و cxPivotGrid والمكونات القابلة للطباعة الأخرى مع `TdxComponentPrinter`) وتقوم بتمرير كل صفحة معروضة عبر HotPDF بدلاً من مُصدر `dxPSExportToPDF` الخاص بـ DevExpress. يكرر هذا المحول حلقة التصدير الداخلية لـ DevExpress: إعادة بناء التقرير → لكل صفحة → رسم الصفحة على `TMetafileCanvas` → عرض `ShowEnhancedMetafile` في HotPDF. تعرض خيارات التسجيل حقول العنوان والمؤلف والموضوع والكلمات الرئيسية وإصدار PDF والضغط ودقة العرض (RenderDPI). يمتلك هذا المحول نفس قيود الجسر الخاص بملفات التعريف مثل محولات FastReport و QuickReport و ReportBuilder: لا توجد حقول AcroForm، ولا توجد مخططات، ولا توجد خيارات PDF/A أو PDF/X. يقع هذا المحول في المجلد `Lib/Addons/DevExpress/` ولا يتضمن في ملف `HotPDF*.dpk` الرئيسي.

2026-05-20 Version 2.119.30

  • تمت إضافة فئة جهاز جديدة لـ ReportBuilder: `TppHotPDFDevice`، وهي مشتقة من `TppGraphicsDevice`، وبالتالي تتكامل مع سلسلة النشر القياسية في ReportBuilder → الجهاز عند تعيينها إلى `TppReport.PrinterDevice` أو `TppPublisher.Device`. يتم عرض كل صفحة على كائن `TMetafileCanvas` مؤقت (يتم إنشاؤه في `BeforeRenderPage`، ويتم إكماله في `AfterRenderPage)`، ويتم التقاطه كـ `TMetafile`، ثم يتم توجيهه عبر مُستورد EMF الخاص بـ HotPDF (`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. يقوم هذا المكون بجمع ملفات التعريف (Metafiles) الخاصة بكل صفحة والتي يقوم QuickReport بتخزينها بالفعل في `QRPrinter.PageList`، ثم يقوم بتمرير كل منها إلى مُستورد EMF الخاص بـ HotPDF (`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`، مما يجعله يتكامل مع سير عمل `MyReport.Export(MyExportInstance)` المعتاد دون الحاجة إلى تغييرات في النواة الأساسية لـ FastReport. يقوم المحول بتوجيه كل صفحة مُعدة من خلال مُستورد EMF الخاص بـ HotPDF (عبر `TfrxPreviewPages.DrawPage` الخاص بـ FastReport → `TMetafileCanvas` → `HotPDF.ShowEnhancedMetafile`)، بحيث يتم الحفاظ على محتوى الصفحة المتجهي والرستر الذي تم إنشاؤه بواسطة محرك التخطيط القياسي لـ FastReport دون الحاجة إلى تعليمات برمجية منفصلة لكل كائن. تعرض الخصائص قيمًا مثل العنوان والمؤلف والموضوع والكلمات الرئيسية وإصدار PDF ومستوى الضغط ودقة العرض (RenderDPI) للتحكم في ملف PDF الناتج. القيود: لا يدعم حقول AcroForm، ولا يدعم الخطوط العريضة، ولا يدعم معايير PDF/A أو PDF/X (فهذه تتطلب مسار إخراج منفصلاً لكل كائن، وهو مخطط لمراجعة مستقبلية). يتم تضمين المحول في المجلد `Lib/Addons/FastReport4/` وهو ليس موجودًا في ملف `HotPDF*.dpk` الرئيسي؛ يجب على المستخدمين إضافته إلى مشروعهم الخاص جنبًا إلى جنب مع حزمة FastReport المطابقة.

2026-05-20 Version 2.119.27

  • تمت إضافة توقيع PDF قائم على PFX من طرف إلى طرف: THotPDF.SignPDFWithPFX(InputPDFPath, OutputPDFPath, PFXFilePath, Password). تقوم هذه الدالة بتحميل ملف PDF غير موقع يحتوي بالفعل على عنصر نائب لحقل التوقيع المضاف، وتقوم بتحليل ملف PFX / PKCS#12، وتقوم بإنشاء بنية CMS SignedData (RFC 5652) كاملة تغطي البايتات المحددة في /ByteRange، وتقوم بكتابة ملف PDF الموقّع في استدعاء واحد. يتم أيضًا توفير نسخة أخرى تستخدم TStream لعمليات سير العمل في الذاكرة. يجب أن يكون حجم /Contents في ملف PDF كبيرًا بما يكفي لاحتواء بيانات CMS بتنسيق سداسي عشري؛ يغطي الإعداد الافتراضي البالغ 8192 بايت مفاتيح RSA بحجم 1024/2048 بت. يتم دعم ملفات PFX فقط باستخدام PBES2 + AES-256-CBC (الحد الأقصى لمحلل PKCS#12 في الإصدار v2.119.26).
  • وحدة HPDFCMS جديدة: مُنشئ SignedData لـ CMS. تقوم HPDFCMSBuildSignedData بتركيب ContentInfo → SignedData → SignerInfo مع محتوى منفصل، وسمات موقعة (contentType + messageDigest + signingTime) (مرتبة بترتيب تصاعدي وفقًا لـ DER وفقًا لـ RFC 562 §5.4)، ومعرّف IssuerAndSerialNumber للموقع المستخرج من شهادة X.509، وخوارزمية توقيع RSA + SHA-256، وشهادة X.509 ملفوفة في [0] شهادات ضمنية. كما تعرض HPDFCMSSHA256ByteRanges لعملية حساب ملخص ثنائي النوافذ، و HPDFCMSBytesToHex لحقن العنصر النائب لـ /Contents. يغلق هذا التراكم الداخلي للتوقيع الذي بدأ مع 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. يقرأ ملفات .pfx / .p12 من OpenSSL ≥ 3.0، و certutil لنظام Windows 11 والإصدارات الأحدث، وKeychain Access لنظام macOS، ويفك تشفير حمولات SafeBag باستخدام PBES2 (PBKDF2-HMAC-SHA-256 + AES-256-CBC)، ويستخرج معلمات شهادة X.509 بتنسيق DER والمفتاح الخاص RSA. يُرجع سجل THPDFPFXKeyMaterial يحتوي على CertDER، وModulus، وPublicExponent، وPrivateExponent، والذي يمكن للكود الخاص بـ CMS / التوقيع في المراحل اللاحقة استخدامه مباشرةً. يتم اكتشاف كلمة المرور غير الصحيحة من خلال فشل إزالة الحشو في PKCS#7 الذي يلي مفتاح AES غير صالح. تظهر الملفات القديمة بتنسيق 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). تم التحقق من صحتها مقابل متجهات HMAC المحددة في RFC 4231 ومخرجات مرجعية قياسية لـ PBKDF2-SHA-256. بالإضافة إلى وحدة فك ترميز ASN.1 v2.119.23 ووحدات RSA v2.119.24، يكتمل بذلك الأساس المشفر اللازم لمسار فك تشفير SafeBag باستخدام PBES2-AES-256 المستخدم في ملفات PKCS#12 / PFX الحديثة (OpenSSL ≥ 3.0 / Windows 11+).

2026-05-20 Version 2.119.24

  • وحدة HPDFRSA جديدة: توفر عمليات حسابية للأعداد الصحيحة عالية الدقة بالإضافة إلى الأسس المعيارية RSA وتشفير PKCS#1 v1.5 EMSA. تعتبر كبيرة بما يكفي لتوقيع المستندات باستخدام مفاتيح RSA حقيقية بحجم 2048/4096 بت. بالإضافة إلى وحدة فك ترميز ASN.1 الموجودة في الإصدار v2.119.23، يكتمل بذلك المكون الأساسي للتشفير اللازم لعملية التوقيع المستندة إلى PFX التي سيتم إضافتها قريبًا. لا تستخدم أي واجهة برمجة تطبيقات (API) موجهة للمستخدم هذه الوحدة حتى الآن، فهي مجرد بنية تحتية داخلية تنتظر طبقات PKCS#12 و CMS.

2026-05-20 Version 2.119.23

  • وحدة HPDFASN1 جديدة: وحدة فك ترميز مضغوطة لـ BER/DER لمجموعة فرعية من ASN.1، وهي ضرورية لقراءة مخازن مفاتيح PKCS#12، وشهادات X.509، وحاويات CMS/PKCS#7 SignedData. توفر THPDFASN1Node (وصف Tag-Length-Value الذي تم تحليله)، و THPDFASN1ParseNode / ParseAt، و Content / ToInteger / ToBigInt / ToOID / ToString، بالإضافة إلى التكرارات FirstChild / NextSibling / Children. ترفض بشكل صريح تنسيقات BER ذات الطول غير المحدد والترميزات ذات أرقام العلامات العالية (>= 31)، مما يعكس المجموعة الفرعية الصارمة لـ DER. هذه هي البنية التحتية الداخلية لخط أنابيب توقيع PFX الموجود داخل المكتبة والتي ستصل في الإصدارات القادمة - لا توجد واجهة برمجة تطبيقات (API) للمستخدم تعتمد عليها حتى الآن.

2026-05-20 Version 2.119.22

  • تمت إضافة تعريفات جديدة لـ PolyLine و Polygon مع بيانات وصفية كاملة: أضافت 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() لتهيئة السجل الأولي بالقيمة صفر. تتحقق التعريفات الجديدة من وجود رأسين على الأقل، وتزيد تلقائيًا من إصدار المستند (إلى PDF 1.5 أو 1.6 أو 1.7 بناءً على الغرض). تظل التعريفات السابقة المترابطة-Single كما هي دون تغيير.

2026-05-20 Version 2.119.21

  • إضافةً إلى ذلك، تم إضافة خيارات إضافية لتعليقات "Line": الدالة `AddLineAnnotation` تتضمن الآن نسخة ثالثة تقبل سجل `THPDFLineExtras` للتحكم في إدخالات الجدول 175 الاختيارية في القسم 12.5.6.7 من مواصفات PDF 1.6/1.7 — مثل لون الجزء الداخلي (/IC) (للأسهم والرؤوس المعبأة)، وطول الخط (/LL)، وتمديد الخط (/LLE)، وإزاحة الخط (/LLO) (في PDF 1.7)، وعلامة التسمية (/Cap) مع موضعها (/CP) (/Inline أو /Top، في PDF 1.7) بالإضافة إلى إزاحة التسمية (/CO)، والغرض (/IT) (سهم خط أو قياس خط). استخدم الدالة `HPDFDefaultLineExtras()` لبدء العملية من سجل مُهيأ بقيم صفرية. النسخة الجديدة تقوم تلقائيًا بترقية إصدار المستند إلى PDF 1.6 (أو 1.7 عند طلب استخدام /LLO و /CP و /CO). تظل النسختان السابقتان لإنتاج نفس المخرجات بالضبط، ويتم فقط كتابة الإدخالات التي يطلبها المستخدم.

2026-05-20 Version 2.119.20

  • تمت إضافة إجراءات أزرار جديدة: `THPDFButtonAction` تتضمن الآن `baShow` (وهي عكس `baHide` التي ترسل `/H false` لإعادة عرض عنصر مخفي) و `baImportData` (باستخدام `/S /ImportData /F filespec` لتحميل بيانات نموذج FDF عند النقر، وفقًا لـ ISO 32000-1 §12.7.5.4). `baShow` مسموح بها وفقًا للمواصفات في PDF/A و PDF/X؛ بينما `baImportData` محظورة في كل من PDF/A و PDF/X وفقًا لـ ISO 19005-1 §6.6.1 و ISO 15930 الخاصة بالطباعة.
  • تمت إضافة وظيفة جديدة لإخفاء/إظهار الحقول المتعددة: `THPDFPage.AddPushButtonWithHideAction(FieldName, Caption, Targets, Hide, Rectangle, Flags)` تقبل مصفوفة من أسماء الحقول المستهدفة وقيمة منطقية صريحة للإخفاء، بحيث يمكن لزر واحد التحكم في ظهور عناصر واجهة المستخدم المتعددة بنقرة واحدة. إذا كانت مصفوفة `Targets` فارغة، سيتم إرجاع خطأ. كلا من تنسيقات PDF/A و PDF/X يدعمان هذه الوظيفة (تتعلق فقط بإظهار/إخفاء عناصر واجهة المستخدم).

2026-05-20 Version 2.119.19

  • تمت إضافة عنصر تحكم جديد للمستخدم "SubmitForm /Flags": تعرض الدالة `THPDFPage.AddPushButtonWithSubmitAction(FieldName, Caption, URL, Rectangle, SubmitFlags)` مجموعة علامات "Table 237" الكاملة المحددة في "ISO 32000-1 §12.7.5.2" من خلال نوع `THPDFSubmitFormFlags` الجديد. يمكن للمستخدمين الآن دمج خيارات مثل `sffExportFormatHTML` و `sffXFDF` و `sffSubmitPDF` (تنسيق الإرسال)، و `sffGetMethod` (HTTP GET مقابل POST)، و `sffIncludeAnnotations`، و `sffSubmitCoordinates`، و `sffCanonicalFormat`، و `sffIncludeNoValueFields`، و `sffIncludeAppendSaves`، و `sffExclNonUserAnnots`، و `sffEmbedForm` وغيرها، بدلاً من القيمة الثابتة `/Flags 0` (FDF + POST) الموجودة في المسار القديم `baSubmitURL`. لا تزال الدالة `AddPushButtonWithAction(.., baSubmitURL, ..)` الحالية تُصدر `/Flags 0` لضمان التوافق مع الإصدارات السابقة على مستوى البايت. نفس قيود PDF/A و PDF/X الموجودة في `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) وهو مناسب للأوامر الأربعة القياسية وهي: "صفحة تالية" / "صفحة سابقة" / "الصفحة الأولى" / "الصفحة الأخيرة" (يسمح PDF/A بجميع الأوامر الأربعة وفقًا لـ ISO 19005-1 §6.6.1) بالإضافة إلى امتدادات 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" وعناصر "outline /Dest" الرجوع إلى وجهة بالاسم بدلاً من ترميز أرقام الصفحات بشكل ثابت، مما يحافظ على استقرار المراجع المتقاطعة عبر عمليات إدراج/حذف/إعادة ترتيب الصفحات. يغطي التعداد الجديد THPDFDestinationFitMode جميع أوضاع التناسب الثمانية المحددة في المواصفات (XYZ, Fit, FitH, FitV, FitR, FitB, FitBH, FitBV). تظهر هذه الطريقة خطأ في حالة الاسم الفارغ، أو فهرس الصفحة خارج النطاق، أو الاسم المكرر؛ كما أنها تزيد تلقائيًا من إصدار المستند إلى PDF 1.2 عند الضرورة. لا يوجد قيود لـ PDF/A أو PDF/X - تعتبر أدوات التنقل مسموحًا بها في جميع الملفات الشخصية.

2026-05-20 Version 2.119.16

  • تمت إضافة نمط جديد لإنهاء الأسطر في التعليقات التوضيحية للخطوط /LE: الآن، `THPDFPage.AddLineAnnotation` تحتوي على دالة جديدة تقبل أنماط بداية ونهاية الخط. يتم الآن عرض المجموعة الكاملة المحددة في الجدول 176 من القسم §12.5.6.7 من معيار ISO 32000-1 من خلال تعداد `THPDFLineEndingStyle` الجديد: `None`، `Square`، `Circle`، `Diamond`، `OpenArrow`، `ClosedArrow`، `Butt`، `ROpenArrow`، `RClosedArrow`، `Slash`. يمكن الآن عرض التعليقات التوضيحية للخطوط كسهام مناسبة، أو علامات تحديد الأبعاد، أو إشارات داخل برنامج Adobe Acrobat / Foxit دون الحاجة إلى أن يقوم البرنامج برسم رؤوس السهام يدويًا على الصفحة. لا تزال الدالة القديمة التي تستخدم أربعة معلمات تعمل بنفس الطريقة.

2026-05-20 Version 2.119.15

  • تنسيق جديد للعلامات (الإشارات): الآن، يعرض كائن `THPDFDocOutlineObject` خصائص اللون، والخط العريض، والمائل (وفقًا لـ "ISO 32000-1 §12.3.3 Table 153 /C و /F"). يمكن الآن عرض الإشارات بالألوان، أو بالخط العريض، أو المائل، وهو مفيد لتجميع الفصول، أو لتمييز الأقسام غير المكتملة أو التي تتطلب اهتمامًا، أو لمطابقة تصميم العلامة التجارية. اللون الافتراضي هو `clNone` (لا يتم إخراج إدخال /C، وهو مطابق للإخراج السابق)؛ الخط العريض والمائل الافتراضيان هما `false`. يؤدي تعيين الخصائص بعد `AddChild` إلى تحديث قاموس الإشارة مباشرةً، ويؤدي تعيين اللون مرة أخرى إلى `clNone` أو تعيين كل من الخط العريض والمائل إلى `false` إلى إزالة إدخالات /C و /F.

2026-05-20 Version 2.119.14

  • تمت إضافة سجل JavaScript مُعرّف على مستوى المستند: الآن، تعرض THotPDF وظيفة RegisterDocumentJavaScript(Name, Body). يتم تسلسل كل إدخال مسجل في شجرة الأسماء الموجودة في الكتالوج (/Names /JavaScript) (ISO 32000-1 §7.7.4.4 + §12.6.4.16) كقاموس غير مباشر /S /JavaScript /JS. يمكن لعمليات واجهة المستخدم (AcroForm) وأحداث فتح المستند استدعاء الوظيفة المسجلة بالاسم من خلال محرك JavaScript الخاص بالعارض (Acrobat، Foxit). هذا مفيد لمشاركة مجموعة من الأدوات المساعدة للتحقق من الصحة أو التنسيق أو الحساب عبر العديد من عناصر واجهة المستخدم دون تكرار مصدر JavaScript في كل قاموس /A. تظهر هذه الطريقة خطأً في أي مستوى امتثال PDFA (ISO 19005-1 §6.6.1) وأي مستوى امتثال PDFX (ISO 15930 سير عمل ما قبل الطباعة)، وترفض أيضًا الأسماء/المحتويات الفارغة بالإضافة إلى تسجيل الأسماء المكررة.

2026-05-20 Version 2.119.13

  • تمت إضافة دعم لصور مصغرة للصفحات: الآن، تعرض `THPDFPage` الدالتين `SetPageThumbnail(ImageIndex)` و `ClearPageThumbnail`. تستخدم تطبيقات عرض ملفات PDF (مثل Acrobat و Foxit ومشغلات المتصفحات) الإدخال `/Thumb` في الصفحة (ISO 32000-1 §12.3.4) لعرض معاينة مسبقة في لوحة التنقل الخاصة بها دون الحاجة إلى تحويل الصفحة إلى صورة نقطية، وهو أمر مفيد بشكل خاص للأرشيفات التي تحتوي على الكثير من الصور، حيث أن برنامج التحويل إلى صورة النقطية الخاص بالعارض قد يكون بطيئًا. تستخدم الوحدة المساعدة أي صورة تم تسجيلها من خلال `AddImage` أو `AddImageFromFile`، بحيث يمكن للمستخدمين إعداد خريطة معاينة مصغرة ذات دقة أقل وإرفاقها باستدعاء واحد؛ تزيل `SetPageThumbnail(-1)` أو `ClearPageThumbnail` الصورة المصغرة المرفقة مسبقًا. يتم رفع استثناء توضيحي في حالة استخدام فهارس صور خارج النطاق.

2026-05-20 Version 2.119.12

  • تم إصلاح مشكلة توافق PDF/A: الآن، تقوم الدالة `AddPushButtonWithAction` بإطلاق استثناء عندما يتم استخدام أنواع الإجراءات `baJavaScript` أو `baResetForm` بأي مستوى من مستويات توافق PDFA (PDF/A-1/2/3). تحظر المعايير ISO 19005-1 §6.6.1 و ISO 19005-2 §6.5.1 و ISO 19005-3 §6.5.1 استخدام إجراءات JavaScript و ResetForm و ImportData في جميع مستويات PDF/A. تظل الإجراءات `baSubmitURL` (SubmitForm) و `baURI` و `baNone` مسموح بها في PDF/A — حيث أن SubmitForm مدرجة في قائمة الإجراءات المسموح بها في §6.6.1. في السابق، كانت عناصر واجهة المستخدم من نوع زر يمكن أن تحمل إجراءات محظورة حتى مع تفعيل PDFACompliance، نظرًا لأن الحماية الموجودة في الإصدار v2.119.54 كانت تغطي فقط مسارات Catalog /AA والإجراء المفتوح على مستوى المستند.
  • تم إصلاح مشكلة توافق معيار PDF/X: الآن، تقوم الدالة `AddPushButtonWithAction` بإطلاق استثناء عند استخدام أنواع الإجراءات `baJavaScript` أو `baResetForm` أو `baSubmitURL` بأي مستوى من مستويات توافق PDF/X. تستبعد سير عمل ما قبل الطباعة المتوافقة مع معيار 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 أنواع التعليقات التوضيحية "Screen" و "3D" و "RichMedia" (الوسائط المتعددة / امتداد Adobe من المستوى 3) عبر جميع مستويات PDF/A. يتم تطبيق نفس القيود أيضًا في حالة `PDFXCompliance`، حيث ترفض سير عمل ما قبل الطباعة وفقًا لمعيار ISO 15930 أنواع التعليقات التوضيحية الخاصة بالوسائط المتعددة.
  • تم إصلاح مشكلة توافق معيار PDF/A-1: الآن، تقوم الدالتان `AddWatermarkAnnotation` و `AddRedactAnnotation` بإظهار خطأ عند تعيين `PDFACompliance` إلى PDF/A-1. تعتبر التعليقات المائية (PDF 1.6) والتعليقات التحريرية (PDF 1.7) أنواعًا فرعية من التعليقات غير متوافقة مع النسخة الأساسية من PDF/A-1 وهي 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: الآن، عند تعيين PDFACompliance إلى PDF/A-1، تظهر رسالة خطأ عند استخدام AddImageWithSMask و AddImageWithSMask32. يحظر معيار 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 جميع تأثيرات الشفافية؛ وتفعيل مجموعات الشفافية على مستوى الصفحة (عن طريق `page /Group /S /Transparency dict`) نموذج تركيب الشفافية للصفحة بأكملها، وهو ما يمثل انتهاكًا مباشرًا للمادة §6.4. لا تزال إصدارات PDF/A-2 و PDF/A-3 تسمح بمجموعات الشفافية على مستوى الصفحة.

2026-05-20 Version 2.119.8

  • تم إصلاح مشكلة توافق PDF/A: الآن، تقوم الدالة RegisterHalftoneState بإطلاق استثناء عندما يكون خيار PDFACompliance مفعلًا ويتم توفير قاموس halftone مخصص (أي، عندما تكون قيمة HTDefaultName هي false). تسمح المعايير ISO 19005-1:2005 §6.2.9 و ISO 19005-2:2011 / ISO 19005-3:2012 §6.3.7 فقط باستخدام الاسم الحرفي "/Default" لـ ExtGState /HT؛ ويُحظر استخدام قواميس halftone المخصصة (الأنواع 1، 5، 6، 10، 16). يظل من الممكن استخدام القيمة HTDefaultName=True لإعادة التعيين إلى قيمة halftone الافتراضية، وهذا يعمل في جميع مستويات PDF/A.
  • تم إصلاح مشكلة تتعلق بالامتثال لمعيار PDF/A: الآن، تقوم الدالة `RegisterSoftMaskState` بإطلاق استثناء عندما يتم تعيين `PDFACompliance` على `PDF/A-1` ويتم توفير قاموس قناع ناعم مخصص (عبر المعامل `SMaskDict`). يحظر معيار ISO 19005-1:2005 §6.4 جميع تأثيرات الشفافية؛ وتفعيل قيمة `/SMask` غير فارغة يؤدي إلى تفعيل الشفافية باستخدام القناع الناعم. لا يزال من الممكن تمرير `SMaskNone=True` لإعادة تعيين الأقنعة الناعمة. لا يزال معيارا PDF/A-2 و PDF/A-3 يسمحان باستخدام الشفافية باستخدام القناع الناعم.

2026-05-20 Version 2.119.7

  • تم إصلاح مشكلة توافق PDF/A: الآن، عند تفعيل خيار PDFACompliance لـ PDF/A-1 أو PDF/A-3، تقوم الدالة AddDocumentAttachment (التي تسمح بتضمين الملفات على مستوى المستند عبر Catalog /Names /EmbeddedFiles) بإظهار خطأ. تمنع المعايير ISO 19005-1:2005 §6.1.11 بشكل صريح استخدام المفتاح /EmbeddedFiles في قاموس أسماء المستند في PDF/A-1. بالنسبة لـ PDF/A-3، يجب تسجيل المرفقات من خلال الدالة AddPDFA3AssociatedFile() لتضمين مصفوفة /AF المطلوبة والمفتاح /AFRelationship وفقًا للـ 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 أو التبديل إلى RegisterUnicodeTTF() مع ملفات الخطوط الفعلية للحصول على مخرجات متوافقة مع PDF/A.
  • تم إصلاح مشكلة تتعلق بالامتثال لمعيار PDF/A: الآن، يتم تضمين الخطوط غير القياسية دائمًا عند تفعيل وضع PDFACompliance، بغض النظر عن إعداد خاصية FontEmbedding. يتم تجاوز تحسين FontEmbedding = false تلقائيًا في وضع 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 في قاموس الكتالوج. الآن، يؤدي استدعاء SetActionScript بأي قيمة لـ PDFACompliance إلى ظهور استثناء وصفي. كإجراء إضافي، تم أيضًا تقييد مسارات OpenAction JavaScript و Catalog /AA في EndDoc لتجاهل الإخراج بصمت عند تفعيل PDFACompliance، مما يضمن عدم كتابة أي مفاتيح غير متوافقة حتى عبر المسارات الداخلية.

2026-05-20 Version 2.119.4

  • تم إصلاح مشكلة توافق PDF/A: الآن، يتم إجبار قيمة "AcroForm /NeedAppearances" على أن تكون "false" عند تفعيل "PDFACompliance"، بغض النظر عن إعداد "AutoFormAppearances". تتطلب المواصفات 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 المضمنة تدفقًا "/CIDSet" في وصف الخط (FontDescriptor) عند تفعيل وضع توافق PDFACompliance. تتطلب المعايير ISO 19005-1:2005 §6.3.5 و ISO 19005-2:2011 / ISO 19005-3:2012 §6.2.11 أن تحتوي مجموعات CIDFont على تيار بتي "/CIDSet" يشير إلى قيم CID الموجودة في برنامج الخط المضمن. تستخدم HotPDF ترميز Identity-H حيث يساوي CID نقطة الرمز Unicode، لذلك يتم إنشاء CIDSet مباشرةً من مجموعة نقاط الرمز المستخدمة في المستند. يتم ضغط تيار البت باستخدام FlateDecode وإرفاقه بوصف الخط (FontDescriptor) ككائن تيار غير مباشر. هذا يصحح ثغرة أمنية سابقة لم يتم اكتشافها في جميع مستويات 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 أن تحتوي كل تعليق توضيحي من هذا القبيل على قاموس مظهر واحد على الأقل (بالشكل "N" كـ XObject). يتم إخراج كائن XObject فارغ للامتثال لمتطلبات البنية؛ تستخدم معظم برامج عرض PDF آليات العرض المضمنة الخاصة بها للأنواع القياسية من التعليقات التوضيحية بغض النظر عن محتوى دفق ‎/AP. تم استثناء التعليقات التوضيحية للروابط والنوافذ المنبثقة بشكل صريح من خلال المعيار وهي تظل دون تغيير. لا ينطبق هذا المطلب على PDF/A-1 (يقتصر معيار ISO 19005-1 §6.5.3 فقط على تنسيق ‎/AP عند وجوده، وليس على وجوده).

2026-05-20 Version 2.119.1

  • تم إصلاح مشكلة توافق PDF/A: تم الآن ضبط علامة الطباعة (/F) تلقائيًا لجميع أنواع التعليقات التوضيحية غير المرتبطة بالعناصر التفاعلية (مثل الملاحظات النصية، والطوابع، والخطوط، والأشكال، والروابط التشعبية، وروابط الانتقال، وروابط الانتقال العكسي، وروابط URI) عندما تكون ميزة PDFACompliance مفعلة (البت 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 في قاموس الكتالوج؛ الآن، عند استدعاء RegisterOptionalContentGroup ضمن PDF/A-1، يتم إطلاق استثناء وصفي يوجه المستخدمين إلى استخدام PDF/A-2 أو إصدار أحدث إذا كانت المجموعات الاختيارية مطلوبة. تم أيضًا تعطيل إخراج /OCProperties في نهاية المستند لمنع عدم الامتثال الصامت، حتى في حالة تسجيل المجموعات الاختيارية بطريقة ما.

2026-05-20 Version 2.119.0

  • تمت إضافة دعم حاوية XAdES-in-PDF وفقًا للمعيار ETSI EN 319 142-2 V1.2.0 §6.2 (الجزء الثالث والأخير من سلسلة B/C/D). يتم تضمين بايتات XML الموقعة بواسطة XAdES والمقدمة من المستخدم كملف مضمن في PDF، ويتم تسجيل مواصفات الملف في مصفوفة /AF في الكتالوج، ويتم تعيين /AFRelationship وفقًا لترقيم PDF 2.0 المحدد من قبل المستخدم. هذا مجرد غلاف من جانب المُنتج - إنشاء التوقيع الفعلي XAdES (XML-DSig + ETSI EN 319 132-1 QualifyingProperties + طابع زمني RFC 3161 مضمن في xades:UnsignedSignatureProperties) هو مسؤولية مكتبة XML التشفيرية الخاصة بالمستخدم (مثل Apache Santuario، .NET SignedXml، libxmlsec، Saxon مع امتدادات XAdES، إلخ).
  • تمت إضافة طريقة جديدة `THotPDF.AddXAdESAssociatedFile(FileName, XMLBytes, Description, MimeType, Relationship)`. القيم الافتراضية هي: `MimeType` بقيمة `'application/xml'` (تستخدم أيضًا بشكل شائع `'application/vnd.etsi.asic-e+zip'` لأرشيفات ASiC-E)، و `Relationship` بقيمة `'Source'` (يشير ملف XML الموقّع بـ XAdES إلى المحتوى الرئيسي للمستند). تُرجع هذه الطريقة القاموس `Filespec` غير المباشر حتى يتمكن المستخدمون من إرفاق بيانات وصفية إضافية أو إحالات مرجعية من إدخالات `Catalog` مخصصة.
  • بغض النظر عن PDF/A: على عكس وظيفة `AddPDFA3AssociatedFile` الموجودة في الإصدار v2.108 (والتي تتطلب PDFACompliance='3*')، فإن هذه الوظيفة لا تتطلب توافق PDF/A — XAdES داخل ملف PDF هو فئة ملف خاصة به وفقًا للمواصفة PAdES الجزء 2، الإصدار 1.2.0، الفقرة 6.
  • تم إصلاح خطأ بالغ في الدالة `_EscapePDFNameBytes` (PDF 1.7 ISO 32000-1 §7.3.5 + الجدول 2). في السابق، كانت الدالة تقوم فقط بتحويل البايتات الموجودة خارج النطاق [0x21..0x7E] والحرف '#'. وكانت أحرف تحديد تنسيق PDF (`/ ( ) < > [ ] { } %`) تتطلب، وفقًا للمواصفات، أن يتم تحويلها إلى `#XX` داخل الأسماء، ولكنها كانت تترك كما هي. ونتيجة لذلك، كانت برامج القراءة الصارمة تقوم بتحليل أسماء مثل `/Subtype /application/xml` على أنها رمزين اسمين منفصلين (/application متبوعًا بـ /xml)، مما أدى إلى تعطيل التعرف على EmbeddedFile /Subtype. في الإصدار v2.119، يتم تحويل جميع أحرف التحديد العشرة وفقًا للمواصفات؛ بينما تظل الأسماء التي ليست أحرف تحديد (والتي تشكل الغالبية العظمى من مخرجات HotPDF) مطابقة للبايت الأصلي. الآن، تقوم أنواع MIME الخاصة بـ PDF/A-3 الملحق E (الإصدار v2.108) بالإخراج بشكل صحيح (`/application#2Fxml` بدلاً من `/application/xml` التالف).
  • تم إغلاق سلسلة PAdES B/C/D عند 3 تحديثات: v2.117 (تمت إضافة ملفات تعريف موسعة E-BES / E-EPES / E-LTV وفقًا للجزء 2 §5) + v2.118 (تمت إضافة قيم أولية وفقًا لـ ISO 32000-1 §12.7.5.5 + الجزء 2 §4.2.6) + v2.119 (تمت إضافة XAdES-in-PDF وإصلاح مشكلة الهروب من المحدد وفقًا للجزء 2 §6.2). بالإضافة إلى v2.109 - v2.116، يغطي HotPDF الآن النطاق الكامل لإنشاء PAdES، بما في ذلك الملفات التعريفية الأساسية والملفات التعريفية الموسعة وختم المستندات ومعلومات التحقق من DSS وتوسعات ESIC وقيود التوقيع عبر القيم الأولية، وحاوية XAdES-in-PDF.
  • تمت عملية تجميع نظيفة لنظامي التشغيل Win32 و Win64؛ وتم إعادة تجميع جميع الإصدارات الأساسية من v2.108 إلى v2.118 دون تغيير. تم إضافة اختبارات جديدة لـ "smoke" و "smoke_pades_xades" تتضمن مسارين إيجابيين (ملف XML موقع باستخدام XAdES كـ `/AFRelationship /Source` وأرشيف ASiC-E كـ `/Data`) وأربعة مسارات للرفض (اسم ملف فارغ، بايت XML فارغ، نوع MIME فارغ، علاقة غير صالحة). يقوم مدقق Python بفحص كلا الملفين بالكامل، بما في ذلك الصيغتين `/Subtype /application#2Fxml` و `/Subtype /application#2Fvnd.etsi.asic-e+zip`. تم إعادة تشغيل جميع اختبارات "PDF/A-3 / PAdES / PDF/X" نظيفة للإصدار v2.108.

2026-05-20 Version 2.118.0

  • تتضمن قيم البذور (Seed Values) وفقًا لمعيار 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 (الخطوة 2 من 3 في سلسلة B/C/D). يحدد قاموس قيم البذور (SV) المرفق بحقل التوقيع القيود المفروضة على أداة التوقيع التي يستخدمها برنامج القراءة - أي المعالج المسموح به، وأي نوع فرعي (SubFilter)، وأي طريقة تجزئة (digest method)، وما إذا كانت معلومات الإلغاء إلزامية، وأي إصدار PDF أدنى مطلوب.
  • تمت إضافة طريقة جديدة `THotPDF.AttachPAdESSeedValue(FieldName, SubFilters, DigestMethods, ForceSubFilter, ForceDigestMethod, AddRevInfo, MinPDFVersion, ForceMinPDFVersion)`. تبحث هذه الطريقة عن حقل التوقيع المحدد في قائمة حقول AcroForm (يجب أن يكون قد تم إنشاؤه بالفعل بواسطة استدعاء سابق لـ `AddPAdESSignatureField` أو `AddDocumentTimestampSignature`) وتضيف إليه قاموسًا فرعيًا `/SV` بالقيود التي يوفرها المتصل.
  • تم إصدار إدخالات قيمة البذرة (كما هو موضح في الجدول 234):
    • `/Type /SV`
    • `/SubFilter` مصفوفة من الأسماء - على سبيل المثال: [/ETSI.CAdES.detached]
    • `/DigestMethod` مصفوفة من الأسماء - على سبيل المثال: [/SHA256 /SHA384 /SHA512]
    • `/AddRevInfo` قيمة منطقية - يجب على أداة التوقيع تضمين OCSP/CRL في CMS
    • `/V` رقم - الإصدار الأدنى لملف PDF (على سبيل المثال: 1.7)
    • `/Ff` أعداد صحيحة تمثل علامات بت (الجدول 235) - كل معلمة Force* تقوم بتعيين البت المقابل، وبالتالي يجب على أداة التوقيع احترام هذا القيد (البت 2 = فرض SubFilter، البت 3 = فرض V، البت 6 = فرض AddRevInfo، البت 7 = فرض DigestMethod)
  • تضمن آليات الحماية للامتثال للمواصفات: يحظر الجزء الثاني من معيار PAdES، الإصدار V1.2.0، الفقرة §4.2.6، استخدام قيم أولية قد تجبر أدوات التوقيع على انتهاك ملف تعريف PAdES (على سبيل المثال، تحديد مرشح PKCS#1). لا يفرض THotPDF هذا الإجراء من جانب المُنتج؛ يتحمل المُستدعي مسؤولية تمرير القيم المسموح بها فقط وفقًا للمواصفات (مثل `'adbe.pkcs7.detached'` أو `'ETSI.CAdES.detached'` لـ SubFilter، و SHA-256+ لـ DigestMethod). يوضح التعليق المساعد القيود بوضوح.
  • تمت عملية تجميع نظيفة لنظامي التشغيل Win32 و Win64؛ وتم إعادة تجميع جميع الإصدارات الأساسية من v2.108 إلى v2.117 دون أي تغيير. أداة "smoke" الجديدة، المسماة "smoke_pades_seedvalue"، تقوم بإنشاء حقل PAdES-B-T ثم تقوم بإرفاق مجموعة كاملة من قيود قيمة البذور (حيث يتم تقييد SubFilter بـ ETSI.CAdES.detached، ويتم تقييد DigestMethod بـ SHA256/384/512، ويتم تعيين AddRevInfo على true، ويتم تعيين MinPDFVersion على 1.7، ويتم تعيين جميع بتات الإجبار). يقوم مدقق Python بفحص القاموس الفرعي "/SV" ويتحقق من شكل كل إدخال؛ كما أنه يختبر مسار الرفض لـ "اسم الحقل غير المعروف".
  • السلسلة، الخطوة 3 (الإصدار v2.119): حاوية XAdES داخل ملف PDF، وفقًا للجزء 2، الإصدار V1.2.0، الفقرة §6، تغلق سلسلة B/C/D. من جانب المُنتج، هذا عبارة عن طبقة رقيقة تغلف البنية التحتية الحالية لـ HotPDF الخاصة بـ EmbeddedFile و Catalog/AF (مساعد PDF/A-3 بالإصدار v2.108)، بالإضافة إلى دلالات /AFRelationship التي يتوقعها الجزء الثاني من PAdES، الإصدار V1.2.0، الفقرة §6.2.2، لبيانات XML الموقعة بـ XAdES.

2026-05-20 Version 2.117.0

  • تمت إضافة ملفات تعريف PAdES الموسعة وفقًا لـ ETSI EN 319 142-2 V1.2.0 §5 (الخطوة 1 من 3 في سلسلة B/C/D). تحدد الفقرة 1 الأساسيات (V1.2.1 §6 B-B / B-T / B-LT / B-LTA) مجموعات ثابتة من سمات CMS؛ تحدد الفقرة 2 §5 مجموعة "موسعة" متوازية من الملفات التعريفية (E-BES / E-EPES / E-LTV) مع مرونة أكبر في سمات CMS للمستخدمين الذين يحتاجون إلى مرونة تتجاوز الأساسيات (على سبيل المثال، عمليات نشر المؤسسات متعددة السياسات، وملفات تعريف CAdES مخصصة داخل غلاف PAdES).
  • تمت إضافة قيم إضافية لـ `AddPAdESSignatureField` إلى معلمات الملف الشخصي، بالإضافة إلى الأسماء الأساسية الأربعة:
    • `'E-BES'` — توقيع أساسي وغير غامض مع ربط شهادة التوقيع عبر سمة ESS الخاصة بشهادة التوقيع (مكافئ لـ CAdES-BES داخل مغلف PAdES). الحد الافتراضي للميزانية هو 16 كيلوبايت للمحتوى.
    • `'E-EPES'` — E-BES + سمة معرف سياسة التوقيع الصريحة الموقعة. الحد الافتراضي للميزانية هو 16 كيلوبايت؛ عادةً ما يمرر المتصل 18-20 كيلوبايت لتناسب بايت معرف سياسة OID والمؤهلات.
    • `'E-LTV'` — التحقق طويل الأجل مع سلسلة شهادات مرنة لسمة CMS + تضمين الإلغاء. يتم توسيعها تلقائيًا إلى 20 كيلوبايت كحد أدنى (تعكس B-LT).
  • تنسيق البيانات الأساسي من جهة الإنتاج متطابق لكل من الإصدارات الأساسية والمتقدمة - فجميعها تستخدم مرشح البيانات الفرعية `ETSI.CAdES.detached`، ونمط الإشارة `/ByteRange` و `/Contents` نفسه، بالإضافة إلى نفس البنية التحتية لـ DSS و ESIC (الإصدار v2.110 / v2.116). يكمن الفرق في مستوى الإصدار في تكوين سمات التوقيع الموجودة في CMS، والتي تنتجها مكتبة التشفير الخاصة بالمستخدم. يختلف سلسلة "Profile" فقط في التشخيص الخاص بالتحقق وفي الحد الافتراضي لـ `/Contents`. لا تقوم THotPDF بترميز CAdES-BES مقابل CAdES-EPES مقابل CAdES-T داخل قاموس PDF نفسه.
  • تم تحديث وثائق المساعدة الخاصة بـ PAdES لتوضيح مسؤوليات المستخدم التي يكشف عنها الجزء الثاني، الإصدار V1.2.0، الفقرة §4.2: اختيار تجزئة SHA-256 (مع التخلص التدريجي من SHA-1)، وجود SignerInfo واحد فقط لكل حقل Sig، وعدم استخدام شهادات RFC 5755، ومتطلبات E-EPES لتضمين السمة "signature-policy-identifier" الموقعة. تظل العناصر المتعلقة بمجال المستخدم خارج نطاق مسؤولية المُنتج، ولكن العقد الآن واضح بشكل صريح في واجهة برمجة التطبيقات.
  • تمت عملية تجميع نظيفة لنظامي التشغيل Win32 و Win64؛ وتمت إعادة تجميع جميع الإصدارات الأساسية من v2.108 إلى v2.116 دون أي تغيير. تم توسيع نطاق `smoke_pades_signature` بإضافة 3 حقول جديدة (SigEBES / SigEEPES / SigELTV)، وتم اختبار كل قيمة جديدة من خلال مسارات "التوسيع التلقائي" و "الميزانية المحددة" و "الميزانية الافتراضية". تم توسيع نطاق أداة التحقق الخاصة بـ Python لتغطية جميع الحقول السبعة، ويتم التأكد من وجود امتداد ESIC في قسم "Catalog" (تم نقل هذا التغيير من الإصدار v2.116).
  • الخطوة الثانية من سلسلة B/C/D: الإصدار v2.118 يضيف قيم البداية (PDF 1.7 §12.7.5.5 + ETSI EN 319 142-1 V1.2.1 §5.5 + الجزء الثاني V1.2.0 §4.2.6) بحيث يمكن لحقول توقيع PAdES تحديد قيود المعالج/SubFilter/طريقة التجزئة التي يجب على قارئ المستهلك احترامها أثناء التوقيع. الخطوة الثالثة: الإصدار v2.119 يضيف دعم حاوية XAdES-in-PDF وفقًا للجزء الثاني V1.2.0 §6 (ملف XML الموقّع بـ XAdES مدمج كـ EmbeddedFile + ارتباط الدليل /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 Document Time-stamp) + EU 2015/1506 (الاعتراف بقطاع الخدمة العامة). تظل النسخ الأساسية من HotPDF v2.109 - v2.111 (B-B / B-T / B-LT / B-LTA + طابع زمني مستقل) متوافقة مع نفس تنسيق البيانات؛ هذا الإصدار يغلق فجوتين في جانب المُنتج كشفت عنه الإصدارات الجديدة من المواصفات.
  • تمت إضافة إدخال `/Type "DSS"` إلى قاموس 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 pre-flight و EU DSS و callas pdfaPilot) هذه الإدخالات لتحديد المستند على أنه حاوية PAdES تعلن عن امتدادات PDF 1.7 + ESIC من المستوى 1.
  • تم إصلاح خطأ بالغ في مسار "الذهاب والإياب" الخاص بـ `EnsurePAdESDSS`. قبل الإصدار v2.116، كان البرنامج يقوم بإعادة حل قاموس DSS في كل مرة يتم فيها استدعاؤه من خلال `Catalog.GetIndexedItem(FindValue('DSS'))`، والذي يُرجع الارتباط غير المباشر THPDFLink المخزن في الكتالوج بدلاً من قاموس DSS الفعلي. أدى التحويل الصامت إلى THPDFDictionaryObject إلى تحويل نوع المؤشر بشكل خاطئ، مما تسبب في أن كل استدعاء لاحق لـ `AddPAdESDSSCertificate` / `AddPAdESDSSOCSP` / `AddPAdESDSSCRL` / `AddPAdESDSSVRI` بعد الاستدعاء الأول يتجاهل بشكل صامت إضافة العنصر إلى المصفوفة (نظرًا لأن مرجع المصفوفة تم حله إلى قيمة فارغة، وأرجع `FindValue` القيمة -1، وتم تفعيل آلية الخروج المبكر إذا كانت الفهرسة أقل من الصفر). يقوم إصلاح v2.116 بتخزين مرجع القاموس الفعلي في حقل `FPAdESDSSDict` بحيث تستخدم الاستدعاءات اللاحقة ذاكرة التخزين المؤقت مباشرةً. الآن، يولد اختبار `smoke_pades_dss` بشكل صحيح 2 شهادة + 1 OCSP + 1 CRL + 1 إدخال VRI (في السابق، كانت الشهادة الأولى فقط هي التي تم تضمينها في /DSS، وكانت المصفوفات /OCSPs و /CRLs فارغة).
  • تم تحديث التعليقات التوضيحية في ملفات مساعدة PAdES لتغطية مسؤوليات المستخدم، وذلك بناءً على الجزء الثاني، الإصدار 1.2.0، القسم 4.2: إيقاف استخدام SHA-1 (يجب على المستخدمين اختيار SHA-256+ لـ CMS)، وجود SignerInfo واحد فقط لكل توقيع PDF (الجزء الثاني، القسم 4.2.1، الفقرة h / الجزء الأول، القسم 4.1، الفقرة a)، يجب عدم استخدام شهادات السمات RFC 5755 (الجزء الثاني، القسم 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` بالإضافة إلى `Catalog /Extensions /ESIC /BaseVersion /1.7 /ExtensionLevel 1`. كما أن `smoke_pades_doctimestamp` يتحقق من نفس امتداد ESIC ويقبل مستطيلًا (`[0 H 0 H]`) ذو مساحة صفرية ومقلوبًا رأسيًا (حيث H هو ارتفاع الصفحة). تم تحديث وثائق التدقيق والملاحظات الفنية للإشارة إلى المعايير EN 319 142-1 V1.2.1 / الجزء 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) ترفض المستندات التي تحتوي عليها.
  • تم رفض أنواع التعليقات التوضيحية التالية (يتم رفضها بغض النظر عن أي قيمة PDFXCompliance ∈ {X-1a, X-3, X-4}):
    • FileAttachment — لا تستخدم مطبعة الأوفست الملفات المضمنة.
    • Sound — لا يوجد مكان للوسائط المتعددة في سير عمل الطباعة.
    • Movie — نفس مبررات الوسائط المتعددة.
    الآن، عند استدعاء كل نقطة دخول (AddFileAttachmentAnnotation، AddSoundAnnotation، AddMovieAnnotation)، يتم إظهار رسالة خطأ تتضمن قسم المواصفات وقيمة PDFXCompliance عند استدعائها ضمن أي ملف PDF/X.
  • الأفعال المحظورة (يتم رفضها في أي حالة من حالات الامتثال لـ PDFX): تشغيل / JavaScript / إرسال النموذج / استيراد البيانات / فيديو / صوت / إعادة تعيين النموذج. يجب ألا تؤدي سير عمل الطباعة المسبقة إلى تشغيل أي برنامج خارجي؛ يجب أن يتم استهلاك ملف PDF فقط بواسطة جهاز الطباعة / RIP، ولا يتم تنفيذه. الآن، عند استخدام AddLaunchLink، يتم إظهار رسالة خطأ في أي ملف PDF/X (لا تعرض HotPDF الإجراءات الأخرى كمسارات واجهة برمجة تطبيقات عامة، لذلك يتم تنفيذها تلقائيًا).
  • أصبحت سلسلة PDF/X الآن مكتملة من الناحية الوظيفية: الإصدار v2.112 (مع خيار التفعيل + هوية XMP + اسم Trapped) + الإصدار v2.113 (OutputIntent + ICC GTS_PDFX) + الإصدار v2.114 (حماية الشفافية + فرض PageBox) + الإصدار v2.115 (حظر التعليقات والإجراءات). تم تغطية جميع ملفات التعريف الثلاثة القياسية في الصناعة (X-1a:2001، X-3:2002، X-4:2010). لا يزال المستخدم يقوم بإنشاء محتوى ما قبل الطباعة على مستوى الصفحة (أهداف CMYK صحيحة، تضمين الخطوط عبر أداة تقليل TTF للإصدار v2.84، أبعاد TrimBox تتطابق مع التصميم، BleedBox عند الحاجة) ولكن جميع آليات الامتثال الهيكلي موجودة.
  • تمت عملية تجميع نظيفة لنظامي التشغيل Win32 و Win64. تم إعادة تجميع جميع الإصدارات الأساسية من v2.108 إلى v2.114 دون أي تغيير. تم توسيع نطاق اختبار `smoke_pdfx_optin` ليشمل 4 اختبارات رفض جديدة (TestRejectFileAttachmentAnnot, TestRejectSoundAnnot, TestRejectMovieAnnot, TestRejectLaunchAction) - حيث يقوم كل اختبار بإخراج النوع المحظور ضمن أحد ملفات PDF/X الثلاثة، ويؤكد الرفض بشكل صحيح. الآن، يغطي الاختبار الكلي 11 سيناريو: 3 سيناريوهات إخراج إيجابية و 8 مسارات رفض.
  • تمت إضافة سلسلتين متوازيتين متعددة الإصدارات إلى هذه المجموعة: PAdES (ETSI EN 319 142، الإصدار 2.109 - 2.111، 3 تعديلات، حيث يتم دعم جميع خيارات B-B / B-T / B-LT / B-LTA بالإضافة إلى الطابع الزمني المستقل) و PDF/X (ISO 15930، الإصدار 2.112 - 2.115، 4 تعديلات، حيث تم وضع جميع آليات الامتثال الهيكلي من جانب المنتج لـ X-1a / X-3 / X-4).

2026-05-20 Version 2.114.0

  • سلسلة إنتاج PDF/X (ISO 15930) للجزء الثالث/الرابع: إضافة آلية للشفافية وتطبيق قيود مربع الصفحة وفقًا لمعايير ISO 15930-1:2001 / ISO 15930-3:2002 / ISO 15930-7:2010 بالإضافة إلى ISO 32000-1 §14.11.2. يغطي هذا الجزء قيودين مستقلتين تنطبقان على كل صفحة؛ وتتبع آلية التقسيم نمط الشفافية وميزات الصفحة الخاص بالإصدار v2.103 من PDF/A-1.
  • تحديث يتعلق بالشفافية (المقطع 7.5): ترفض الدالة RegisterExtGState قيم ألفا للملء أقل من 1 (/ca)، أو قيم ألفا للحد أقل من 1 (/CA)، أو أوضاع المزج خارج المجموعة {Normal, Compatible} عندما تكون قيمة PDFXCompliance هي 'X-1a' أو 'X-3'. تتطلب معايير PDF/X-1a (ISO 15930-1:2001) و PDF/X-3 (ISO 15930-3:2002) الإصدار الأساسي 1.3 من PDF، والذي يسبق ميزة الشفافية في الإصدار 1.4 من PDF. تسمح معايير PDF/X-4 (ISO 15930-7:2010، الإصدار الأساسي 1.6 من PDF) بشكل صريح باستخدام الشفافية، لذلك لا يتم تفعيل هذا التحديث في حالة استخدام X-4. يوضح التحذير سبب المشكلة ويقترح الترقية إلى X-4 إذا كانت الشفافية مطلوبة.
  • تطبيق قيود PageBox (المادة 14.11.2): الطريقة الجديدة `EnsurePDFXPageBoxes` تفحص كل صفحة وتتطلب وجود واحد على الأقل من /TrimBox أو /ArtBox. وجود MediaBox وحده غير كافٍ لأنه يمثل مساحة التصميم، وليس أبعاد الصفحة النهائية التي يحتاجها مطبع. في حالة عدم وجود PageBoxes، يتم إظهار رسالة خطأ تتضمن رقم الصفحة (يبدأ من 1)، والإشارة إلى القسم ذي الصلة في المواصفات، وتوقيع استدعاء SetTrimBox الموصى به. تقوم بوابة PDFXCompliance في نهاية المستند باستدعاء EnsurePDFXPageBoxes تلقائيًا بعد فحص OutputIntent.
  • النمط النموذجي للمستخدم: بعد ضبط إعدادات PDFXCompliance و Trapped وإضافة AddPDFXOutputIntent، يجب أن تتضمن كل صفحة في المستند `CurrentPage.SetTrimBox(Left, Bottom, Right, Top)` بما يتطابق مع أبعاد المنتج النهائي (على سبيل المثال، 0 0 612 792 لـ US Letter، أو 0 0 595 842 لـ A4). يوصى باستخدام BleedBox ولكنه ليس إلزاميًا.
  • تمت عملية تجميع نظيفة لنظامي التشغيل Win32 و Win64؛ وتمت إعادة تجميع جميع الإصدارات الأساسية من v2.108 إلى v2.113 دون أي تغيير. تم توسيع نطاق `smoke_pdfx_optin` ليشمل: استدعاء إيجابي لـ `SetTrimBox` في كل ملف من الملفات الثلاثة، ومسار رفض `TrimBox` المفقود، ومسار رفض الشفافية X-1a (حيث يؤدي استدعاء `RegisterExtGState` مع `ca=0.5` إلى حدوث خطأ)، ومسار إيجابي لـ X-4 للسماح بالشفافية (حيث ينجح نفس الاستدعاء ويتم تسجيل `ExtGState`). يقوم مدقق Python بفحص كل قاموس `/Type /Page` ويتحقق من وجود واحد على الأقل من `/TrimBox` أو `/ArtBox` لكل صفحة.
  • تبقى شريحة 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: تطبيق إعدادات الإخراج وملفات تعريف ICC وفقًا لمعايير 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. تتطلب كل ملف تعريف PDF/X وجود إدخال واحد على الأقل من النوع "/Type /OutputIntent /S /GTS_PDFX" يحدد ظروف الطباعة المستهدفة ويوفر تدفق ملف تعريف ICC الخاص بـ "/DestOutputProfile" - تستخدم مطابع الطباعة هذه المعلومات لمطابقة ألوان ملف PDF مع مجموعة الألوان الخاصة بآلة الطباعة/الورق/الحبر المستخدمة.
  • تمت إضافة وظيفة مساعدة جديدة `AddPDFXOutputIntent(OutputConditionIdentifier, Info, ICCProfileStream, NumComponents, AlternateCS)` والتي تحاكي الوظيفة v2.102 الخاصة بـ PDF/A، ولكنها تصدر النوع الفرعي GTS_PDFX بدلاً من GTS_PDFA1. تتحقق هذه الوظيفة من أن `ICCProfileStream` ليس فارغًا وأن `OutputConditionIdentifier` ليس فارغًا؛ وتستدعي `RegisterICCProfile` لتضمين الملف الشخصي (وتتعامل تلقائيًا مع مطابقة مساحة الألوان البديلة `/Alternate` مع `NumComponents`) وتستدعي `AddOutputIntent` لإنشاء قاموس `OutputIntent`.
  • إنفاذ قاعدة EndDoc: عند تعيين PDFXCompliance، يتحقق EnsurePDFXOutputIntent من مصفوفة OutputIntents ويتطلب وجود عنصر واحد على الأقل يحتوي على /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) قم بتحميل ملف تعريف ICC الخاص بـ CMYK (FOGRA39 / SWOP / إلخ) في كائن `TStream`, 4) `Doc.AddPDFXOutputIntent('FOGRA39 (ISO 12647-2:2004)', '', ICCStream, 4, 'DeviceCMYK')`, 5) قم بتصميم المحتوى, 6) تقوم `Doc.EndDoc` بإصدار `OutputIntent` المرتبط من مصفوفة `Catalog /OutputIntents`; تقوم أدوات المعاينة المسبقة (مثل Adobe Acrobat و Enfocus PitStop و callas pdfaPilot) بالتحقق من صحة إعداد إدارة الألوان.
  • تمت عملية تجميع نظيفة لنظامي التشغيل Win32 و Win64؛ وتم إعادة تجميع جميع الإصدارات الأساسية v2.108 و v2.109 و v2.110 و v2.111 و v2.112 دون أي تغيير. تم توسيع نطاق `smoke_pdfx_optin` (الذي كان في الأصل v2.112) ليشمل: تسجيل ملف تعريف ICC وهمي وإضافة `AddPDFXOutputIntent` في كل من ملفي التعريف الثلاثة (X-1a → FOGRA39 CMYK، X-3 → SWOP CMYK، X-4 → sRGB RGB)، وإضافة مسار للرفض يتحقق من أن عدم وجود `OutputIntent` يؤدي إلى حدوث خطأ. تم توسيع نطاق مدقق Python لتغطية كل القواميس والتحقق من وجود الإدخال `/Type /OutputIntent /S /GTS_PDFX` مع إخراج `/DestOutputProfile`.
  • تتضمن تحديثات PDF/X المتبقية: الإصدار v2.114 يضيف آلية للتعامل مع الشفافية (حيث يتم رفض X-1a / X-3 إذا كانت قيم ألفا للملء/الحد أقل من 1 أو إذا كانت هناك مكونات Bitmap غير عادية؛ بينما يسمح X-4 بالشفافية) بالإضافة إلى فرض استخدام PageBox (يجب أن تحتوي كل صفحة على TrimBox أو ArtBox وفقًا للقسم §14.11.2). الإصدار v2.115 يختتم السلسلة عن طريق حظر الإجراءات / التعليقات التوضيحية / 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 هو الجزء الأول من أربعة: إضافة خاصية جديدة وبيانات تعريف. تم حفظ تقرير التدقيق الكامل وخطة العمل لأربعة إصدارات في الملف .superpowers/specs/2026-05-19-pdfx-compliance-audit.md.
  • تمت إضافة خاصية جديدة `PDFXCompliance: AnsiString` إلى THotPDF، وتقبل القيم التالية: `''` (معطل، الافتراضي)، `'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 قد تم معالجته بالفعل أم أنها تحتاج إلى معالجة إضافية في مرحلة ما قبل الطباعة. يتم إخراجها كـ /Name في ملف PDF (وليس كسلسلة نصية) وفقًا لـ ISO 32000-1 §14.11.6.1؛ على سبيل المثال: `<< /Trapped /False >>`.
  • تم الآن تحديد بيانات التعريف XMP، حيث يعلن الحزمة عن `xmlns:pdfx="http://ns.adobe.com/pdfx/1.3/"` مع تعيين `` إلى السلسلة الدقيقة المحددة في المواصفات (`PDF/X-1:2001` أو `PDF/X-3:2002` أو `PDF/X-4`)، ومع تعيين `` إلى اسم الملف الشخصي الكامل (إما `PDF/X-1a:2001` أو `PDF/X-4:2010`) (بالنسبة لـ X-1a + X-4). تتعرف برامج Adobe Acrobat pre-flight و 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 بإنشاء ثلاثة ملفات PDF (واحد لكل ملف تعريف) ويتحقق من مساحة اسم 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 (ملف PDF يحتوي فقط على طابع زمني مستقل وفقًا لمعيار ETSI.RFC3161) الذي كان مخططًا في الأصل، أصبح الآن ضمنيًا - حيث أن `AddDocumentTimestampSignature` من الإصدار v2.111 يعمل على مستند جديد بدون توقيع داخلي - وبالتالي، تعتبر سلسلة PAdES مكتملة بـ 3 عمليات تثبيت، وسيتم تخصيص الإصدار v2.112 لـ PDF/X. تم دعم جميع ملفات تعريف الأساس ETSI EN 319 142-1.

2026-05-19 Version 2.111.0

  • سلسلة منتجات PAdES، الجزء الثالث/الرابع: دعم توقيع الطابع الزمني للمستندات وفقًا لمعيار ISO 32000-1 §12.8.5 بالإضافة إلى ETSI EN 319 142-1 §5.7. الطابع الزمني للمستند هو توقيع ثانٍ يتم تطبيقه بعد اكتمال توقيع التحقق طويل الأجل؛ وهو يغطي ملف حالة التحقق طويل الأجل بأكمله (التوقيع الأصلي + DSS) ويثبت وجود المواد الخاصة بالتحقق طويل الأجل في وقت موثق. هذا هو ملف الأرشفة المطلوب للاحتفاظ بالبيانات المنظمة في الاتحاد الأوروبي، والذي يتجاوز عمر شهادة CA الأصلية.
  • تمت إضافة وظيفة مساعدة جديدة `THPDFPage.AddDocumentTimestampSignature(FieldName, ContentsBytes)`. على عكس التوقيع القياسي PAdES، فإن ختم المستند الزمني يحتوي على:
    • `SubFilter` بقيمة `/ETSI.RFC3161` (رمز زمني RFC 3161، وليس CAdES).
    • مستطيل عنصر تحكم مساحة صفرية (لا يحتوي الختم الزمني على أي مظهر مرئي - إنه بيانات وصفية تشفيرية بحتة).
    • لا يوجد `/Reason` أو `/Location` أو `/ContactName` (هذه موجودة في سمات التوقيع TST، وليست في قاموس التوقيع).
    • حجم افتراضي لبيانات `/Contents` يبلغ 16 كيلوبايت (يمكن للمتصل تمرير قيمة أصغر تصل إلى حد أدنى يبلغ 1 كيلوبايت؛ عادةً ما يكون رمز TST RFC 3161 الكامل مع سلسلة الشهادات 4-8 كيلوبايت).
  • تنتهي نطاقات الإنتاج عند تنسيق الملف: يقوم البرنامج المساعد بإنشاء القاموس الوهمي `/Type /Sig` مع عامل التصفية الفرعي الخاص بالوقت والطابع الزمني، بالإضافة إلى علامة `/ByteRange` و `/Contents` لإجراء تصحيحات لاحقة من خلال `PreparePDFForSigning` و `InsertSignatureHex`. يحصل المُستدعي على بايتات TST الفعلية وفقًا لمعيار RFC 3161 من سلطة الطوابع الزمنية الموثوقة (TSA، مثل DigiCert / GlobalSign / FreeTSA عبر HTTP POST) ويقوم بإدخالها. تتضمن سير عمل الأرشفة PAdES-B-LTA النموذجية ما يلي: 1) إصدار التوقيع الأساسي PAdES-B-LT (الإصدار v2.109)، 2) ملء `Catalog /DSS` بسلسلة الشهادات و OCSP/CRL (الإصدار v2.110)، 3) الحفظ كتحديث تدريجي، 4) إضافة حقل الطابع الزمني للمستند فوق بايتات حالة LT (الإصدار v2.111)، 5) طلب TST من TSA عبر نطاق البايت، 6) إدخال بايتات TST.
  • تمت عملية تجميع نظيفة لنظامي التشغيل Win32 و Win64؛ وتمت إعادة تجميع جميع الإصدارات الأساسية v2.108 و v2.109 و v2.110 دون أي تغيير. ينتج الإصدار الجديد `smoke_pades_doctimestamp` حقل `SigInner` من نوع PAdES-B-LT بالإضافة إلى حقل `DocTS` للختم الزمني للمستند، وذلك باستخدام الوحدة المساعدة الجديدة. يتحقق مدقق Python من أن التوقيع الداخلي يحتوي على `/SubFilter /ETSI.CAdES.detached`، وأن منطقة المستطيل الخاص بالختم الزمني هي صفر، وأن القاموس `/V` الخاص بالختم الزمني يحتوي على `/SubFilter /ETSI.RFC3161` ولا يحتوي على `/Reason` أو `/Location` أو `/ContactName`، وأن `/Contents` عبارة عن عنصر نائب بحجم 16 كيلوبايت (32768 حرفًا سداسيًا عشريًا).
  • تتيح إضافة "شريحة PAdES" المتبقية، بالإصدار v2.112 (اختياري)، إنشاء ملفات PDF مستقلة تحتوي فقط على ختم زمني وفقًا لمعيار ETSI.RFC3161 (بدون توقيع CAdES داخلي - مجرد حاوية لمستند ختم زمني).

2026-05-19 Version 2.110.0

  • تحديث سلسلة PAdES، الجزء 2/4: دعم قاموس Document Security Store (DSS) وفقًا لمعيار ISO 32000-2 §12.8.4.3 بالإضافة إلى ETSI EN 319 142-1 §5.6. تتطلب إصدارات PAdES-B-LT (و B-LTA) تضمين معلومات متعلقة بالتحقق - سلسلة الشهادات، واستجابات OCSP، وقوائم الإبطال (CRLs) - داخل ملف PDF نفسه، بحيث يمكن التحقق من التوقيعات لفترة طويلة بعد وقت التوقيع الأصلي دون الحاجة إلى الاتصال بخوادم PKI خارجية.
  • تمت إضافة أدوات مساعدة جديدة إلى THotPDF:
    • `EnsurePAdESDSS` — تقوم بإنشاء قاموس غير مباشر للكتالوج /DSS مع مصفوفات /Certs و /OCSPs و /CRLs وقاموس فرعي فارغ /VRI؛ تُرجع المكالمات اللاحقة القاموس الموجود.
    • `AddPAdESDSSCertificate(CertDERBytes)` — تضيف شهادة X.509 مشفرة بتنسيق DER كتدفق غير مباشر إلى /DSS /Certs؛ تُرجع كائن التدفق غير المباشر لاستخدامه في مراجع VRI.
    • `AddPAdESDSSOCSP(OCSPDERBytes)` — نفس الأمر لـ OCSP BasicOCSPResponse إلى /DSS /OCSPs.
    • `AddPAdESDSSCRL(CRLDERBytes)` — نفس الأمر لقائمة إبطال الشهادات إلى /DSS /CRLs.
    • `AddPAdESDSSVRI(SigContentsHexSHA1, Certs, OCSPs, CRLs)` — تقوم بإنشاء إدخال VRI لكل توقيع، مع مفتاح هو SHA-1 السداسي عشري الكبير لـ /Contents (الشكل المحدد في المواصفات)؛ يحتوي كل إدخال على مصفوفات /Cert و /OCSP و /CRL تشير إلى التدفقات غير المباشرة التي تم إنشاؤها أعلاه.
  • تنتهي نطاق الإنشاء عند تنسيق الملف. لا يزال البرنامج الذي يستدعي يقوم بحساب قيمة SHA-1 للمحتوى النهائي الموقّع، ويقوم بتزويد الشهادات المشفرة بتنسيق DER، واستجابات OCSP، وقوائم سحب الشهادات (CRLs) من أدوات PKI الخاصة به. سير العمل النموذجي: يتم إنشاء التوقيع الأساسي PAdES-B-T (الإصدار v2.109)، ثم تتم إضافة الشهادات واستجابات OCSP وقوائم سحب الشهادات إلى DSS للتحقق طويل الأمد، ثم يتم إرفاق إدخالات VRI لربط معلومات التحقق بتوقيعات معينة.
  • تمت عملية تجميع نظيفة لنظامي التشغيل Win32 و Win64؛ وتم إعادة تجميع جميع الإصدارات الأساسية v2.108 و v2.109 دون تغيير. يقوم الاختبار الجديد smoke_pades_dss بإنشاء حقل توقيع PAdES-B-LT، ويضيف 2 شهادات و 1 OCSP و 1 CRL إلى DSS، ويضيف إدخال VRI مع تجزئة سداسية عشرية اختبارية. يتحقق المدقق Python من هيكل قاموس DSS: مرجع إلى /DSS في الكتالوج، ومصفوفات /Certs و /OCSPs و /CRLs، ويتحقق من عدد العناصر في المصفوفات، ويتأكد من تطابق مفتاح VRI، ويتأكد من تطابق مراجع الشهادات/OCSP/CRL في إدخال VRI مع المصفوفات DSS على مستوى أعلى.
  • تبقى شرائح PAdES: الإصدار v2.111 يطبق توقيع الطابع الزمني لمستند PAdES-B-LTA (حقل توقيع ثانٍ مع 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) والتي تقوم بتحديد ثابتًا لـ SubFilter المطلوب لـ PAdES وتتحقق من توافق الملف. تم أرشفة التدقيق الكامل وخطة الطريق المكونة من 4 إصدارات في .superpowers/specs/2026-05-19-pades-compliance-audit.md.
  • تمت إضافة وظيفة مساعدة جديدة `THPDFPage.AddPAdESSignatureField(FieldName, Rect, Profile, Reason, Location, ContactName, ContentsBytes, Flags)`. تتيح هذه الوظيفة تحديد مستوى الأساس القياسي ETSI EN 319 142-1: 'B-B' (توقيع CAdES أساسي، بدون طابع زمني)، 'B-T' (مع طابع زمني موثوق وفقًا لـ RFC 3161، وهو الحد الأدنى للاستخدام القانوني في الاتحاد الأوروبي)، 'B-LT' (مع معلومات التحقق من DSS للتحقق طويل الأجل)، أو 'B-LTA' (مع توقيع طابع زمني للمستند للأرشفة). تستخدم جميع الخيارات الأربعة مرشحًا فرعيًا 'ETSI.CAdES.detached'، ويختلف معلمة الملف الشخصي في التشخيص والميزانية الافتراضية لبايتات /المحتوى. تثير سلاسل الملفات الشخصية الأخرى أخطاءً وفقًا لـ ETSI.
  • تمت زيادة حجم ميزانية المحتوى تلقائيًا: في الوضعين PAdES-B-B و B-T، القيمة الافتراضية هي 16 كيلوبايت (يمكن للمستخدم تحديد قيمة أقل؛ نحن نفرض حدًا أدنى يبلغ 64 بايت، وهو ما تم توريثه من الإصدار v2.108). في الوضع PAdES-B-LT، يتم زيادة الحجم تلقائيًا إلى 20 كيلوبايت كحد أدنى (يشمل ذلك بيانات سلسلة الشهادات و OCSP/CRL بالإضافة إلى CAdES). في الوضع PAdES-B-LTA، يتم زيادة الحجم تلقائيًا إلى 24 كيلوبايت كحد أدنى (يشمل ذلك B-LT بالإضافة إلى ختم الوقت الخاص بالمستند). القيم الأكبر التي يوفرها المستخدم تمر دون تغيير؛ تقوم الوحدة المساعدة فقط بفرض الحد الأدنى.
  • نطاق المُنتج: يقوم المكون الإضافي بإنشاء القاموس الوهمي `/Type /Sig` مع `/SubFilter /ETSI.CAdES.detached`، و `/Reason`، و `/Location`، و `/ContactName`، و `/M` (تاريخ التوقيع)، بالإضافة إلى المحددات `/ByteRange` و `/Contents` لإجراء تصحيحات لاحقة من خلال `PreparePDFForSigning` و `InsertSignatureHex`. تظل مسؤولية استرجاع بايتات CMS/CAdES الفعلية، واسترداد الطابع الزمني RFC 3161، وجمع OCSP/CRL، وإنشاء قاموس DSS على عاتق المُستدعي - وهذا يتطلب مكتبة تشفير خارجية (مثل OpenSSL أو Bouncy Castle أو Windows CAPI) خارج نطاق مُنتج PDF.
  • تمت عملية تجميع نظيفة لنظامي التشغيل Win32 و Win64. يقوم البرنامج الجديد `smoke_pades_signature` بإصدار أربعة حقول توقيع PAdES (B-B / B-T / B-LT / B-LTA) ويؤكد أنه عند وجود قيم غير صالحة في الملف الشخصي، يتم إطلاق تنبيه. يتحقق برنامج التحقق الخاص بـ Python من أن قيمة `AcroForm /SigFlags` هي 3، وأن كل عنصر تحكم يحتوي على `/FT /Sig` ومرجع غير مباشر إلى قاموس `/Type /Sig` يحتوي على `/SubFilter /ETSI.CAdES.detached`، وأن طول العنصر النائب السداسي عشري لـ `/Contents` يطابق حجم البايت المتوقع (الذي يتم تحديده تلقائيًا).
  • تتضمن التحديثات المستقبلية لـ PAdES ما يلي: في الإصدار v2.110، تمت إضافة مُنشئ القاموس "Catalog /DSS" (مخزن بيانات الأمان للمستند) لبيانات التحقق من PAdES-B-LT (سلسلة الشهادات + OCSP/CRL). في الإصدار v2.111، تمت إضافة حقل التوقيع الخاص بختم الوقت للمستندات المستقلة لغرض الأرشفة PAdES-B-LTA. في الإصدار v2.112 (اختياري)، تمت إضافة ملفات PDF الخاصة بختم الوقت فقط وفقًا لمعيار ETSI.RFC3161.

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 المختلطة وتسجله في مصفوفة `/AF` في الكتالوج باستخدام دلالات `/AFRelationship` الواردة في القسم E.4.
  • تدفق حاويات هجين: الحالة الاستخدامية النموذجية هي الفواتير بتنسيق PDF/A-3 على غرار ZUGFeRD، حيث يتم عرض الفاتورة المقروءة للبشر في دفق صفحة PDF، بينما تضاف البيانات المصدرية XML القابلة للقراءة بواسطة الآلة كملف مرتبط. المفتاح `/AFRelationship` يوضح للمستخدمين كيفية ارتباط الملف المرفق بالمحتوى المرئي: 'Source' (البيانات المصدرية الأصلية)، 'Data' (البيانات الخام التي يعرضها ملف PDF)، 'Alternative' (تمثيل بديل)، 'Supplement' (مادة تكميلية)، 'Unspecified' (لا شيء من السابق).
  • تحديد معايير: يظهر خطأ في `AddPDFA3AssociatedFile` عند أي قيمة غير PDF/A-3 لـ `PDFACompliance` (الملحق E خاص بالجزء الثالث)، مع رسالة تشير إلى استخدام `AddFileAttachmentAnnotation` لـ PDF/A-2، مع الإشارة إلى أن PDF/A-1 §6.1.11 يحظر المرفقات تمامًا. يظهر خطأ إذا كان `FileName` أو `MimeType` فارغًا؛ ويظهر خطأ إذا كانت قيمة `Relationship` غير صالحة، مع الإشارة إلى التعداد المحدد في الملحق E.4.
  • تتضمن بنية الإخراج: تدفق الملف المضمن غير المباشر الذي يحمل `/Type /EmbeddedFile` بالإضافة إلى `/Subtype ` و `/Params <>`، بالإضافة إلى بايتات الملف. يحمل قاموس الملف المرجعي `/Type /Filespec` بالإضافة إلى `/F` و `/UF` (كلاهما = اسم الملف)، بالإضافة إلى `/Desc` الاختياري و `/EF <>` و `/AFRelationship` (مفتاح الملحق E). يتم إنشاء مصفوفة `/AF` في الكتالوج بشكل كسول في أول عملية إلحاق ويتم إلحاق عناصر إليها في عمليات الاستدعاء اللاحقة. يسمح القاموس `Filespec` المُرجع للمتصلين بإضافة مفاتيح اختيارية إضافية (مثل `/CI` لمعلومات/مجموع التحقق) عند الحاجة.
  • تمت عملية تجميع نظيفة لنظامي التشغيل Win32 و Win64. تم إنشاء إصدار تجريبي جديد باسم `smoke_pdfa3_associated` يقوم بإنشاء فاتورة هجينة بتنسيق PDF/A-3B مع إرفاق فاتورة XML حقيقية كمصدر لـ `/AFRelationship`. ثم يتم اختبار ثلاثة مسارات للرفض: يتم رفض ملفات بتنسيق PDF/A-1، ويتم رفض ملفات بتنسيق PDF/A-2، ويتم رفض قيم غير صالحة لـ `/AFRelationship`. يتحقق برنامج التحقق المكتوب بلغة Python من هيكل القاموس `Filespec / EmbeddedFile` (النوع: `/F`، `/UF`، الوصف: `/Desc`، `/AFRelationship`، `/EF`، `/UF`، `/EmbeddedFile`، النوع: `/Subtype`، #2F escape، المعلمات: `Size`).
  • تم الآن إغلاق واجهة الإنتاج الخاصة بـ PDF/A-2 + PDF/A-3 بشكل كامل (مع خيار التفعيل v2.105 بالإضافة إلى XMP، وتغطية حظر التعليقات والإجراءات في v2.106، وقيود التنفيذ وفقًا للفقرة 6.1.13 في v2.107، وملحقات الملفات المرتبطة في v2.108). نظرًا لأن HotPDF تغطي بالفعل الامتثال الصارم لمعايير PDF/A-1 (v2.101-104) و PDF/UA-1 (v2.94-v2.100)، فإنها الآن تغطي كامل نطاق معايير PDF/A-1/2/3 + PDF/UA-1 من حيث الأرشفة وإمكانية الوصول.

2026-05-19 Version 2.107.0

  • تطبيق قيود حدود التنفيذ لسلسلة الإنتاج PDF/A-2 + PDF/A-3، وفقًا للبند 6.1.13 من المعيارين ISO 19005-2 و ISO 19005-3. تعتبر متطلبات البند 6.1.13 في PDF/A-1 أقل صرامة (لا يوجد حد أقصى صارم لطول السلسلة النصية)، لذا فإن هذا التحقق الجديد يعمل فقط عندما يكون مستوى التوافق مع PDF/A هو 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 لا تتجاوز هذه الحدود أبدًا لأنها مرتبطة بهياكل البيانات التي يتحكم بها المنتج. يركز المدقق على السلاسل التي يوفرها المتصل وحدود الصفحة لأنها الحدود الوحيدة التي يمكن للمتصل الفعلي تجاوزها.
  • نماذج XFA (المادة 6.4.2): لا تقوم HotPDF بإخراج عناصر AcroForm /XFA أو Catalog /NeedsRendering. يتم استيفاء كلا العنصرين تلقائيًا في معايير PDF/A-1/2/3 - وقد تم توثيق ذلك في تقرير التدقيق لمنع أي امتدادات مستقبلية من إعادة إدخال هذه العناصر.
  • تمت معالجة الرمز المستخدم عندما لا يوجد له مقابل (§6.2.11.8 في PDF/A-2): يمنع المواصف القياسي استخدام عوامل عرض النص التي تشير إلى الرمز المستخدم. تتجنب THotPDF هذه المشكلة عند استخدام خطوط Unicode TTF المسجلة (الإصدارات من v2.74 إلى v2.86) لأن البرنامج يقوم بربط كل نقطة رمز برمز حقيقي أو يرفض التسجيل. يتحمل المستخدم مسؤولية مسارات إخراج النص الخام؛ ويتم توثيق ذلك في تقرير التدقيق.
  • تغييرات مهمة: تمنع المواصفات استخدام سمات "bytes" أو "encoding" في رأس حزمة XMP (§6.6.2). تقوم الدالة `BuildXMPPacket` بإخراج رأس بسيط (مع المعرف "W5M0MpCehiHzreSzNTczkc9d") بدون أي من هاتين السمتين، وهو ما يفي بالمتطلبات في جميع أجزاء PDF/A.
  • تمت عملية تجميع نظيفة لنظامي التشغيل Win32 و Win64. تم إضافة اختبارات جديدة لمجموعة "smoke" لاختبار حدود PDF/A-2: الاختبارات التي تتحقق من أن PDF/A-2 ضمن الحدود المحددة تنجح؛ والاختبار الذي يتحقق من أن PDF/A-1 مع عنوان بحجم 32768 بايت ينجح أيضًا (دون تجاوز الشرط §6.1.13)؛ والاختبار الذي يتحقق من أن PDF/A-2 مع عنوان بحجم 32768 بايت يتم رفضه مع رسالة تشخيصية وفقًا للمواصفات. تم إعادة تجميع جميع خطوط الأساس السابقة لـ PDF/A-2/3 دون أي تغيير.
  • الجزء المتبقي من شريحة مُنتج PDF/A-2/3: الإصدار v2.108 يطبق PDF/A-3 الملحق E للملفات المرتبطة (خاصية الحاوية الهجينة الخاصة بـ PDF/A-3: مصفوفة /AF في كتالوج الملفات مع مفتاح /AFRelationship بالإضافة إلى EmbeddedFile /Params /CheckSum + /ModDate).

2026-05-19 Version 2.106.0

  • تغطية إصدارات PDF/A-2 + PDF/A-3، بما في ذلك الفقرتان 6.3.1 و 6.5.1 (وهما متطابقتان في كل من PDF/A-2 و PDF/A-3). تم تفعيل قيود التعليقات والإجراءات في إصدار v2.104 بالفعل لأي حالة PDFACompliance غير فارغة، وبالتالي تستمر في العمل بنفس الطريقة في إصدارات PDF/A-2/3. تؤكد v2.106 هذا السلوك، وتحديث رسائل التشخيص للإشارة إلى الأقسام الموحدة من المواصفات لجميع أجزاء PDF/A، وتوثق الأنواع الفرعية المحظورة الإضافية التي يتوافق معها HotPDF بشكل طبيعي (ولا يوجد مسار إخراج عام لها).
  • مصفوفة الإجراءات المحظورة: يمنع معيار PDF/A-1 إجراءات 6 (تشغيل/صوت/فيلم/إعادة تعيين النموذج/استيراد البيانات/جافاسكريبت). يوسع معيارا PDF/A-2 و PDF/A-3 المجموعة المحظورة لتشمل 13 إجراءً بإضافة الإجراءات التالية: إخفاء/تعيين حالة OCG/العرض/التحويل/الانتقال إلى عرض ثلاثي الأبعاد بالإضافة إلى الأنواع الفرعية "تعيين الحالة" و "لا شيء". لا يزال الإجراء AddLaunchLink يثير خطأ؛ لا يحتوي THotPDF على أي إدخال عام يقوم بإصدار الإجراءات الـ 12 الأخرى، لذلك يتم استيفاؤها تلقائيًا.
  • مصفوفة أنواع التعليقات المحظورة: يحظر معيار PDF/A-1 استخدام المرفقات/الصوت/الفيديو. في معيار PDF/A-2 / PDF/A-3، تم تخفيف حظر المرفقات (تم التغيير في الإصدار v.105)، ولكن تمت إضافة الأبعاد الثلاثية/الشاشة إلى قائمة المحظورات. لا تزال الدالة AddSoundAnnotation و AddMovieAnnotation تسبب مشاكل في جميع أجزاء PDF/A؛ نظرًا لأن THotPDF لا يدعم إخراج الأبعاد الثلاثية/الشاشة، فإن هذه القيود يتم تجاوزها تلقائيًا.
  • تحديث لرسائل التشخيص: الآن، تشير جميع الوظائف الثلاث (AddSoundAnnotation، AddMovieAnnotation، AddLaunchLink) من الإصدار v2.104 إلى جميع الأقسام ذات الصلة في وثائق المواصفات في رسائل الخطأ الخاصة بها (على سبيل المثال، "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 يتحقق من عمل جميع الوظائف الثلاثة في جميع مستويات PDF/A-2/3 الستة (2B، 2U، 2A، 3B، 3U، 3A). كل استدعاء يتحقق من ظهور الاستثناء المتوقع مع تشخيص وفقًا للفقرتين §6.3.1 و §6.5.1. تم إعادة تجميع الاختبارات الأساسية السابقة لـ PDF/A-1 (smoke_pdfa1_compliance / smoke_pdfa1_forbidden / smoke_pdfa1_annot_action) واختبار smoke_pdfa2_compliance بالإصدار v2.105 دون أي تغيير.
  • تعديلات على معالجة ملفات PDF/A-2/3: الإصدار v2.107 يفرض حدود التنفيذ وفقًا للمواصفة ISO 19005-2 §6.1.13 (نطاقات البايت للأعداد الصحيحة/الأرقام الحقيقية/السلاسل النصية/الأسماء، وتداخل q/Q، وألوان DeviceN، و CID، وحدود الصفحة) بالإضافة إلى §6.4.2 لـ XFA و §6.2.11 للأنواع 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، وترقية تلقائية للإصدار الأساسي لملف PDF إلى 1.7، وتخفيف بعض القيود الصارمة الموجودة في الإصدارات v2.101-v2.104 والتي تسمح بها مواصفات PDF/A-2 و PDF/A-3.
  • تمت إضافة ست قيم جديدة إلى الخاصية PDFACompliance، بالإضافة إلى القيم الموجودة ' / 'A' / 'B': '2A' / '2B' / '2U' (مستويات PDF/A-2 A / B / U) و '3A' / '3B' / '3U' (مستويات PDF/A-3 A / B / U). يمثل المستوى U المستوى الجديد "الحفاظ على Unicode فقط" الذي تم تقديمه في PDF/A-2 (نص مرئي وقابل للاستخراج باستخدام Unicode، بدون شرط 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'). تسمح مواصفات PDF/A-2 و PDF/A-3 §6.4 بشكل صريح بالشفافية (مع متطلبات منفصلة مثل وجود `OutputIntent` واستخدام أوضاع المزج المسماة الكاملة في PDF 1.4)، لذلك تسمح قيم `PDFACompliance` '2*' و '3*' بمرور الاستدعاء.
  • تم تخفيف قيود ميزة "FileAttachment" في الإصدار v2.104: الآن، لا تظهر أخطاء في `AddFileAttachmentAnnotation` إلا في حالة استخدام معيار PDF/A-1 الصارم. يمنع معيار PDF/A-2 §6.3.1 فقط أنواع التعليقات التوضيحية ثلاثية الأبعاد/الصوت/الشاشة/الفيلم؛ بينما يُسمح باستخدام "FileAttachment" وهو أساس سير العمل الهجين المرتبط بالملفات في الملحق E من معيار PDF/A-3. لا تزال القيود الأخرى المتعلقة بالتعليقات التوضيحية والإجراءات (تعليقات صوتية ومرئية؛ إجراء "Launch") في الإصدار v2.104 تعمل في جميع أجزاء معيار PDF/A وفقًا للقيود المشتركة في §6.3.1 و §6.5.1.
  • أضيفت طرق مساعدة جديدة في THotPDF باسم PDFAPart و PDFAConformanceLevel و IsPDFA1Strict و IsPDFA2OrLater لجعل تحديد القيم أكثر سهولة. تستخدم الآن الإصدارات السابقة من PDF/A (v2.101-104) هذه الأدوات المساعدة لتحسين بنية التعليمات البرمجية وتوفير رسائل خطأ أوضح تقترح التبديل إلى PDF/A-2 أو PDF/A-3 عند الحاجة.
  • تمت عملية تجميع نظيفة لنظامي التشغيل Win32 و Win64؛ تم إعادة تجميع جميع الاختبارات الأساسية v2.101-104 (smoke_pdfa1_compliance / smoke_pdfa1_forbidden / smoke_pdfa1_annot_action) دون أي تغيير. الاختبار الجديد smoke_pdfa2_compliance ينتج أربعة ملفات PDF (مستويات 2B / 2U / 2A / 3U)، ويختبر تخفيف الشفافية v2.103، وتخفيف إرفاق الملفات v2.104، بالإضافة إلى مسارين للتحقق (تم رفض مستوى '4Q' غير صالح؛ لا يزال بوابة الشفافية PDF/A-1 تعمل). يتحقق مدقق Python من تطابق XMP pdfaid:part مع كل مستوى، ويؤكد أن المستوى 2A لديه وراثة لملف PDF موسوم.
  • تحديثات إضافية لشرائح مُنتج PDF/A-2/3: الإصدار v2.106 يوسع مجموعة الإجراءات المحظورة من 6 إلى 13 (تمت إضافة Hide و SetOCGState و Rendition و Trans و GoTo3DView؛ تم إهمال تعيين الحالة / لا شيء) بالإضافة إلى تعديل القيود على أنواع التعليقات التوضيحية (تمت إضافة 3D و Screen، وتمت إزالة FileAttachment). الإصدار 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 التي تحظر أنواع التعليقات غير المسموح بها (FileAttachment، Sound، Movie) و 6.6.1 لنوع إجراء الإطلاق). مع الإصدار v2.104، تم إصلاح جميع الـ 17 مشكلة من جانب المُنتج والتي تم تحديدها في تدقيق PDF/A-1 بتاريخ 2026-05-19 (راجع الملف: .superpowers/specs/2026-05-19-pdfa1-compliance-audit.md): وهي تشمل المشكلات الرئيسية الأربعة (التعريف في القسم 5/6.7.11، الحظر المفروض على التشفير في القسم 6.1.3، OutputIntent في القسم 6.2.2، الشفافية في القسم 6.4) بالإضافة إلى مجموعة من الميزات المحظورة الأخرى.
  • §6.5.2 أنواع التعليقات المحظورة: الآن، عند استخدام PDFACompliance، تظهر الأخطاء بوضوح مع الإشارة إلى القسم المحدد في المواصفات لكل من `AddFileAttachmentAnnotation` و `AddSoundAnnotation` و `AddMovieAnnotation`. وفقًا للمواصفات، "يجب عدم السماح بأنواع FileAttachment و Sound و Movie" لتجنب الاعتماد على المحتوى الخارجي واستخدام الوسائط المتعددة في الملفات الأرشيفية.
  • §6.6.1 إجراء التشغيل: الآن، تقوم الدالة `AddLaunchLink` بإظهار تحذير ضمن `PDFACompliance` مع اسم تشخيصي يحدد الهدف من التشغيل. وفقًا للمواصفة، "لا يجوز السماح بإجراءات التشغيل والصوت والفيديو وإعادة تعيين النموذج واستيراد البيانات وجافاسكريبت." الأنواع الخمسة الأخرى من الإجراءات المحظورة (الصوت/الفيديو/إعادة تعيين النموذج/استيراد البيانات/جافاسكريبت) ليس لها نقطة دخول عامة في `HotPDF` تقوم بإصدارها، وبالتالي يتم تلبيتها بشكل طبيعي دون الحاجة إلى قيود صريحة.
  • تم الآن دمج ميزتي PDFUACompliance و PDFACompliance ويعملان بشكل صحيح عبر جميع الشرائح الأربعة لـ PDF/A. تعمل هاتان الميزتان بشكل متكامل: يرث المستوى A ميزة PDFUACompliance تلقائيًا لإنشاء ملف PDF مُعنون، وتطبق كلتا الميزتين آليات الحماية الخاصة بها (تتعلق بالـ Suspects/Tabs/Lang لـ PDF/UA؛ والتشفير/الشفافية/التعليقات/الإجراءات لـ PDF/A) دون أي تداخل.
  • ملخص إغلاق التدقيق: تم الآن إغلاق جميع متطلبات تنسيق الملف §6 الخاصة بـ PDF/A-1 التي يمكن لـ HotPDF تلبيتها هيكليًا. المسؤوليات المتبقية للمستخدم (§6.1.5 معادلة Info-XMP، §6.2.3.3 مطابقة مساحة الألوان مع OutputIntent، §6.3 تفاصيل الخطوط حيث تم التعامل مع معظمها بالفعل في عمل PDF/UA الخاص بالإصدار v2.74-v2.86) تتوافق مع المسؤوليات المماثلة للمستخدم في PDF/UA-1.
  • تمت عملية تجميع نظيفة لنظامي التشغيل Win32 و Win64؛ وتمت إعادة تجميع v2.103 لـ smoke_pdfa1_forbidden بنجاح. يختبر الاختبار الجديد smoke smoke_pdfa1_annot_action جميع المسارات الأربعة المحددة (AddFileAttachmentAnnotation، AddSoundAnnotation، AddMovieAnnotation، AddLaunchLink) ضمن PDFACompliance، ويؤكد أن كل استدعاء يؤدي إلى ظهور رسالة خطأ وفقًا للفقرتين §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، الجزء 3/4: تم إصلاح القسم §6.4 المتعلق بالشفافية (فجوة حرجة رقم 15) بالإضافة إلى القسم §6.2.8 المتعلق بدالة التحويل /TR (فجوة رقم 14). تم استيفاء قسمين من القسم 6 المتعلقين بمسارات إنتاج HotPDF الحالية تلقائيًا دون الحاجة إلى تغييرات في التعليمات البرمجية: القسم §6.1.10 المتعلق بمرشح LZW (يقوم HotPDF بإخراج FlateDecode فقط في مسار الكتابة الخاص به) والقسم §6.2.4 المتعلق بالصور و/Interpolate (لا يقوم HotPDF بإخراج /Interpolate أبدًا). تم توثيق هذه التغييرات الآن على أنها تلقائية في تقرير التدقيق.
  • §6.4 الشفافية تمنع قيم ألفا غير 1.0 وأنماط المزج غير "Normal" أو "Compatible". الآن، تقوم وظيفة `RegisterExtGState` بالتحقق من توافق PDF/A: إذا كانت قيمة ألفا للملء أقل من 1، فسيتم إرجاع خطأ (يتطلب PDF/A-1 أن يكون `/ca = 1.0`)؛ وبالمثل، إذا كانت قيمة ألفا للخط أقل من 1، فسيتم إرجاع خطأ (يتطلب PDF/A-1 أن يكون `/CA = 1.0`)؛ وإذا كان نمط المزج مختلفًا عن `Normal` أو `Compatible`، فسيتم إرجاع خطأ. تعرض جميع عمليات التحقق الثلاثة قسم المواصفة والقيمة المخالفة. تظل حالة ExtGState الافتراضية (بدون مفاتيح ألفا، وبدون نمط مزج) والقيم المسموح بها بشكل صريح (قيم ألفا 1.0، ونمط مزج Normal/Compatible) دون تغيير.
  • §6.2.8 يحظر ExtGState مفتاح وظيفة النقل /TR (تم إهماله؛ يسمح PDF/A-1 فقط بـ /TR2 بقيمة /Default، وحتى ذلك من الأفضل تجنبه). الآن، تثير 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 جميع المسارات الثلاثة المقيدة (ca<1، CA<1، BM=Multiply، تسجيل /TR) بالإضافة إلى التحقق من أن المسارات المسموح بها (ca=1.0، CA=1.0، BM=Normal/Compatible، بدون ألفا) لا تزال تعمل بشكل صحيح. لا يوجد مدقق - الاختبار نفسه يتحقق من خلال try/except أن كل استدعاء مقيد يثير استثناء.
  • الجزء المتبقي من وحدة إنشاء PDF/A-1: الإصدار v2.104 يغلق أنواع التعليقات المحظورة (FileAttachment, Sound, Movie) وفقًا للفقرة §6.5.2، بالإضافة إلى قواعد التعليقات /F /AP وفقًا للفقرة §6.5.3، وأنواع الإجراءات المحظورة (Launch, Sound, Movie, ResetForm, ImportData, JavaScript) وفقًا للفقرة §6.6.1، وحقول النموذج /A /AA و /NeedAppearances وفقًا للفقرة §6.9. بعد تطبيق الإصدار 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)` والتي تجمع استدعاءين: `RegisterICCProfile` و `AddOutputIntent('GTS_PDFA1', ...)` في استدعاء واحد. يتطلب معيار PDF/A-1 الصارم وجود إدخال من النوع `/Type /OutputIntent /S /GTS_PDFA1` مع دفق ICC صالح لـ `/DestOutputProfile`؛ وبدون ذلك، لا يمكن للملفات المتوافقة إعادة إنتاج الألوان بدقة عبر الأنظمة الأساسية المختلفة.
  • أضافت بوابة `PDFACompliance` فحصًا جديدًا باسم `EnsurePDFAOutputIntent`: يقوم هذا الفحص بفحص قائمة `OutputIntent` المسجلة، ويبحث عن وجود عنصر واحد على الأقل يحتوي على `/S /GTS_PDFA1` و `/DestOutputProfile`. في حالة عدم وجود مثل هذا العنصر، يتم عرض رسالة خطأ توضح القسم المحدد في المواصفة وترشد المستخدمين إلى وظيفة `AddPDFAOutputIntent`. وفقًا للقسم §6.2.2 بالإضافة إلى الملحق أ.
  • تتضمن سير العمل الأرشيفية النموذجية: تمرير دفق ملف تعريف ICC sRGB IEC61966-2.1 لملفات PDF/A الموجهة للشاشة، أو FOGRA39 / GRACoL للطباعة، أو ملف تعريف CMYK المسجل المناسب للتحضير للطباعة. يجب أن تكون قيمة NumComponents إما 1 (رمادي)، أو 3 (RGB / Lab)، أو 4 (CMYK) وفقًا للجدول 66 في القسم 8.6.5.5 من مواصفات PDF 1.7؛ تقوم الوحدة المساعدة بإجراء التحقق وتمريره إلى RegisterICCProfile.
  • يقوم المساعد بالتحقق من الصحة: إذا كان `OutputConditionIdentifier` فارغًا، فسيتم إرجاع خطأ (المتطلب في القسم 6.2.2 هو وجود المعرف); إذا كان `ICCProfileStream` فارغًا، فسيتم إرجاع خطأ (حيث أن `DestOutputProfile` إلزامي). لا تُرجع هذه العملية أي قيمة، حيث يتم تسجيل `OutputIntent` تلقائيًا في `FOutputIntents` وعرضه من خلال مسار التسلسل الحالي للكتالوج `/OutputIntents`.
  • تمت عملية تجميع نظيفة لنظامي التشغيل Win32 و Win64. تم تحديث `v2.101 smoke_pdfa1_compliance` لاستدعاء `AddPDFAOutputIntent` (باستخدام بديل ICC وهمي بحجم 192 بايت؛ يجب على المستخدمين الحقيقيين توفير ملف ICC حقيقي). يضمن اختبار التحقق الجديد الرابع أنه في حالة عدم وجود `OutputIntent` ضمن `PDFACompliance`، يتم إظهار تنبيه وفقًا للقسم 6.2.2. تم توسيع أداة التحقق الخاصة بـ Python للتحقق من مصفوفة `Catalog /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: الحفاظ على المظهر المرئي فقط). في حالة استخدام قيم غير صالحة، سيتم إظهار خطأ في نهاية المستند. يرجى الرجوع إلى معايير التوافق ISO 19005-1:2005 §5.
  • يؤدي تعيين `PDFACompliance` إلى القيمة 'A' تلقائيًا إلى تفعيل `PDFUACompliance` (يورث المستوى A متطلبات PDF المميّز من القسم 6.8، والتي تتوافق مع متطلبات الهيكل المنطقي للقسم 7 في PDF/UA-1). يمكن الجمع بين كلا الميزتين دون تعارض؛ حيث يضيف طبقة `PDF/UA-1` الخاصة باللغة والعنوان والمشتبه بهم (v2.94) إلى طبقة الحماية `PDF/A` (v2.101).
  • يؤدي تعيين أي من المستويين تلقائيًا إلى تفعيل FEnableXMPMetadata، مما يضمن أن المستند يحتوي على دفق 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 وجود dc:title في مكافئ XMP، وهو ما يعادل Info /Title). صرامة اللغة تعكس سلوك v2.94 لـ PDFUACompliance (§6.8.4 للمستوى A)، لذا يجب على المؤلفين اختيار علامة BCP-47 صحيحة بدلاً من الحصول على قيمة افتراضية "en" صامتة.
  • حماية من تعارض التشفير: وفقًا للفقرة 6.1.3، يجب ألا يحتوي الجزء الختامي للملف على العنصر "/Encrypt". الآن، عند تعيين خيارات "كلمة مرور المالك" أو "كلمة مرور المستخدم" أو "الحماية"، فإن الدالة `EnableEncrypt` (وهي الدالة الداخلية التي يتم استدعاؤها عند تعيين هذه الخيارات) تظهر رسالة خطأ واضحة إذا كان حقل `PDFACompliance` غير فارغ. تعرض الدالة `EndDoc` هذا التعارض بنفس الطريقة، بحيث يرى المستخدمون الفشل قبل عملية التسلسل.
  • لا تزال مسؤولية الطرف الذي يقوم بالاستدعاء تشمل: إصدار ملف PDF/A-1 OutputIntent صالح مع ملف ICC (تحديث v2.102)، وتجنب الشفافية (v2.103)، وتجنب أنواع التعليقات/الإجراءات المحظورة (v2.104)، وإنشاء هيكل شجري دلالي حقيقي للإصدار A (تم تغطيته بواسطة أدوات PDF ذات العلامات v2.96-v2.99).
  • تمت عملية تجميع نظيفة لنظامي التشغيل Win32 و Win64؛ وتمت إعادة تجميع اختبار v2.100 الأساسي smoke_pdfua_link_contents بنجاح. الاختبار الجديد smoke smoke_pdfa1_compliance ينتج ملفات PDF من النوع A و B، بالإضافة إلى اختبار ثلاثة مسارات للتحقق (مستوى 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

  • تم إصلاح الفجوة المتبقية في تغطية الارتباطات التوضيحية /Contents وفقًا للبند PDF/UA-1 §7.18.5، وذلك بناءً على التدقيق الذي تم في 2026-05-19. في الإصدار v2.95، تمت إضافة حقل الوصف إلى الدالة AddURILink. يوفر الإصدار v2.100 نفس دعم الوصف البديل لنقاط الإدخال الثلاثة المتبقية للارتباطات: AddGoToLink (للانتقال داخل المستند)، وAddGoToRLink (للانتقال بين الملفات)، وAddLaunchLink (لفتح ملف خارجي).
  • كل دالة مساعدة تكتسب الآن معلمة اختيارية نهائية `const Description: AnsiString = ''`. عندما لا تكون فارغة، يحتوي قاموس التعليقات التوضيحية على إدخال `/Contents (Description)`; وفي وضع `PDFUACompliance`، يؤدي وجود وصف فارغ إلى ظهور خطأ واضح يحدد الهدف المرتبط الذي تسبب في المشكلة، بحيث لا يمكن إخفاء الوصف البديل المفقود. القيمة الافتراضية الفارغة تحافظ على التوافق مع الإصدارات السابقة خارج وضع PDFUACompliance.
  • وفقًا للمواصفة PDF/UA-1 §7.18.5، يجب أن تحتوي الروابط على وصف بديل من خلال مفتاح "Contents" كما هو موضح في ISO 32000-1:2008، 14.9.3. تنطبق هذه المواصفة على جميع أنواع التعليقات التوضيحية للروابط، وليس فقط روابط URI - والآن، تجعل التوقيعات المساعدة ذلك موحدًا.
  • التدفق النموذجي: `Page.AddGoToLink(R, 1, 700, 'انتقل إلى الصفحة 2: المنهجية'); Page.AddGoToRLink(R, 'companion.pdf', 0, -1, false, 'افتح المستند المرفق للحصول على الجداول الكاملة'); Page.AddLaunchLink(R, 'readme.txt', false, 'افتح ملف README في محرر النصوص الافتراضي');`
  • تمت عملية تجميع نظيفة لنظامي التشغيل Win32 و Win64؛ وتمت إعادة تجميع ملف الأساس "smoke_pdfua_figure" بنجاح. يقوم الاختبار الجديد "smoke_pdfua_link_contents" بإنشاء مستند مكون من صفحتين مع ثلاثة تعليقات ارتباط في الصفحة 0 (انتقال إلى الصفحة 1، انتقال إلى "companion.pdf"، تشغيل "readme.txt")، بالإضافة إلى اختبار مسار الاستثناء "PDFUACompliance" الخاص بوصف فارغ لجميع التعليقات الثلاثة. يتحقق المدقق Python من أن كل تعليق ارتباط يحمل الخاصية "/Subtype /Link"، والإجراء المطابق "/S /GoTo" (أو "/GoToR" أو "/Launch")، وقيمة "/Contents" تتطابق مع الوصف المقدم.
  • ملخص تغطية الميزات الخاصة بـ PDF/UA-1: مع الإصدار v2.100، جميع نقاط الدخول الأربعة لتعريفات الارتباط الآن تستوفي الشرط §7.18.5. بالإضافة إلى ذلك، وبناءً على إغلاق التدقيق في الإصدار v2.94 (Suspects, Tabs, Lang)، والإصدار v2.95 (URI Contents, Bit 10, ID)، وسلسلة أدوات المساعدة الدلالية لـ Tagged PDF في الإصدارات v2.96-v2.99 (Heading, List, Table, Figure)، فإن واجهة إنتاج PDF/UA-1 الخاصة بـ HotPDF أصبحت الآن مغلقة بالكامل من حيث التدقيق، سواء على مستوى الطبقة الخارجية الصارمة وفقًا للمواصفات أو على مستوى واجهة برمجة التطبيقات (API) سهلة الاستخدام.

2026-05-19 Version 2.99.0

  • تمت إضافة `BeginTaggedFigure(Parent, AltText, BBox): FigureElem` و `EndTaggedFigure` كالجزء الرابع والأخير من سلسلة الأدوات المساعدة الدلالية لـ PDF/UA-1 §7.3 (الرسومات). تقوم الأقواس بتضمين عمليات الرسم التي يوفرها المستخدم (كائن صورة، مسار متجه، مستطيل مملوء) داخل عنصر هيكل "Figure" مع سمة التخطيط الإلزامية "/Alt" والسمة الاختيارية "/BBox".
  • `/Alt` إلزامي (لا يوجد بديل افتراضي فارغ). وفقًا لـ PDF/UA-1 §7.3، يجب أن تتضمن "علامات الشكل تمثيلًا بديلاً أو نصًا بديلاً يمثل المحتوى الذي تم تحديده بعلامة الشكل". يؤدي النص البديل الفارغ إلى ظهور خطأ مع رسالة تشخيص واضحة توجه المستخدمين إلى الدالة `AddStructureElement` ذات المعاملات الستة في الإصدار v2.88 إذا كان `/ActualText` (وليس `/Alt`) هو آلية النص البديل المناسبة.
  • يُعدّ مربع الإحاطة الاختياري (BBox) عبارة عن مصفوفة مكونة من 4 قيم [llx, lly, urx, ury] تصف مربع إحاطة الشكل في مساحة المستخدم الافتراضية، ويتم إرفاقه كـ /A << /O /Layout /BBox [...] >> وفقًا لـ ISO 32000-1 14.8.5.4.5 الخاص بمالك سمة التخطيط. لتخطي سمة مربع الإحاطة تمامًا، قم بتمرير مصفوفة فارغة. يؤدي مربع الإحاطة ذو الطول غير الصحيح (1/2/3/5 عناصر أو أكثر) إلى حدوث خطأ، مع استخدام المستطيل المحدد في المواصفات كمرجع للتخطيط.
  • تتضمن التدفق العملي النموذجي ما يلي: `Fig := Doc.BeginTaggedFigure(Root, 'شعار الشركة: سهم يشير إلى اليمين', [72, 600, 200, 720]); ... رسم محتويات الشكل ... Doc.EndTaggedFigure;`. يشارك الشكل في نفس هيكل MCID / ParentTree مثل مسارات `BeginTaggedContent` الأخرى في الإصدار v2.90، ولكن مع إرفاق سمات `/Alt` و `/BBox` تلقائيًا.
  • يغلق هذا التحديث القسم 7.3 الخاص بمسؤولية المستخدم في معيار PDF/UA-1، كما ورد في تقرير التدقيق. الآن، تغطي سلسلة الأدوات المساعدة الدلالية لـ "PDF/UA" جميع الأنواع الأربعة الرئيسية للهياكل: القسم 7.4 (العناوين، الإصدار 2.96)، القسم 7.6 (القوائم، الإصدار 2.97)، القسم 7.5 (الجداول، الإصدار 2.98)، والقسم 7.3 (الرسومات، الإصدار 2.99). بالإضافة إلى إصلاحات الطبقة التغليفية الموجودة في الإصدارين 2.94 و 2.95، أصبح منتج "HotPDF" لـ "PDF/UA-1" الآن متوافقًا تمامًا مع المواصفات على مستوى الواجهة، ويوفر أيضًا تجربة مستخدم مريحة على مستوى واجهة برمجة التطبيقات.
  • تمت عملية تجميع نظيفة لنظامي التشغيل Win32 و Win64؛ وتمت إعادة تجميع ملفات الاختبار الأساسية `smoke_pdfua_table` بنجاح. يقوم اختبار `smoke_pdfua_figure` الجديد بإخراج عنصرين من هيكل `Figure` (أحدهما يحتوي على `/Alt` و `/BBox`، والآخر يحتوي على `/Alt` فقط)، بالإضافة إلى اختبار مسارات الاستثناء الخاصة بالنص البديل الفارغ ومربع الإحاطة (`BBox`) غير الصحيح. يتحقق مدقق Python من كلا النوعين `/S` لعناصر `Figure`، ويتأكد من تطابق محتوى النص البديل (`/Alt`)، وأن قيم مصفوفة مربع الإحاطة (`BBox`) هي [72، 600، 200، 720].

2026-05-19 Version 2.98.0

  • تمت إضافة أربع أدوات مساعدة لجداول مُعلّمة وفقًا للمواصفة PDF/UA-1 §7.5 (الجداول) كجزء ثالث من سلسلة أدوات المساعدة الدلالية لملفات PDF المُعلّمة. `BeginTaggedTable(Parent): TableElem` تقوم بإنشاء حاوية هيكل الجدول؛ `AddTaggedTableRow(Table): TRElem` تضيف صفًا (TR)؛ `EmitTaggedTableHeader(TR, X, Y, Text, Scope): THElem` تُنشئ خلية رأس الجدول (TH) مع السمة الإلزامية "/Scope"؛ `EmitTaggedTableCell(TR, X, Y, Text): TDElem` تُنشئ خلية بيانات (TD). جميع الأنواع الخمسة من العلامات (الجدول، الصف، رأس الجدول، خلية البيانات، بالإضافة إلى كائن السمة) تتوافق مع المواصفات.
  • يجب أن يكون سمة "Scope" (المحددة في ISO 32000-1 14.8.5.7 الجدول 350) إلزامية في العنصر المساعد (ولا يوجد قيمة افتراضية)، والقيم المسموح بها هي `Row` أو `Col` أو `Both`. تؤدي سلاسل "Scope" غير الصالحة إلى ظهور خطأ وفقًا للمواصفات. وفقًا لـ PDF/UA-1 §7.5، "يجب أن تحتوي عناصر الهيكل من النوع TH على سمة Scope. إذا لم يكن من الممكن تحديد هيكل الجدول من خلال الرؤوس والمعرفات، فيجب أن تحتوي عناصر الهيكل من النوع 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`. تُرجع الدالة المساعدة عنصر `StructElem` الخاص بالخلية للمتصلين الذين يرغبون في إرفاق سمات إضافية (مثل قائمة `/Headers` للجداول المعقدة، و `/RowSpan`، و `/ColSpan`).
  • يحل محل الهيكل متعدد الخطوات v2.90 بالإضافة إلى تسلسل BDC/EMC لكل خلية.
  • يغلق هذا التحديث القسم 7.5 الخاص بمسؤولية المستخدم من معيار PDF/UA-1، كما ورد في تقرير التدقيق. الآن، تغطي سلسلة أدوات المساعدة الدلالية لملفات PDF ذات العلامات الأقسام 7.4 (العناوين، الإصدار 2.96)، و7.6 (القوائم، الإصدار 2.97)، و7.5 (الجداول، الإصدار 2.98). الجزء المتبقي (الإصدار 2.99 وما يليه): أداة مساعدة للرسوم البيانية للقسم 7.3، تتضمن /BBox و /Alt، بالإضافة إلى كتلة الرسم التي يوفرها المستخدم.
  • تمت عملية تجميع نظيفة لنظامي التشغيل Win32 و Win64؛ وتمت إعادة تجميع ملفات الاختبار الأساسية `smoke_pdfua_list` بنجاح. يقوم الاختبار الجديد `smoke_pdfua_table` بإنشاء جدول مكون من 3 صفوف (صف عنوان + صفين من البيانات) مع 3 خلايا `TH` (النطاق = العمود) و 6 خلايا `TD`، ويختبر الاستثناء الخاص بالنطاق غير الصالح. يتحقق مدقق Python من هيكل الجدول الكامل `Table > TR > TH/TD` مع وجود `/Scope /Col` في كل خلية `TH`.

2026-05-19 Version 2.97.0

  • تمت إضافة مساعدين جديدين لقوائم PDF/UA-1 §7.6 كجزء ثانٍ من سلسلة مساعدات البنية الدلالية لملفات PDF ذات العلامات: `BeginTaggedList(Parent, NumberingStyle): ListElem` يقوم بإنشاء عنصر هيكل L مع كائن سمة `/A` وصفه `<< /O /List /ListNumbering /