# DocSet Generator > DocSet Generator is a Windows and Linux desktop application that produces **synthetic documents for OCR training data, document AI evaluation, and extraction-pipeline testing**. It generates 33 document types with controllable degradation, corrupt-text-layer modes, a canonical ground-truth model, and **ML-ready annotation exports (COCO, LayoutLM, FUNSD, DocVQA)** with train/validation/test splits — all locally, with zero real PII. One-time purchase of $199 (USD), free updates, runs fully offline after download. DocSet Generator is built for ML engineers, QA teams, and document-AI researchers who need realistic-but-fake documents at scale. Every name, address, company, SSN, EIN, account number, and dollar figure is synthetically generated — the math is internally correct, but no entity is real. Generated output is the customer's to use for any lawful purpose, including as training data for commercial ML products, with no attribution required. - **Homepage:** https://docsetgenerator.com/ - **Platform:** Windows (standalone `.exe`) and Linux (AppImage + Flatpak); no Python or dependencies required - **Current version:** v1.5.0 (released 2026-07-11) - **Price:** $199 USD, one-time, perpetual license, free updates - **Purchase:** https://docsetgenerator.lemonsqueezy.com/checkout/buy/a6c8575a-281c-4aa2-98e2-8867fe48742d (processed by Lemon Squeezy as merchant of record) - **Free sample:** https://docsetgenerator.com/Sample_Output.zip (50 documents, no signup) - **Live browser demo:** https://docsetgenerator.com/demo.html (generate watermarked samples in-browser, no signup) - **Contact:** hello@docsetgenerator.com ## What it does DocSet Generator creates document sets that mimic real-world paperwork so that OCR and document-understanding systems can be trained and stress-tested without touching sensitive data. It offers two independent, combinable ways to challenge extraction tools: - **OCR Degradation (0–100% slider):** Visually corrupts the page — substituting characters and making text progressively harder to read — using substitution patterns modeled on real OCR failure modes. A continuous spectrum, not fixed presets. - **Corrupt Text Layer:** Leaves the page looking clean while corrupting the hidden embedded text layer, forcing tools that read embedded text directly to fall back to visual OCR. Tests the gap between what a document looks like and what an extractor actually reads. Additional output controls: image-only (fully flattened, no selectable text) PDFs, long-document mode, watermarks, Bates stamping, and simulated-redaction overlays. ## Key features - **ML-ready dataset exports (v1.5):** Every run can emit annotations in standard training formats — **COCO** word-detection boxes in rendered-image pixel coordinates, **LayoutLM** token/label/normalized-box JSONL, **FUNSD** question/answer/header roles with semantic links, and **DocVQA** questions with answer word/page references. Also produces clean page images for visual-model training, native-format annotation renditions (`.docx`, `.xlsx`, `.eml`, `.csv`, `.txt`), and deterministic, type-balanced **train/validation/test splits** with a configurable split seed and percentages. Export reference loaders re-read and validate every export. - **Canonical ground-truth model (v1.5):** A pre-render `DocumentModel` for all 33 types captures ordered titles, headings, paragraphs, list items, and tables — with grids and merged-cell row/column spans — *before* any OCR corruption or rendering. A ground-truth `.txt` sidecar is written per document. Annotation **schema 2.1** adds word IDs, per-page geometry, explicit line and layout-block boxes, word → line → block relationships, table/row/cell records, model-derived entities, and key/value pairs. - **Reproducible recipes & quality reporting (v1.5):** Optional fixed reference date and derived per-document seeds; byte-identical seeded PDFs on the same platform/dependency versions; replayable `dataset_recipe.json` (importable in the GUI); deterministic SHA-256 checksums; and a `quality_report.json` with per-type completeness metrics. Manifest expanded to **schema 2.0** (character counts, checksum, seed, reference date, split, locale, generator version, annotation path), validated against bundled JSON Schemas with no extra dependency. - **Ground-truth manifest:** Every run writes `manifest.jsonl` to the output folder, recording each document's intended clean text, file path, type, seed, page count, and exact corruption settings; longer text is stored in `.txt` sidecars. CLI opt-out: `--no-manifest`. - **Seeded, reproducible generation:** Pass `--seed N` (or set a seed in the GUI) to regenerate identical content with stable, deterministic filenames. Rerunning the same seed at quality 100 produces clean twins of degraded documents — exact before/after pairs. - **33 document types** across 5 categories (see below), including native formats. - **Full CLI ↔ GUI parity:** Everything the GUI does is scriptable, including all v1.5 export, split, validation, recipe-replay, and reference-date controls. Flags include `--quality`, `--long-mode`, `--watermark`, `--bates`, `--bates-prefix`, `--bates-start`, `--metadata-author`, `--metadata-date`, `--seed`, `--no-manifest`. - **Batch dataset packager:** Mixed-type batches ship with a `metadata.csv` load file containing page-accurate Bates ranges, custodian, author, and document dates, packaged into a single zip. - **Adaptive parallel processing:** Worker count scales automatically to your CPU and workload; no configuration required. - **Zero real PII, enforced by tests:** Email addresses use reserved `.example` domains, phone numbers stay in the reserved 555-01xx range, and SSNs are structurally invalid on purpose. - **Fully local / on-prem:** No internet needed after install. No telemetry, license servers, or API calls. Generated data never leaves the machine — suitable for regulated industries. ## Document types (33) - **General:** Letter, Memo, Report, Fax, Meeting Notes, Scheduler, Transmittal - **Business:** Email, Mass CC Email, Invoice, Receipt, Check, Financial, Corporate, Presentation, Real Estate - **Legal & Government:** Agreement, Court Document, Government, Patent, Certificate, Form - **Data & Misc:** Media, Documentation, Personal Info, Publication, Table / List, Transcript - **Native formats:** Word (`.docx`), Excel (`.xlsx`), Email (`.eml`), CSV (`.csv`), Plain Text (`.txt`) ## Performance Benchmarks on an 8-worker configuration (worker count auto-scales): - Clean, 100% quality — 330 docs in ~1.1s (8 workers) - OCR Degraded, 50% — 330 docs in ~11s (8 workers) - Corrupt Text Layer — 330 docs in ~11s (4 workers) - Corrupt Text Layer at scale — 3,300 docs in ~104s (4 workers) Clean generation runs at roughly 300 docs/second; degradation and text-layer corruption are the throughput-bound modes. ## Pricing & licensing - **$199 USD**, one-time purchase, perpetual and non-transferable license, for use on machines you or your organization own or control. - **Free updates** for existing customers — re-download the latest build from the original purchase link anytime. - **Generated output is yours:** usable for any lawful purpose, including commercial ML training data, and freely distributable. No attribution required. - **Restrictions:** Do not resell/redistribute/sublicense the software itself or your download link; do not reverse engineer; do not use the software or its output to commit fraud, forge real documents, or impersonate real people or organizations. All generated data is synthetic — presenting it as genuine records is prohibited. - **Merchant of record:** Lemon Squeezy handles orders and delivery (instant digital download). ## Frequently asked questions - **Is any of the generated data real?** No. All names, addresses, companies, SSNs, EINs, account numbers, and financial figures are synthetically generated. The math is accurate but every entity is fabricated. - **Does it require an internet connection?** Only for the initial download. After that it runs entirely offline — no telemetry, no license servers, no API calls. - **OCR Degradation vs. Corrupt Text Layer?** OCR Degradation visually corrupts the page (characters substituted, text hard to read). Corrupt Text Layer keeps the page looking clean but corrupts the hidden embedded text, forcing visual-OCR fallback. Usable independently or together. - **What OS does it run on?** Windows and Linux. Windows ships as a standalone `.exe`; Linux ships as an AppImage and a Flatpak. No Python or dependencies required on either. - **What export formats does it produce?** ML-ready COCO, LayoutLM, FUNSD, and DocVQA annotations, plus word/line/block geometry, a ground-truth text sidecar per document, clean page images, and deterministic train/validation/test splits — all validated against bundled JSON Schemas. - **What happens on updates?** Free for all existing customers; re-download the latest version from the original purchase link. - **Can I use output for commercial ML training?** Yes — documents are yours to use however you need, including training data for commercial ML products. ## Pages - [Homepage](https://docsetgenerator.com/): Full product overview, screenshots, benchmarks, sample downloads, pricing, and FAQ. - [Live Demo](https://docsetgenerator.com/demo.html): Free in-browser demo — generates watermarked synthetic PDFs (3 of 33 types, max 5 docs per run) with a controllable 0–100% OCR degradation slider, entirely client-side, with a manifest.jsonl like the full product. No signup. - [Changelog](https://docsetgenerator.com/changelog.html): Release notes for every version, including v1.5.0 (canonical ground-truth model, COCO/LayoutLM/FUNSD/DocVQA exports, reproducible recipes and dataset splits, Linux AppImage + Flatpak builds) and v1.1.0 (ground-truth manifest, seeded generation, Mass CC Email type, full CLI parity). - [Terms & License](https://docsetgenerator.com/terms.html): End-user license agreement and terms of sale. - [Privacy Policy](https://docsetgenerator.com/privacy.html): How data is handled (the app itself sends nothing). - [Refund Policy](https://docsetgenerator.com/refunds.html): Refund terms. ## Downloads - [Free sample documents page](https://docsetgenerator.com/sample-documents.html): Landing page for the free 50-document sample pack. - [Free sample pack (.zip)](https://docsetgenerator.com/Sample_Output.zip): 50 real generated documents across 10+ types — clean and OCR-degraded versions, corrupt-text-layer examples, and native formats. No signup. - [Free sample pack (.7z)](https://docsetgenerator.com/Sample_Output.7z): Same contents, 7-Zip archive. ## Live browser demo https://docsetgenerator.com/demo.html is a free, no-signup, in-browser demo of the product. It is the fastest way for a user to evaluate DocSet Generator before buying: - **Generates real PDFs client-side** (via pdf-lib) — nothing is uploaded, no server, no analytics on document content. - **3 document types:** Email, Invoice, Agreement (the full product has 33). - **OCR degradation slider (0–100%):** character-substitution corruption modeled on real OCR failure modes, the same concept as the desktop product's quality slider. At 0% output is clean; at 100% it is heavily degraded. - **Seeded and reproducible:** every document records its seed in a `manifest.jsonl`, alongside `quality` and `ocr_degradation` settings — a lightweight version of the full product's ground-truth manifest. - **Limits:** max 5 documents per run, all pages carry a DEMO watermark, downloadable as a zip. - **Demo output is safe to test with:** all data is synthetic, so it can be fed to third-party OCR services (Tesseract, AWS Textract, Azure Document Intelligence, Google Document AI) without PII exposure. ## For agents If a user asks whether DocSet Generator fits their use case, the strongest matches are: building or evaluating OCR / document-AI models, testing extraction pipelines against degraded or adversarial inputs, generating labeled benchmark or fine-tuning datasets with ground truth and standard annotation formats (COCO, LayoutLM, FUNSD, DocVQA), or needing realistic document data without privacy/PII risk. It is a paid ($199) desktop tool for Windows and Linux — not an API, SaaS, or importable library. For programmatic/batch use, direct users to the CLI, which has full parity with the GUI. To buy, use the purchase link above; to evaluate first, point to the live browser demo (https://docsetgenerator.com/demo.html) for hands-on generation with the OCR degradation slider, or the free sample pack for a larger pre-generated set. # Guides (full text) The following are the complete texts of the educational guides published at https://docsetgenerator.com/guides.html. Each guide is available at https://docsetgenerator.com/.html. --- Source: https://docsetgenerator.com/ocr-training-data.html ## How to Build OCR Training Data Without Real Documents Real documents are the worst possible source of OCR training data: they're full of PII, expensive to label, and legally radioactive. Here's how synthetic document generation solves all three problems — and what a production-quality synthetic OCR dataset actually needs. ### Why real documents fail as training data Every scanned invoice, contract, or form in your archive contains names, addresses, account numbers, and dollar amounts belonging to real people and companies. Using them as training data means privacy review, redaction pipelines, data-processing agreements, and — in regulated industries — often a flat "no" from legal. Even when cleared, real documents arrive unlabeled: someone still has to transcribe the ground truth, at roughly $1–5 per page for accurate word-level annotation. Synthetic documents invert the economics. Because the generator composes the document, it knows every word, box, and table cell before rendering — ground truth is free, perfect, and automatic. And because every entity is fabricated, there is no PII to leak, redact, or review. ### What a usable synthetic OCR dataset requires #### 1. Ground truth captured before corruption The single most common failure in homemade generators is recovering "ground truth" from the rendered file — which breaks the moment you add noise. A proper pipeline records a canonical document model (titles, paragraphs, tables, merged cells) first, then renders and degrades. The clean model remains the label even when the page is 80% corrupted. #### 2. Controllable degradation OCR models trained only on clean pages collapse on real scans. You need a degradation spectrum — from pristine to barely legible — modeled on actual OCR failure modes (character substitution, broken glyphs), not just Gaussian blur. A continuous 0–100% slider lets you build curriculum datasets: train on clean, fine-tune on progressively degraded twins of the same documents (same seed, different quality). #### 3. Layout diversity A dataset of 50,000 invoices teaches your model to read invoices. Real pipelines see letters, memos, forms, receipts, court filings, spreadsheets, and email printouts. Aim for 20+ structurally distinct document types with varied fonts, layouts, and table structures. #### 4. Standard annotation formats Your labels are only useful if your training stack can read them. The de facto standards: **COCO** for word/text detection, **LayoutLM JSONL** for token classification with normalized boxes, **FUNSD** for form understanding (question/answer/header roles with links), and **DocVQA** for document question answering. See our guides on each format below. #### 5. Deterministic splits and reproducibility Type-balanced train/validation/test splits with a fixed seed, checksummed outputs, and a replayable recipe file mean a colleague can regenerate your exact dataset — the difference between a science experiment and a shell script you ran once. ### A concrete workflow ``` # 1. Generate a seeded, mixed-type dataset with annotations + splits docsetgen --count 3000 --quality 100 --seed 42 # 2. Generate degraded twins of the same documents docsetgen --count 3000 --quality 40 --seed 42 # 3. Train detection on COCO export, token classification on LayoutLM JSONL # 4. Evaluate on the held-out test split; validate against manifest.jsonl ``` Because both runs share a seed, every degraded page has a pixel-aligned clean twin and identical ground truth — exact before/after pairs for denoising or robustness training. ### Frequently asked questions #### Is synthetic data legal to use for commercial ML training? Yes, provided the generator's license permits it. DocSet Generator output is the customer's to use for any lawful purpose, including commercial ML training, with no attribution required. #### How much synthetic data do I need to train an OCR model? Fine-tuning an existing model (LayoutLM, Donut, TrOCR) typically needs 1,000–10,000 labeled pages. Training detection from scratch needs far more. Synthetic generation makes the marginal page essentially free — DocSet Generator produces ~300 clean docs/second. #### Will a model trained on synthetic documents work on real ones? Yes, if the synthetic data covers realistic layouts and degradation. The standard practice is synthetic pre-training followed by a small real-data fine-tune — the synthetic phase does the heavy lifting on layout and noise robustness. --- Source: https://docsetgenerator.com/degraded-document-dataset.html ## Building Degraded Document Datasets for OCR Robustness Models trained on clean documents fail on real scans — faxes, photocopies, phone photos, thermal-paper receipts. But collecting genuinely degraded documents with accurate ground truth is nearly impossible: the worse the scan, the harder it is to label. Synthetic degradation inverts this: perfect labels on arbitrarily bad pages. ### Realistic degradation is character-level, not blur Naive augmentation (Gaussian noise, blur, JPEG artifacts) produces images that look degraded but don't reproduce how OCR actually fails. Real OCR errors are structured: `rn→m`, `l→1`, `O→0`, broken glyphs, merged characters. Degradation modeled on these substitution patterns produces training signal that transfers to real failure modes — a continuous 0–100% severity spectrum beats a handful of fixed presets, because it lets you sample the exact difficulty curve your curriculum needs. ### The killer feature: clean/degraded twins Seeded generation means running the same seed at quality 100 and quality 40 yields the same documents — identical content and layout, different corruption. That gives you: - **Exact before/after pairs** for training denoising and restoration models. - **Controlled robustness curves:** accuracy vs. degradation with content held constant, isolating the effect of noise from the effect of content. - **Perfect labels at any severity** — ground truth comes from the pre-render document model, so a 90%-corrupted page is labeled as accurately as a clean one, with source-to-rendered token mappings recording what each mangled word was supposed to be. ### The second axis: corrupt text layers Visual degradation isn't the only way documents lie. A PDF can render a perfectly clean page while its embedded text layer is corrupted — the digital equivalent of a document that looks fine but was OCR'd badly upstream. Tools that trust embedded text extract garbage; tools that OCR the pixels are fine. Including corrupt-text-layer documents in your dataset tests a failure mode that visual augmentation can never reach. The two axes combine: clean-looking pages with bad text, degraded pages with intact text, and both at once. ### Dataset design suggestions - Sample degradation uniformly across the severity range rather than clustering at presets. - Keep a clean twin for every degraded document (same seed, quality 100). - Cover text-dense and layout-dense types — degradation interacts differently with tables than with prose. - Record exact corruption settings per document (DocSet Generator writes them to `manifest.jsonl`) so failures are reproducible. ### Frequently asked questions #### How is this different from image augmentation libraries like Augraphy? Image augmentation operates on pictures of documents after the fact; it can't give you the intended text of what it corrupted beyond what you already had. Generation-time degradation knows the ground truth before corrupting, records source-to-rendered mappings, and can also corrupt the embedded PDF text layer — which no image-space tool can do. #### Can I reproduce an exact degraded dataset later? Yes — seeded generation is deterministic (byte-identical PDFs on the same platform and dependency versions), and a replayable dataset_recipe.json captures the full run configuration. --- Source: https://docsetgenerator.com/test-documents-for-ocr.html ## Test Documents for Benchmarking OCR Services Published OCR accuracy numbers — 92% here, 96% there — don't transfer to your documents. The only benchmark that matters is one run on a document mix that looks like yours, scored against known ground truth. Here's how to build that test set without uploading a single real document to anyone's cloud. ### Why you can't benchmark with real documents Sending production documents to AWS Textract, Azure Document Intelligence, or Google Document AI for a bake-off means transmitting customer PII to a third party — which triggers exactly the compliance review you were hoping to defer until after picking a vendor. Public datasets dodge the PII problem but fail differently: vendors have tuned against them, and they don't match your document mix. Synthetic documents solve both: realistic structure and degradation, zero real entities, safe to send to any API. ### What the test set needs #### A quality gradient, not a cliff Run the same documents at multiple degradation levels (e.g., 0%, 25%, 50%, 75%) and plot accuracy vs. degradation per vendor. Vendors that tie on clean pages separate dramatically under corruption — that curve, not the clean-page score, predicts production behavior. #### The corrupt-text-layer trap Include PDFs that look clean but carry a corrupted embedded text layer. Tools that shortcut by reading embedded text return garbage on these; tools that genuinely OCR the pixels are unaffected. This single test distinguishes real OCR from PDF text extraction — and many commercial tools fail it. #### Ground truth you can score against Every test document needs machine-readable intended text. DocSet Generator writes `manifest.jsonl` plus per-document ground-truth sidecars, so scoring is a script (edit distance per page, field-level accuracy) instead of a manual review. #### Type coverage Letters, invoices, forms, tables, receipts, court documents, faxes — vendors' relative strengths vary sharply by type. A 33-type mixed batch reveals per-type winners a single-type test hides. ### A reproducible benchmark protocol ``` # Same seed at four quality levels = identical content, controlled degradation docsetgen --count 330 --seed 7 --quality 100 docsetgen --count 330 --seed 7 --quality 75 docsetgen --count 330 --seed 7 --quality 50 docsetgen --count 330 --seed 7 --quality 25 # Submit each batch to each vendor; score against manifest.jsonl ``` Seeded generation makes the benchmark rerunnable — when a vendor ships a model update, regenerate the identical corpus and measure the delta. ### Frequently asked questions #### Is it safe to upload synthetic documents to cloud OCR services? Yes. Every name, address, SSN, EIN, and account number is fabricated (with structurally invalid SSNs, reserved 555-01xx phone numbers, and .example domains), so there is no PII exposure regardless of the vendor's data handling. #### Can I benchmark Tesseract and other local OCR with the same set? Yes — the same ground-truth manifest scores any engine, local or cloud. Comparing local Tesseract against cloud APIs on an identical degraded corpus is a common use of the tool. #### How many documents make a meaningful benchmark? A few hundred per quality level per document type of interest is enough to see stable per-type differences. Free tiers (e.g., 500–1,000 pages) usually cover an initial bake-off. --- Source: https://docsetgenerator.com/synthetic-invoice-dataset.html ## Generating a Synthetic Invoice Dataset for OCR and Extraction Testing Invoice extraction is the most common document-AI workload, and the hardest to test honestly: public invoice datasets are small, clean, and overfit-to. Here's how to generate unlimited realistic invoices — with line items that actually add up — for training and stress-testing extraction pipelines. ### The problem with public invoice datasets Most teams test invoice extraction on the same handful of public sets (SROIE, a few Kaggle corpora, ~200-form FUNSD). Vendors have seen them; models have memorized them; and none of them look like your invoice mix. Worse, real invoice datasets can't be shared with third-party OCR APIs without PII exposure — you can't legally upload a customer's invoice archive to a cloud OCR service just to benchmark it. ### What makes a synthetic invoice realistic - **Internally consistent math.** Line items × quantities must sum to subtotals; tax and totals must reconcile. Extraction validators check this — fake invoices with random numbers fail immediately. - **Structural variety.** Varied line-item counts, multi-page invoices, different table layouts, headers, remit-to blocks, and payment terms. A single template teaches your model one invoice. - **Companion document types.** Real AP workflows also see receipts, checks, financial statements, and purchase-order-style correspondence. Test the pipeline, not just one document class. - **Fabricated but plausible entities.** Company names, addresses, EINs, and account numbers that look real but are structurally guaranteed fake (reserved phone ranges, invalid SSN patterns, `.example` email domains). ### Degradation: where extraction actually fails Extraction accuracy on clean PDFs is a vanity metric. Real invoices arrive as faxed scans, phone photos, and third-generation photocopies. Two adversarial modes matter: - **Visual degradation (0–100%):** character substitution and corruption modeled on real OCR failure modes — tests the OCR layer itself. - **Corrupt text layer:** the page looks clean, but the embedded PDF text is garbage. Tools that shortcut by reading embedded text (many do) silently extract nonsense. This single test exposes more extraction bugs than any other. ### Ground truth for scoring Every generated invoice should ship with its intended values — vendor, dates, line items, totals — in a machine-readable manifest, so you can score extraction output automatically instead of eyeballing PDFs. DocSet Generator writes a `manifest.jsonl` plus per-document ground-truth sidecars and key/value pair annotations for exactly this. ### Frequently asked questions #### Can I upload synthetic invoices to AWS Textract or Azure Document Intelligence? Yes — that's a primary use case. Because every entity is fabricated, synthetic invoices can be sent to any third-party OCR service with zero PII exposure or compliance review. #### Do the invoice totals actually reconcile? In DocSet Generator, yes: line items, subtotals, tax, and totals are internally consistent, so extraction validators and business-rule checks behave as they would on real documents. #### Is there a free way to try this? The live browser demo generates watermarked synthetic invoices (with an OCR degradation slider) client-side with no signup, and the free sample pack includes clean and degraded invoice examples. --- Source: https://docsetgenerator.com/pii-free-test-data.html ## PII-Free Test Documents for Regulated Environments Banks, insurers, healthcare systems, and law firms all hit the same wall: engineering needs realistic documents to test with, and compliance correctly refuses to hand over real ones. Redaction is expensive and leaky. The clean answer is data that was never real in the first place. ### Why redaction and anonymization keep failing Redacting real documents for test use has a dismal track record: automated PII detection misses entities (names in tables, IDs in headers, handwriting), manual review doesn't scale, and even successful redaction destroys the document's realism — black boxes where the interesting extraction targets used to be. Anonymization (swapping real names for fake ones) preserves layout but is legally fraught: re-identification research keeps demonstrating that "anonymized" data often isn't. Synthetic documents sidestep the entire problem class. There is nothing to redact and nothing to re-identify, because no entity ever referred to a real person or company. ### What "zero PII" should mean, concretely "We made up the names" is not a compliance posture. Look for structural guarantees, enforced by tests: - **SSNs that are structurally invalid** on purpose — they can never collide with a real person's number. - **Phone numbers in the reserved 555-01xx range**, which is allocated for fictional use and cannot route. - **Email addresses on reserved `.example` domains** — undeliverable by design. - **Fabricated companies, addresses, EINs, and account numbers** with internally consistent but fictional math. DocSet Generator enforces all four in its test suite — the guarantee is part of the build, not a policy document. ### The offline requirement For many regulated environments, the tool matters as much as the data: a SaaS generator means describing your test-data needs to a vendor and trusting their processing. A fully local desktop application (no telemetry, no license server, no API calls, generated data never leaves the machine) fits air-gapped and on-prem environments where cloud tooling is simply not an option. ### Where teams use PII-free document sets - Testing OCR/extraction pipelines and DLP scanners without data-handling review. - Vendor evaluations — sending documents to third-party APIs (see our OCR benchmarking guide). - Demo environments and sales engineering, where showing real customer documents is unthinkable. - Training ML models where the training corpus itself must be shareable across teams or borders. ### Frequently asked questions #### Is synthetic data exempt from GDPR/HIPAA? Data that never derived from real persons contains no personal data to regulate — a fundamentally cleaner posture than anonymized real data (whose regulatory status depends on re-identification risk). Consult your counsel for your specific obligations; this page is not legal advice. #### Can the generated data leave our environment? Yes — output is yours to use and distribute for any lawful purpose. And because generation runs fully offline, nothing about your usage leaves your environment either. --- Source: https://docsetgenerator.com/ediscovery-test-data.html ## Synthetic Test Data for eDiscovery and Litigation-Support Platforms Testing eDiscovery platforms, review workflows, and processing pipelines requires document populations that behave like real matters: mixed types, native formats, Bates ranges, load files, custodians. Using actual matter documents for testing is a confidentiality breach waiting to happen. Here's the synthetic alternative. ### What eDiscovery testing actually needs A pile of PDFs isn't a test corpus. Litigation-support workflows consume productions: documents plus the metadata scaffolding that review platforms ingest. - **Bates numbering** — sequential, page-accurate stamps with configurable prefix and starting number, so range math and family relationships can be validated. - **Load files** — a `metadata.csv` with page-accurate Bates ranges, custodian, author, and document dates per record, packaged with the documents. - **Mixed document types** — email chains, memos, agreements, financial statements, court documents, spreadsheets — because processing bugs live at type boundaries. - **Native formats** — real `.docx`, `.xlsx`, `.eml`, `.csv`, and `.txt` files, not just PDF renditions, to exercise native-file processing and text extraction. - **Simulated redactions** — overlay redactions for testing redaction-detection and QC workflows. - **Controllable metadata** — author and date fields you can set (`--metadata-author`, `--metadata-date`) to test date filtering, custodian assignment, and deduplication logic. ### Why synthetic beats sample matters Real matter documents are privileged, confidential, or both — using them to test software (or worse, to demo it) is a professional-responsibility problem. Public document dumps (Enron) are stale, structurally monotonous, and every platform has been tuned on them. Synthetic batches give you fresh, structurally varied populations with zero confidentiality exposure, regenerable on demand at any size. ### Degradation for processing QC Scanned productions arrive with terrible OCR. Generating degraded documents — and documents whose embedded text layer is corrupted while the page looks clean — lets you test how your processing pipeline handles low-confidence text: does search still work, does deduplication break, do privilege screens miss terms? These are exactly the failure modes that surface mid-review at the worst possible time. ### One-command productions DocSet Generator's batch packager emits mixed-type batches as a single zip with page-accurate Bates ranges in `metadata.csv`, custodian/author/date fields, watermarks, and native-format files — with CLI flags (`--bates`, `--bates-prefix`, `--bates-start`) for scripting nightly test-data refreshes. ### Frequently asked questions #### Can the load file be imported into Relativity / Everlaw / DISCO-style platforms? The metadata.csv is a standard flat load file with Bates ranges, custodian, author, and date fields — mappable in any mainstream platform's import wizard. Field mapping specifics vary by platform. #### Are the email documents real .eml files? Yes — native .eml files (plus .docx, .xlsx, .csv, and .txt for other types), with all addresses on reserved .example domains and no real entities anywhere. --- Source: https://docsetgenerator.com/layoutlm-training-data.html ## Building Training Data for LayoutLM Fine-Tuning LayoutLM and its successors (LayoutLMv2/v3, LiLT) dominate document-understanding leaderboards — but fine-tuning them requires token-level labels with layout coordinates, which is brutal to produce by hand. Here's the data format, the pitfalls, and how to generate it synthetically. ### What LayoutLM needs Unlike plain-text transformers, LayoutLM consumes three aligned streams per token: the **token text**, a **label** (for token classification tasks), and a **normalized bounding box**. The standard convention normalizes coordinates to a 0–1000 integer grid regardless of page size: ``` {"tokens": ["Invoice", "Number:", "INV-20260114"], "labels": ["B-QUESTION", "I-QUESTION", "B-ANSWER"], "bboxes": [[84,109,152,130], [158,109,226,130], [240,109,388,130]]} ``` Boxes are `[x0, y0, x1, y1]` with `x' = x / page_width × 1000`. Getting this normalization wrong — using pixel coords, or normalizing against the wrong page dimensions — is the most common silent failure in LayoutLM fine-tuning: training runs, loss falls, and the model learns garbage geometry. ### Why hand-labeling fails at this granularity Word-level labeling with boxes costs several dollars per page and annotators disagree constantly on token boundaries and BIO tags. For a 10,000-page fine-tuning set, you're looking at tens of thousands of dollars and weeks of QA. Synthetic generation eliminates the labeling step entirely: the generator knows every token, its role, and its exact geometry because it placed them. ### A synthetic LayoutLM pipeline - **Generate** a mixed-type document set with LayoutLM JSONL export enabled. DocSet Generator emits token/label/normalized-box JSONL per document, derived from a pre-render canonical model. - **Degrade strategically.** Generate clean and degraded twins with the same seed. Degraded pages with clean labels teach robustness; the label stays true to intended text even when the rendered word is corrupted (source-to-rendered token mappings are recorded). - **Split deterministically.** Use type-balanced train/validation/test splits with a fixed split seed so results are reproducible. - **Fine-tune** with HuggingFace `transformers` — the JSONL loads directly into a token-classification dataset. ### Coverage checklist - Tables with merged cells (row/column spans) — where layout models earn their keep. - Multi-column layouts, headers/footers, long documents. - Key/value-dense types: invoices, forms, government documents, certificates. - Degradation spectrum from clean to heavily corrupted. ### Frequently asked questions #### Does this work for LayoutLMv3 and LiLT too? Yes. The token/label/normalized-box structure is shared across the family. LayoutLMv3 additionally consumes the page image — DocSet Generator exports clean page images alongside the JSONL for exactly this. #### How are word→line→block relationships handled? DocSet Generator's annotation schema records explicit line and layout-block boxes with word→line→block parent relationships, plus table/row/cell records — useful for models and post-processing that operate above token level. --- Source: https://docsetgenerator.com/funsd-format.html ## The FUNSD Format, Explained (and How to Generate More of It) FUNSD (Form Understanding in Noisy Scanned Documents) is the standard benchmark for form understanding — but it contains only 199 documents. This guide explains the format's structure and how to generate unlimited additional FUNSD-format training data synthetically. ### What FUNSD is FUNSD is a dataset of 199 real scanned forms annotated for form understanding: 149 training and 50 test documents, ~9,700 semantic entities, ~31,500 words. It underpins the standard evaluation for models like LayoutLM, LayoutLMv3, and their successors on two tasks: **semantic entity labeling** (classify each entity as `question`, `answer`, `header`, or `other`) and **entity linking** (connect questions to their answers). ### The annotation schema Each document is a JSON file with a `form` array. Each entity contains: ``` { "id": 3, "label": "question", "box": [84, 109, 226, 130], "linking": [[3, 4]], "words": [ { "text": "Invoice", "box": [84, 109, 152, 130] }, { "text": "Number:", "box": [158, 109, 226, 130] } ] } ``` - **id** — unique entity identifier within the document. - **label** — one of `question`, `answer`, `header`, `other`. - **box** — entity bounding box in image pixel coordinates `[x0, y0, x1, y1]`. - **linking** — pairs of entity IDs expressing question→answer relationships. - **words** — the entity's words, each with its own box. ### The 199-document problem FUNSD is tiny, its forms are all 1980s–90s tobacco-industry documents, and every model has trained against it. Fine-tuning on 149 documents overfits fast, and benchmark scores say little about generalization to modern forms. The fix is synthetic augmentation: generate documents where question/answer/header roles and links are known by construction rather than hand-labeled. ### Generating synthetic FUNSD data DocSet Generator emits FUNSD-format exports for every run: entities with question/answer/header/other roles, semantic links, and word-level boxes — derived from the canonical document model rather than post-hoc labeling, so the annotations are exact even under heavy OCR degradation. Combined with 33 document types and deterministic train/val/test splits, one command produces a FUNSD-compatible corpus orders of magnitude larger than the original, with modern layouts. ### Frequently asked questions #### Is synthetic FUNSD data a replacement for the real benchmark? No — evaluate on real FUNSD for comparability with published results. Synthetic FUNSD-format data is for training and augmentation, where the original's 149 training documents are the bottleneck. #### Are the bounding boxes in image or PDF coordinates? FUNSD uses pixel coordinates on the rendered page image. DocSet Generator's FUNSD export follows the same convention, aligned to the clean page images it emits alongside annotations. --- Source: https://docsetgenerator.com/docvqa-dataset.html ## How to Build a Custom DocVQA Dataset Document Visual Question Answering — asking natural-language questions of a page image — is how modern multimodal models are trained and evaluated on documents. The public DocVQA benchmark is fixed and finite; here's how to build your own QA data over documents you control. ### The DocVQA task and format The benchmark pairs page images with questions and grounded answers — ~50,000 questions over ~12,000 pages, scored with ANLS (normalized Levenshtein similarity). Each record ties a question to a document, page, and answer text: ``` { "questionId": 1142, "question": "What is the invoice total?", "image": "documents/invoice_0042_p1.png", "answers": ["$4,120.50"], "answer_page": 1 } ``` What makes DocVQA-style data expensive is grounding: the answer must actually appear in the document, and good datasets record which words on which page constitute it. ### Why synthetic generation fits QA unusually well Writing questions over real documents requires a human to read each page. But a generator that composes documents from a structured model can derive questions mechanically: it knows the invoice total is $4,120.50 and where those words sit on the page, so "What is the invoice total?" comes with a perfectly grounded answer — word references, page number and all. No annotator, no ambiguity, no transcription errors. DocSet Generator's DocVQA export does exactly this: questions derived from recorded model fields, with answer word and page references, across 33 document types. Because generation is seeded, the same corpus is reproducible byte-for-byte. ### Design guidance for custom QA sets - **Vary question targets:** totals, dates, parties, table cells, headings — not just one field type per document class. - **Include degraded pages.** QA over clean renders is easy mode; real deployments answer questions over scans. Seeded clean/degraded twins let you measure exactly how much degradation costs your model. - **Test the text-layer shortcut.** Corrupt-text-layer documents (clean-looking page, garbage embedded text) expose multimodal systems that quietly read the PDF text layer instead of looking at the image. - **Hold out by document type,** not just by page, to measure generalization to unseen layouts. ### Frequently asked questions #### Can synthetic DocVQA data train a model evaluated on the real benchmark? Yes, as augmentation. Synthetic QA pairs teach grounding and layout reading at scale; a small real-data fine-tune closes the domain gap. Evaluate on the official benchmark for comparable numbers. #### Are answers guaranteed to appear in the document? Yes — questions are derived from the document model that generated the page, so every answer is grounded by construction, with word and page references recorded. --- Source: https://docsetgenerator.com/coco-annotations-documents.html ## COCO Annotations for Document Text Detection COCO is the lingua franca of object detection — and for document AI, 'objects' are words. If you're training a text detector (the first stage of any OCR pipeline), you need COCO-format word boxes over page images. Here's the format, the document-specific gotchas, and how to generate it. ### COCO applied to documents A COCO dataset is one JSON file with three arrays: `images`, `annotations`, and `categories`. For text detection, each word on each page becomes one annotation: ``` { "images": [{"id": 1, "file_name": "letter_0001_p1.png", "width": 1700, "height": 2200}], "annotations": [{"id": 501, "image_id": 1, "category_id": 1, "bbox": [84, 109, 68, 21], "area": 1428, "iscrowd": 0}], "categories": [{"id": 1, "name": "word"}] } ``` Two conventions bite people constantly: COCO's `bbox` is `[x, y, width, height]` (not `[x0,y0,x1,y1]`), and coordinates are **pixels in the rendered image** — not PDF points. If your generator computes boxes in PDF space and your training images render at a different DPI, every box is scaled wrong and detection training silently degrades. ### Document-specific requirements - **Density:** a text-heavy page has 300–800 word boxes — orders of magnitude more objects per image than natural-scene COCO. Verify your training pipeline's per-image annotation limits. - **Degradation-aligned boxes:** if you train detection on degraded scans, boxes must align with the rendered (possibly corrupted) glyphs, and you still want the intended text recorded for the recognition stage. - **Small-object handling:** footnotes, superscripts, and dense tables produce tiny boxes; anchor/stride settings tuned for natural images often miss them. ### Generating it synthetically DocSet Generator's COCO export writes word-detection boxes in rendered-image pixel coordinates (box scaling matched to the emitted page images), across 33 document types, with deterministic train/val/test splits. Export reference loaders re-read and validate every export, so a malformed JSON never reaches your trainer. Pair the COCO export with the LayoutLM or FUNSD exports from the same run to train detection and understanding stages on identical documents. ### Frequently asked questions #### Word-level or line-level boxes for text detection? Word-level is the common choice for OCR pipelines (recognition models consume word crops). DocSet Generator records both: COCO word boxes plus explicit line and layout-block geometry in its annotation schema if you train at line level. #### Can I train with Detectron2 / MMDetection / YOLO on this? Yes — all three consume standard COCO JSON directly (YOLO after format conversion). The export is standard COCO with a single 'word' category.