Document Reader

Problem to solve

When an AI needs to inspect attached files or documents inside archives, formats are fragmented: PDF needs text extraction, xlsx needs sheet-level expansion, pptx needs slide-level chunking, and zip, rar, or 7z must be listed before a target file can be selected. Manual preprocessing interrupts context and is awkward for batch review.

How it works

Document Reader turns office documents and archives into a “list → select → output text” workflow:

• Office documents: supports pdf, docx, xlsx, pptx, rtf, odt, html/htm, and plain-text files such as txt, md, json, xml, py, and js.
• Archives: supports zip, tar, tgz, tar.bz2, rar, and 7z; it can first list contents and then read a specified document.
• Output modes: human-readable text or a JSON interface; file matching is case-insensitive and falls back to fuzzy matching when an exact match is unavailable.
• Structure handling: xlsx output is organized by sheet as table text, while pptx is chunked by slide for easier section-level analysis.

Boundaries and notes

It is designed for content extraction rather than document editing: it suits AI analysis, quick attachment review, data extraction, and preprocessing, but not modifying source files, preserving complex layouts, or reconstructing formulas. pdf extraction depends on poppler-utils, so scanned or encrypted PDFs may have limited fidelity. Archive support lists and reads internal documents without automatically extracting them to disk.