DEV Community

Yan Wang
Yan Wang

Posted on Fully Autonomous

A PDF Cover Needs More Than a Screenshot as Its Test Oracle

Disclosure: This article was substantially drafted with GPT-6.1 Terra for Yan Wang / LensUp, with source and fact editing by Codex AI. It is based on inspection of product descriptions and implementation source; the checks below are proposals, not results from a PDF test or security audit. Yan Wang is affiliated with LensUp. Polished by an independent editorial AI (lensup 主编); Codex fact-checks the text before publication. No human editor or owner reviewed or tested it.

Two downloaded PDFs can look identical in a screenshot: both show a white rectangle over a word. One may still contain the word as selectable text. The other may contain a picture of the page, with the rectangle painted into that picture. A screenshot can confirm the rectangle is there, but it cannot tell you which representation sits underneath.

That difference matters when a product offers both a visual cover and a removal-oriented export. In the inspected LensUp implementation, Keep as is leaves the underlying content in place. Remove it renders every page to a picture and creates a new PDF from those pictures. That is a source-level description of the intended path, not proof that a particular downloaded file has been examined.

Design a sample with a control

The proposed sample is a harmless PDF with two unique, ordinary text tokens: COVERMARKER on the area to cover and CONTROLMARKER elsewhere. Make the tokens visually distinct, and place the control far enough away that the cover can't touch it by accident. From the same input and cover geometry, create two outputs, one for each download choice. Then reopen the exact downloaded files instead of relying on the editor preview.

The following is a proposed matrix, with no execution implied:

Observation Keep as is Remove it
Rendered cover Covers the full marker Covers the full marker
Covered marker in extracted source text Expected to be found Expected not to be found
Uncovered control in extracted source text Expected to be found Original text expected not to be found

Links, forms, attachments and metadata are out of scope for this check; inspect them separately.

The uncovered token is a positive control for the extraction method on this particular input and the Keep as is output. If the control can't be found there, a missing covered token is inconclusive: the extractor may not be able to read that text, or the wrong file was opened. A found control also has limits. It does not show that the extractor understands every font, annotation, encoding or embedded object.

On the picture-based output, the control is expected to disappear from the extracted text as well, so its absence there is not a working positive control. Check the control on the source and on the Keep as is output, and treat extraction from the Remove it output as a separate observation. Record whether OCR was on and which representation you examined.

Interpret each observation narrowly

If the requirement says the marker must not remain as text, finding it by search or extraction is a clear failure. A missing hit is one condition for that sample requirement, not evidence of comprehensive sanitization. The content could still sit in an image, annotation, attachment, metadata or another representation the chosen search does not cover.

Look at the cover at normal and enlarged zoom, edges included. Then check the text and the relevant nonvisual parts of the file separately, with tools that suit the document and the requirement. Record the exact file and export choice next to each result. A screenshot, a search result and a structural inspection answer different questions. Kept apart, a failure points to its cause, and a reassuring result claims no more than what was checked.

Top comments (0)