adobe-mappings-pdf

Overview

adobe-mappings-pdf is an Adobe-provided data package related to character encoding and font mapping information used in PDF documents. In practical terms, it supplies reference mapping data that PDF tooling can use when text in a PDF needs to be interpreted, converted, or rendered consistently. Adobe’s PDF reference documents describe the use of CMaps, ToUnicode mappings, and related encoding structures for mapping character codes to Unicode values and glyphs in PDF fonts. (opensource.adobe.com)

For a Linux distribution, this kind of package is usually shipped as shared reference data rather than as a standalone user-facing application. NiceOS packages it so PDF-related software can depend on a maintained copy of the upstream mapping material instead of bundling its own private copy. That helps keep packaging consistent across consumers, but maintainers should still verify how the package is used in the wider distribution before making packaging assumptions.

Purpose and typical use cases

Typical use cases include:

• providing character mapping data for PDF font handling and text extraction workflows;
• supporting document processing tools that need consistent Unicode interpretation of PDF text;
• serving as packaged reference data for libraries or utilities that work with PDF internals;
• reducing duplication by centralizing upstream mapping data in the distribution.

Typical users are:

• distribution maintainers who package PDF-related software;
• developers integrating PDF parsing, rendering, or text extraction components;
• build and CI/CD maintainers validating that packaged PDF tooling still works with the shipped mapping data;
• desktop users indirectly, through applications that consume PDF libraries.

Upstream project

The upstream for this package is Adobe. The publicly available Adobe documentation that is most relevant to this package describes PDF font encodings, CMaps, Unicode mappings, and the PDF reference model used by PDF software. (opensource.adobe.com)

For background reading, the Adobe Acrobat help pages also document PDF font handling and supported file conversion scenarios. Those pages are useful for understanding the broader PDF ecosystem around this data package, although NiceOS maintainers should verify the exact relationship between this package and any specific consumer package in the distribution. (helpx.adobe.com)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and related packaging logic.
• SOURCES/ — source manifests and integrity metadata used by the packaging workflow.
• METADATA/ — repository metadata used by the dist-git tooling.
• SBOM/ — software bill of materials material, if present for this package.

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository keeps the metadata needed to identify and verify the expected source content.

Source storage and integrity policy

NiceOS tracks source integrity through manifest files in SOURCES/. Those manifests are the authoritative record for the source objects that should be present during package builds.

Practical implications for maintainers:

• do not expect the full upstream archive to be committed to Git;
• confirm that the SOURCES/ manifests match the intended upstream source set;
• check that regenerated metadata still points to the correct upstream material;
• treat missing or stale manifest data as a packaging issue to fix before the build.

The repository should remain usable even when the upstream source changes in future updates, because the integrity model depends on manifests rather than on version-specific text in this README.

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check:

• whether the upstream mapping data has changed in a way that affects consumers;
• whether any packaging metadata in SPECS/ needs adjustment;
• whether the SOURCES/ manifests need regeneration or replacement;
• whether SBOM/ material should be updated to reflect the new source set;
• whether downstream consumers rely on file names, paths, or installation locations that may change;
• whether any license or attribution files need to be refreshed in the package metadata.

Risks and things to consider:

• PDF-related packages can be sensitive to data-format changes even when the update looks small;
• consumer packages may assume specific path layouts or file names, so verify those assumptions;
• if the upstream layout changes, update the spec and manifests together rather than separately;
• if the package is used by multiple PDF components, test all known consumers, not only one.

Build and verification checklist

Use this checklist for RPM maintenance and review:

1. Verify the upstream source to be packaged matches the manifests in SOURCES/.
2. Review SPECS/ for any required changes in file lists, install paths, or subpackage handling.
3. Confirm that generated metadata in SBOM/ is still accurate, if the repository uses it.
4. Run a clean build in the target NiceOS build environment.
5. Inspect the resulting RPM payload to confirm the expected mapping data is installed.
6. Check for unexpected file additions, removals, or path changes.
7. Validate that dependent PDF-related packages still build and run against the updated package.
8. Review license and attribution information for consistency with the packaged upstream material.
9. Ensure the repository does not accidentally contain upstream archive payloads that should remain outside Git.

References

• Adobe PDF Reference materials
• Adobe PDF Reference 1.5
• Adobe Acrobat PDF font documentation
• Adobe Acrobat help: supported file formats
• Adobe Acrobat help: PDF fonts overview

Russian documentation

See README_RU.md for the Russian version of this documentation.

Dist-git repository notes

• Package repository: rpms/adobe-mappings-pdf
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.