kallunwillock/chibipdf

1. Repository scope

- This repo currently contains a single delivered component: ChibiEx.

- The broader “ChibiPDF” suite is intended to include PDF generation too, but that part (ChibiScribe) is not present yet.

- So the architecture here is a self-contained VBA library for PDF extraction, rendering, and OCR.

2. Top-level structure

- src/ChibiEx.cls is the core implementation artifact.

- There are no separate service folders, native DLLs, scripts, or build pipelines in the repo.

- The library is meant to be imported/used directly from a VBA host application.

3. Primary runtime boundary

- The consumer boundary is a VBA host such as Excel, Word, Access, Outlook, PowerPoint, or VB6-compatible environments.

- ChibiEx runs inside the host process and exposes an object-oriented API to VBA code.

- There is no standalone executable; this is an in-process automation/library component.

4. Core subsystem: ChibiEx class

- ChibiEx is the central object that coordinates all functionality.

- It likely manages document state, current page selection, output buffers, and OCR results behind one class interface.

- The README shows it is used for both PDF operations and standalone OCR, so the class acts as a facade over multiple internal capabilities.

5. Input types supported

- The library accepts PDF files for text extraction and rendering.

- It also accepts image inputs for OCR: image files, HBITMAPs, StdPictures, and in-memory streams.

- This means the architecture is designed around multiple input adapters feeding a common recognition/rendering pipeline.

6. PDF text extraction flow

- For searchable PDFs, text extraction can happen directly from the document content.

- For scanned PDFs, the class automatically detects the image-based case and switches to OCR.

- The key architectural behavior is that the caller uses the same ExtractText API regardless of PDF type; the class hides the routing decision internally.

7. OCR pipeline

- OCR is done without external tools like Tesseract or Adobe Acrobat.

- The OCR stage relies on the Windows OCR engine available on supported Windows versions.

- For scanned PDFs, the flow is: PDF page → render page image → OCR in memory → return extracted text.

- For standalone OCR, the flow is: image input → OCR engine → ResultText.

8. Rendering subsystem

- ChibiEx can render PDF pages to PNG files, byte arrays/memory, streams, or StdPicture objects.

- This is a distinct output path from text extraction and is likely used both for user-visible exports and as an internal step before OCR.

- The API supports rendering all pages, a single page, a page range, or arbitrary page lists, which implies a page-oriented document model internally.

9. Output surfaces and data flow

- The library produces two main kinds of outputs:

- Text: returned as strings (ExtractText, ExtractAllText, ResultText)

- Images: written to files or returned as in-memory picture/stream/byte representations

- The data flow is deliberately in-memory where possible, especially for OCR of scanned PDFs, to avoid temporary files.

10. Dependency and infrastructure boundaries

- The repo explicitly targets no external dependencies: no Acrobat, no GhostScript, no Tesseract, no custom DLLs.

- The only meaningful external platform dependency is Windows plus the built-in OCR capability.

- This makes the architecture suitable for locked-down enterprise environments where installing third-party software is difficult.

11. Compatibility and platform model

- The project targets VBA 7.0+, 32-bit and 64-bit, and Windows 10 build 10240+ or later.

- The architecture must therefore use Windows/VBA-compatible interop patterns rather than native add-ins or unmanaged code.

- The README credit to WinRT interop techniques suggests the implementation leans on modern Windows APIs while staying usable from VBA.

12. What to draw in an architecture diagram

- Show a single ChibiEx VBA class at the center.

- On the left, show inputs from the host application: PDF files and image sources.

- Inside, show two main processing paths: direct PDF text extraction and render → OCR.

- On the right, show outputs as text results and rendered images/streams/files.

- Add one external platform dependency boundary only: Windows OCR / Windows runtime APIs.