# PDF text-layer diagnostic files

These are original, deliberately constructed examples for “PDF Copy-Paste Gives Wrong Text? Diagnose the Text Layer First,” tested on 2026-09-10. They contain no customer files or third-party article text.

## Downloads and expected results

- [correct-digital-text.pdf](correct-digital-text.pdf): normal visible text; extraction matches the page.
- [wrong-unicode-map.pdf](wrong-unicode-map.pdf): the PDF's extraction mapping changes `8` to `3` and lowercase `a` to `x`; visible glyphs are unchanged.
- [wrong-ocr-text.pdf](wrong-ocr-text.pdf): a page image with deliberately incorrect invisible text. No OCR engine generated the errors.
- [image-only.pdf](image-only.pdf): the same page image with no text layer.
- [results.json](results.json): both extractors' raw text, PDF hashes, pixel hashes, environment and limitations.
- [text-layer-check.csv](text-layer-check.csv): a reader's worksheet for real documents, not an automated certification.
- [build-fixtures.py](build-fixtures.py): complete generator and assertions.

The `.txt` files beside each PDF contain the actual Poppler extraction. Both extractors' outputs are retained in `results.json`.

## Reproduce

Download `build-fixtures.py`, [NotoSans-Regular.ttf](fonts/NotoSans-Regular.ttf), and [OFL.txt](fonts/OFL.txt), keeping the latter two under a `fonts` subdirectory. The script creates or replaces generated PDFs, text files, `results.json`, and a `preview` subdirectory beside itself. Run it in a dedicated directory, not a folder containing other files with these names.

The observed environment was macOS, Python 3.12.14, ReportLab 4.4.9, pypdf 6.10.0, Pillow 12.3.0, and Poppler 26.08.0 (`pdftotext` and `pdftoppm` on PATH). Create a Python virtual environment, install these Python dependencies, and install the matching Poppler version separately if an exact rendering comparison is needed:

```sh
python3 -m venv .venv
.venv/bin/python -m pip install reportlab==4.4.9 pypdf==6.10.0 Pillow==12.3.0
.venv/bin/python build-fixtures.py
```

The script checks both extracted outputs against the intended text and compares two pairs of RGB renders at 144 dpi. It stops if an assertion fails. Different rendering versions may change pixel hashes. The claim is equality within each pair in the reported environment, not universal identity across viewers or all four PDFs.

The four visible lines are:

```text
A small reading-file experiment
The archive contains 18 notebooks.
Item B-204 arrived on 6 May.
Retain the original page as the reference.
```

## Font source and license

The unmodified Noto Sans Regular font was obtained from the official [notofonts/noto-fonts repository at commit ffebf8c1ee449e544955a7e813c54f9b73848eac](https://github.com/notofonts/noto-fonts/blob/ffebf8c1ee449e544955a7e813c54f9b73848eac/hinted/ttf/NotoSans/NotoSans-Regular.ttf). Its SHA-256 is:

```text
b85c38ecea8a7cfb39c24e395a4007474fa5a4fc864f6ee33309eb4948d232d5
```

Copyright 2018 The Noto Project Authors (github.com/googlei18n/noto-fonts). The font is distributed under the SIL Open Font License 1.1. The complete official license is included as `fonts/OFL.txt`. Keep that copyright and license with the font when redistributing it. No Arial font or Arial-based exploratory fixture is included in this package.

## Scope and audit notes

The synthetic faults demonstrate that visible page content and extracted text can disagree. They do not establish how common these faults are, measure OCR accuracy, or prove that any repair method will work on an arbitrary PDF. These were constructed examples with known faults, not a blinded assessment.

No OCR engine, OCRmyPDF repair, Acrobat repair, or BookTranslator upload was run. There were no excluded fixtures or reruns needed for this Noto-font generation. An earlier internal exploratory version used a system font and initially expected all four renders to match; that assumption was rejected. This public version tests the two meaningful pairs and retains both results, without choosing a favorable subset.