Xiangyun OCR Table and Document Recognition Pro

Problem

Many office documents exist as images or scanned PDFs where text, tables, and layout are mixed together. Direct copy often produces disordered text, breaks cell relationships, or leaves manual cleanup before the content can be edited.

How It Works

This skill wraps the Xiangyun OCR general document recognition API with typeId: 3050 to identify text, tables, and layout in images, PDFs, and scanned files. It loads credentials from config.json, environment variables NETOCR_KEY / NETOCR_SECRET, or user input, then accepts local files, dragged files, or batch directories. Recognition can be tuned by nLanguage, such as 2 for English or 11 for Japanese. For tables and multi-column reports, layout: 1 is recommended. Skewed scans can use autoRotation and inclineCorrect; watermark or background noise can be handled with removeWaterMark and filterColor. After a successful call, the result includes a consumeId, and the content is previewed as Markdown. When the user explicitly asks for export, it downloads xls, flowWord, boxWord, md, pdf, txt, or ofd files.

Limits and Notes

The skill depends on a cloud OCR service. During recognition, images and API credentials are sent to netocr.com, so it is not ideal for highly sensitive material that cannot leave the environment. Input quality matters: scanned documents should aim for 300DPI and stay under 3M, while normal images are around 200KB. Supported formats include PNG, JPG, JPEG, WEBP, TIF, OFD, and PDF. consumeId may expire, so failed downloads usually require re-running recognition. Export formats differ: xls suits data processing, boxWord preserves layout better, flowWord is for editable body text, and md is for document conversion. For mixed-language documents, choose the dominant language explicitly instead of relying on the default Simplified Chinese.