Public evidence record · reviewed August 20, 2026
This record examines three archived Offline OCR screenshots from two desktop sessions. It shows what the artifacts support, exposes visible output problems, and explains why they do not justify an accuracy percentage.
Prepared by Lingyun Zheng, developer of Offline OCR.
Disclosure: this is a first-party product evidence record, not an independent laboratory review. Claims are deliberately limited to the archived artifacts and product implementation inspected on August 20, 2026.
Short conclusion
The archived artifacts support a limited workflow claim: Offline OCR processed a one-page PDF in one session, and a separate May 28 session rendered mixed prose and formulas, started a PDF export, and produced a DOCX that opened in Microsoft Word. They do not establish recognition accuracy because the original source page, expected transcription, exact app version, and correction log were not preserved together.
The dates and observations below come from visible information in the archived screenshots. The May 26 and May 28 captures are treated as separate sessions, not combined into a single end-to-end test.
The dialog reads “DeepSeek OCR Recognizing” and identifies a one-page PDF. The inspected implementation labels this engine “Local LLM”. The artifact does not reveal the input page, final result, or the device network state during the capture.
The May 28 editor view contains mixed prose and structured formulas. The export dialog states “Generating HD PDF”. Visible merged words remain in the document, so this is evidence of workflow completion, not perfect recognition.
Microsoft Word displays the exported .docx with mathematical notation rendered on the page. A screenshot confirms the visible result, but not the internal editability of every equation object.
Visible limitations
The May 28 screenshots visibly contain merged boundaries such as “RecognitionAbstractThis”, “CalculusIn”, “OperationsEvaluating” and “FoundationsIn”. Some headings and numbered sections also run into adjacent text. These are material editing issues and should not be hidden in a trustworthy example.
Several words and headings are joined together. A user should expect to restore spaces and paragraph boundaries before reusing the document.
The screenshots show integrals, fractions, matrices and Greek characters, but the missing source page prevents a symbol-by-symbol correctness check.
Opening a .docx in Word proves a usable document was generated. It does not, by itself, prove that every visible formula was stored as a native editable Word equation.
Reproducible testing
A future result can support accuracy claims only when another reviewer can repeat the run and compare the same input with the same unedited output.
No. It verifies parts of a real product workflow, but the public artifacts do not include the original source and reviewed expected output required to calculate accuracy.
The May 26 screenshot explicitly shows DeepSeek OCR, and the inspected product implementation identifies that engine as a local model. The screenshot alone does not prove the device network state. The processing mode used for the separate May 28 export session is not visible and is therefore left unclaimed.
No. It proves that a DOCX opened in Microsoft Word and displayed mathematical notation. Object-level editability requires inspection of the actual file, which is not part of this public record.
Visible limitations help users judge correction effort and prevent a workflow screenshot from being mistaken for an independently scored benchmark.
Use a representative page, keep the raw result, and review every formula before exporting or publishing the document.
Evidence record reviewed: August 20, 2026.