Document news

My reports and takes on OCR, PDFs, parsing, document models, releases, field notes, X, videos, and real questions.

Updated Oct 14, 2026, 10:59 AM UTC

40 reported updates · latest reviews first · RSS feed

99 watched sources

GitHub

Hugging Face

Web

X

YouTube

Date

articlearXivSource: 06.22.26

RT-DocLayout: Real-Time End-to-End Document Layout Analysis with Reading Order in the Wild

Original quality

Reviewed 10.12.26

PP-DocLayoutV3: putting blocks in reading order

My take — Reading complex layouts or columns straight across can split two different paragraphs into one sentence. PP-DocLayoutV3 takes a page image, finds blocks such as paragraphs and tables, and puts them in reading order. The Paddle team trained V3 to find the blocks and put them in order in one model. It takes every pair of blocks and does that in parallel. It adds up the pairwise estimates to figure out how many blocks likely come before each one, and then it's going to sort by that count. The model that was trained on both tasks made fewer ordering mistakes on the OmniDocBench benchmark. With separate training, the error score was 0.189 and 0.041 when it was trained jointly. https://isaacflath.com/pdf2production

X@antoine_chaffinSource: 10.07.26

New company, new team, same frontier results & same open license Happy to announce the release of our new embedding model family More than just an upgrade i

Original quality

Reviewed 10.12.26

Index documents with a large model, query with a small one

My take — Perplexity released a new embedding model that lets you index documents with a large model but search them with a really fast one. Normally you index PDFs for search in advance once. In those cases, the big slow model is worth it because the user is not waiting. Then you can use the small model for queries where users are waiting for results. Perplexity made the embeddings compatible using distillation. First they trained a large teacher model to match questions with relevant documents. Then they trained both released models, a 9B and a 0.6B, to copy that teacher's embeddings. With the large model handling both indexing and queries, it answered 92.4% correctly. With the small model handling both, that fell to 90.1%. So 2 or 3 more wrong answers per 100. https://isaacflath.com/pdf2production

X@VikParuchuriSource: 10.09.26

We made a fair OCR benchmark. And we're not ranked first. Introducing OmniParseBench - 16k tests across 90 languages with consistent, interpretable scoring. htt

Original quality

Reviewed 10.12.26

OmniParseBench: look at the pages, not just the scores

My take — Datalab released OmniParseBench, a new benchmark for testing document parsers. Overall scores don't tell you how a parser handles your tables. Datalab gives you separate scores for tables, handwritten, and even handwritten tables. They also show you how many tests each score is based on. They publish the data, the tests, and the scoring code. Gemini Flash did beat Datalab's most accurate parser on the overall score, though it costs about 5 times as much. That comparison does include Datalab's optional 25% discount for letting them keep your documents to train on them. I like this benchmark a lot, but to use it well, you still need to look at the pages and see whether they look like your documents. You can use a coding agent to download the benchmark dataset and put them all side by side so you can scroll through. https://isaacflath.com/writing/formative-vs-summative-document-evals https://isaacflath.com/writing/document-evals

articlearXivSource: 05.24.26

MinerU-Popo: Universal Post-Processing Model for Structured Document Parsing

Original quality

Reviewed 10.12.26

MinerU-Popo: headings need the whole document

My take — When a tool reads a PDF one page or a few pages at a time, it can mistake a section heading for the title of the whole document because it's missing that context. MinerU-Popo takes the text, tables, and images an OCR tool has pulled and works out which parts belong together, even across many pages. If there's a section heading at the top, it might assume it's the H1 header rather than realizing it should be an H2 or an H3 because it's nested in sections from the prior pages. POPO gives some of that context by comparing header levels that overlap and table fragments that continue across the page break. For retrieval, that gives you a section with all the supporting material. https://isaacflath.com/pdf2production

articlearXiv Document ResearchSource: 09.28.26

Xiaomi-OCR-0 Technical Report

Original quality

Reviewed 10.06.26

Xiaomi: a council of OCR models

My take — Xiaomi used a council of 8 OCR models to create training data. They were training a small OCR model to answer questions from tables and documents. To teach it tables, they needed table images paired with HTML with the correct words and layouts. They cropped a table from a document and asked 8 different OCR models to turn it into HTML. Then they compare all the results to flag examples that need more checking. They do this by ranking them based on how close they match to the other 7, and then they keep the top 3. If those 3 are very similar, they go with the one that's in the middle, which means highest average similarity with the other 2. That table image and HTML becomes a labeled training example. When the agreement is very low, they use Qwen 3.5. They give Qwen the pair with the highest similarity score between them, and then they have Qwen compare those with the original table image to get good HTML. Only the disputed examples are going through these extra Qwen checks, and Qwen is correcting the HTML. They then render this corrected HTML as a table image, and then Qwen can compare that table image with the original crop, find mismatches, and do another HTML revision. They can repeat this check as many times as they'd like. The corrected answer then goes back into the group of the 8 originals for the agreement check again. So if the agreement is still too low, then it goes to human review. I like this quite a lot because they're not assuming that their repair path works. It still has to go through the check. Now I’d be interested in diving in a little bit more because agreement doesn't necessarily mean they're agreeing on the right answer. If there's an extremely hard OCR document and almost every model makes the same kinds of mistakes, then they might all agree on the wrong answer. So just going based on agreement is a risk, but they are trying to mitigate that risk by having 8 models and not just a couple.

articleReducto EngineeringSource: 08.13.26

When is a bigger model actually better? A practical framework for model routing

Original quality

Reviewed 10.06.26

Reducto: model routing

My take — Reducto wrote about their auto-router approach with two trained regression models. When you need to extract text from a PDF, one of the first decisions is which OCR model to use. Often people use a router to do that by page because using the slowest model on every page wastes a lot of time and money. But if cheaper models fail 20% more often, then that's a problem too. You want the best of both worlds. Reducto's approach runs the same pages through a fast model as well as a bigger one. I don't know which models they used, but to build something similar yourself, you could use Tesseract for a super light model and Chandra for a heavy model. To create the dataset, run every page through both and score and time them. For example, Tesseract may score 80 out of 100 on one page and take 1 second, and Chandra might score 90 and take 3 seconds. The change between the two is what we want to predict. Now, instead of putting all of Tesseract's output into the regression model, they calculated statistics. For example, word count and confidence scores from Tesseract. Then we can train one regression model from statistics as the input to that accuracy delta between the two models, and then another from statistics to the latency delta. Once you have this estimated accuracy improvement and latency change, you can create logic to say whether that tradeoff is worth it for the particular page. Is a 5% boost in accuracy worth 3 seconds in latency? That depends on the use case. Now we did this for Tesseract and Chandra, but you could do this for any model pair. You could run something through LightParse and use that to predict whether Docling should be run for OCR. It could then predict, “Should I send it to Qwen for a VLM?” And you can build up this router that way. I think this is a pretty good approach to have the regression model. The other option is to have a classifier where you predict, is it worth it to move up or not? But the regression model kind of pushes that logic a little bit later. So that you can kind of tweak and adjust your router without retraining.

articleReducto EngineeringSource: 09.04.26

Reliable repetition detection for small VLMs

Original quality

Reviewed 10.06.26

Reducto: repetition detection

My take — LLMs and VLMs sometimes get into duplication loops, especially when they're OCRing a table that has copies of a table row. Many documents can have two identical rows, and then when they read those, the model is going to keep writing more copies instead of stopping in many cases. This is because VLMs use what it has already written to choose what comes next. Once it starts repeating, those copies make another copy more likely. There's a parameter called temperature that controls how much randomness there is, and a higher temperature gives other options more chances, which can break a repeating pattern. It's one reason why LLMs are often non-deterministic. But Reducto found that its model copied documents most accurately at a very low temperature. So it kept that setting and added code to check for repetition while the model was still writing. The first check looks for the same stretch of text several times in a row, but a row can keep repeating while its label changes. For example, S10 to S11 to S12, or an incrementing date or other number. The text doesn't match exactly, so Reducto added checks for numbers and labels that keep counting up. It also controlled how many copies there had to be when it stops depending on the length. So long sections don't have to repeat quite so many times. You can use the same approach with other models by checking the output as it streams back. You could stop the loop and retry the request. For OCR, that could mean trying the page again at a higher temperature or sending it to another model. If you host the model yourself, tools like vLLM can give you that control. If you're using a vendor API, you have to check to see if they support that. And this is important because sometimes a form or something else might really contain a blank section several times in a row, or for example, multiple signature lines on a large agreement. It's pretty normal. So as you eval this, you need to check to make sure you aren't cutting off valid tables that might have legitimate repetition.

modelPaddlePaddle / Hugging FaceSource: 01.20.26

PP-DocLayoutV3

Original quality

Reviewed 10.06.26

PP-DocLayoutV3: curved text

My take — PP-DocLayoutV3 is a new OCR model that handles warped, curved, and angled text and layouts. This is really great for OCR when you have scans that are crooked, product photos from different angles, security footage, or robotics where your angle is wherever the camera happened to be, and more. PP-DocLayoutV3 classifies and segments regions and predicts reading order. Then there's a model after that to read what's in the boxes. As you can see, the bounding boxes are not just a square. It can handle a lot of these warped images nicely, and it can put them at an angle. If we compare this to another approach, we can get bounding boxes, and it's like, yeah, it kind of works, but it's also kind of weird. Incorrect text fits inside of them. The bounding box is clearly way bigger than it needs to be. So for the bounding box in the paragraph to work, it has to be so big that part of the title is actually in that bounding box. This kind of thing happens all the time when you have user intake forms and you're maybe doing identity verification where you're scanning birth certificates and driver's licenses and things like that.

releasedocling-project/doclingSource: 10.01.26

v2.132.0

Original quality

Reviewed 10.06.26

Docling: section lines & reading order

My take — Docling's new version uses section lines on the page to get a better reading order. If reading order is off, extracts are almost impossible to read because the paragraphs are out of order. This is the first page of a geology paper from their examples. The red arrows show the order Docling reads the blocks before the change. The reading order goes from the keywords on the left to the introduction, and then it jumps to the abstract, and then it goes back to the rest of the introduction. And that's a very confusing way to read that. If you try to extract this to Markdown, it just wouldn't make any sense. In the new version, it goes from the keywords to the abstract before going to the introduction because Docling is requiring blocks above that section line to be read before moving on, and that makes it move to the abstract instead of continuing down the left side. Here's the same problem in a newspaper example. There's section lines that separate the interviews up top from the portraits below them. The old order reads the first interview column, drops to the bottom left portrait, comes back up for the next interview column, and jumps back and forth like that. When the divider is included, it finishes the interview columns above the line and then goes to the portrait strip, which is exactly how almost any human would read this. This means extraction is much clearer in these types of use cases.

releasedocling-project/doclingSource: 09.29.26

v2.131.0

modelHugging FaceSource: 09.24.26

ATH-MaaS/Ovis-VL-Embedding family released

Quality

Reviewed 09.28.26

Ovis-VL-Embedding: new embeddings trained on docs

My take — A PDF assistant needs to find the page with an answer, even if that's in a chart, a table, or a scanned document. Ovis-VL-Embedding takes Qwen 3.5 and adapts it for that retrieval step. Their training set includes DocVQA for document questions, TextVQA for text inside images, and InfoVQA for infographics. The model also trains on ordinary photos and videos, but documents are what I'm focusing on here. To test this, I had it search for Ensign Peak. The map came back first, even though the printed label is abbreviated to Ensign Pk, isn't super clear, and has lines all over it. I then searched for underwriting fee. The first result was the closing-cost page with the scanned table containing the fee.

articleJina AISource: 09.14.26

jina-ocr-v1: Faster Document Parsing on Low-Budget GPUs

MODEL RELEASENEW

Quality

Reviewed 09.25.26

Jina OCR and speculative decoding

My take — Jina released a new OCR model aimed at reading difficult pages faster and more accurately. They started with DeepSeek OCR, trained it more on difficult scans, tables, and formulas, and collected and generated examples of the mistakes it made. They gave partial credit for partially correct tables and formulas. After training, they kept the OCR model fixed and trained a small draft model to predict its next tokens. The full model checks several drafted tokens in one pass to speed up the output. That's speculative decoding. I tried the hosted API on an earnings statement, checking three financial rows across three years. All nine values appeared under the correct years, including the negative investment result for 2022. The model weights have a noncommercial license, so reach out to their team if you're going to use them in a product. My full talk with Joe Barrow on speculative decoding: https://youtu.be/vXqq9xpBWWk

X@NielsRoggeSource: 09.18.26

2 new OCR models landed on @huggingface today - tencent/WeVisDoc (2B and 4B), Apache 2.0 - jinaai/jina-ocr-v1, non-commercial license Which one should you pick?

Quality

Reviewed 09.25.26

WeVisDoc OCR on difficult scans

My take — An OCR model trained on clean pages is going to struggle with blurry scans and unfamiliar layouts. Tencent trained WeVisDoc to solve that, with 2B and 4B models released under Apache 2.0. They started with Qwen3-VL, trained it on a variety of documents, and used data augmentation to blur and distort pages. Then they checked its errors and trained it more on the things it struggled with. I tried the 2B version locally on a Berkshire earnings statement. Revenue, investment gains or losses, and expenses were all correct. On a NASA scan, it returned equations as LaTeX but read a subscript F as a T. It did great on typed equations. I'm optimistic about using these data augmentations to make OCR models more reliable.

releasedocling-project/doclingSource: 09.16.26

Docling v2.128.0 adds Nemotron-Parse-2.0 VLM and minimal AFP support

SOFTWARE RELEASEMATERIAL

Quality

Reviewed 09.25.26

Docling adds an AFP print-file reader

My take — Using AFP print files in an OCR workflow takes a specialized reader. AFP is used by IBM printing systems, and Docling has added a reader that extracts the text directly. I tested it on two public sample files. On the first, Docling recovered phrases like "C++ compiler" that I could find with a text search. It also joined some words together and garbled some characters. The second file came back mostly unreadable. I suspect the encoding is part of the problem. This reader currently assumes one encoding, and Docling gives a warning about that limitation. AFP files can also contain images and barcodes, but this release only extracts text. Even with those limits, it's a useful start to getting searchable text out of these print files.

X@jdrhyneSource: 09.16.26

A specialized chart parser we trained just beat Gemini 3.8 Flash, Claude Opus 5, and GPT-6 Astra on our 2,500-chart benchmark. @nutrientdocs scored 0.857 F1 at

X UPDATEUNCLEAR

Quality

Reviewed 09.25.26

Nutrient chart OCR: 28.8% versus 28.5%

My take — Nutrient released a chart reading model that turns chart images into table values. Each value is linked to its category and its series. I tried its demo on a CDC chart about how often students eat fruit. The chart didn't have specific values printed on it. The model created five rows for the population groups and five columns for the consumption frequencies. For the total population eating fruit less than once per day, it returned 28.8%. The correct value from accompanying CDC data that I didn't give to the model was 28.5%. It recovered the group and series correctly, but these aren't going to be exact values in all cases. You need to handle them as estimates. It's great to see work on extracting chart values into a table, JSON, or CSV.

releaseopendatalab/MinerUSource: 09.16.26

mineru-4.0.0-released

Quality

Reviewed 09.24.26

MinerU 4.0: read a passage without loading the full PDF

My take — MinerU 4.0 gives an agent answering a question about a long PDF a way to read the document without loading it into every prompt. As MinerU parses your PDFs, it builds a local keyword search index in SQLite. An agent can find a matching document and read individual pages or passages, without building an indexing pipeline yourself. I tested it on a 23-page financing agreement. For this test, MinerU read the text already stored in the PDF. It gave each passage an address containing its document, page, and block number. I used one of those addresses to retrieve just the clause saying payments are due on May 15 and November 15. That lets an application do keyword search with SQLite and then fetch the passage with the answer, without sending the entire agreement into the next prompt. All of this is done locally.

articleLlamaIndex BlogSource: 09.22.26

LiteParse Updates: September 2026

Quality

Reviewed 09.24.26

LiteParse: fast PDF text extraction, but check the table rows

My take — LiteParse extracts PDF text very quickly and flags pages that might need OCR or more advanced processing. It bundles Tesseract when OCR is needed. LlamaIndex reports about 3 milliseconds per page with OCR off, meaning just the text layer. I tested it on Berkshire Hathaway's earnings statements. The JSON result said needsOcr: false and had table-likely in its layout flags. I extracted the text without OCR and checked revenue, investment, and expense totals across all three years. All the values matched, but it merged the insurance premiums and sales rows into one row instead of two. One fix would be a routing rule that sends every page flagged table-likely to a table parser, but that might be overkill. To send smaller regions, you could turn on table blocks in the library, get bounding boxes for detected tables, and send just the part you need to a parser.

X@VikParuchuriSource: 09.16.26

Structured extraction is hard to eval, and most benchmarks are biased, or have bad scoring/GT. That’s why we made OmniExtractBench - 620 docs from multiple vend

articleDatalab BlogSource: 09.16.26

Extraction benchmarks aren't fair, so we made one you can audit

Quality

Reviewed 09.23.26

OmniExtractBench: seeing which values matched or went missing

My take — Choosing an OCR model is hard when a benchmark covers different documents from yours and the score doesn't say what really went wrong. Datalab's new OmniExtractBench has 620 documents drawn from four vendors' benchmarks. It reduces dependence on one vendor's selection to try to make it more fair. It includes huge tables with repeated values, forms, research papers, and filings. The scorer tells you which values matched, which were misread, missing, or invented, so you can understand what's really happening. I wanted to try it for myself, so I ran Datalab's extractor on a report and scored its output against the benchmark's expected answers. The scorer found 60 matching values and one missing row label. In Excel, I can see the field, expected value, returned value, and verdict. I then deleted the first row of the casing table to test the scorer. It marked those values as missing, but the next row still matched. The benchmark code and scorer are on GitHub, and the README links to the full dataset on Hugging Face.

articleReducto BlogSource: 09.14.26

How Finch Legal Uses Reducto to Help Paralegals Manage 5x More Personal Injury Cases Reducto

Quality

Reviewed 09.16.26

Finch Legal: citations for checking the original document

My take — OCR is part of how Finch Legal got its paralegals to handle 5 times the usual caseload. Normally, paralegals pick up a case they haven't touched in a while and they need to call the client, but first they need to go through medical records or email or insurance paper to figure out what all happened since they last looked. Finch says that catch-up took about a half hour before they could do the phone call. Now Finch starts working through the paperwork as it arrives. Reducto, an OCR vendor, reads every document and keeps track of where the information came from. Finch then has a system to show what changed, flag a missing signature, get the paralegal's attention. When the paralegal needs to look into something deeper, they have a citation that jumps them back to the spot in the actual original document. This is important because if fact-checking takes as long as it would be to go through it manually, it doesn't save any time. The citation is what lets them have a review, understand what it says, jump back and quickly fact-check, and save all that time. In most real-world product workflows, this is pretty necessary.

X@VikParuchuriSource: 09.09.26

If you're blind, most PDFs are a garbled mess - and having one fixed can cost >$100. Our API now makes them usable for pennies. https://t.co/K714DnR3wM

Quality

Reviewed 09.16.26

Datalab: readable text and document structure for screen readers

My take — Datalab has an API that adds readable text and document structure to PDFs for screen readers. Let's look at the calculus example. We can see from the original text that there's all kinds of structure there. There's integral calculus on the top. There's prove that with a number next to it, and underneath that there is an equation, and we can see that it's indented. And so there's all kinds of visual information that just pure text doesn't represent. And we can see that when we look at this text layer. It's very garbled. It's not something that you would want to read and make any sense of. So instead, if you use the Datalab API, you can see that the structure is extracted. We see text and formula and text and text and formula and text, all of these in different sections that can be nicely parsed and rendered depending on the type, formulas get rendered as formulas, and then text can get rendered that way. I would still have a human in the loop check this, but this is really cool because PDFs often are not very accessible to people who are blind or other things. And so this is a step to helping that, and hopefully it just reduces the cost of getting really good translations and really good accessible ways of reading existing PDF documents.

videoLandingAISource: 09.08.26

LandingAI Introduces Split API to Separate Bundled Documents into Typed Sub-Documents

PRODUCT/API UPDATENEW

Quality

Reviewed 09.16.26

LandingAI Split: separating bundled documents

My take — LandingAI Split takes a parsed PDF and the descriptions of document types that you want. It'll return each document's type, pages, and text, and so intake systems can send it to the right type of extraction. I tried two sample packets with this, a lease with its attachments and a medical chart from a hospital stay. There's 18 pages and it comes as one file, as leases often do, but there's actually 8 different documents in there. The 6-page lease, house rules, security deposit policy, concession acknowledgement, and the bed bug, mold, pet, and satellite addendum. LandingAI split this into all the different documents just as you would expect. Some of them were 6 pages, the pet addendum was 3, and it worked perfect. The second was a sample chart. It includes a registration, a consultation, an operation, progress notes, and all kinds of other medical things. Here we want to split it by report. So the lab report can go to a lab results extractor and an operative report can go to a separate extraction. We can't really split it based on condition because the diabetes and heart disease may be on the same page and scattered across pages. This worked really well except for one page. This page is explicitly marked Medical Report Continued, and so I would have expected it to get this split correct. In both cases, this is very useful. You often have these mixed jumbles of reports, especially when a customer or a patient is filling out forms where they might have 5 or 6 different forms and they just get scanned together. And breaking them up really makes things a lot easier.

videoLandingAISource: 09.08.26

Extract Structured Fields from Documents

videoLandingAISource: 08.19.26

High Volume Parsing and Extraction with Snowflake Insertion

articleLandingAI BlogSource: 08.13.26

LandingAI releases Snowflake streaming pipeline using ADE Gen2 and DPT-3

SOFTWARE RELEASENEW

Quality

Reviewed 09.09.26

LandingAI DPT-3: Extract document fields into SQLite

My take — LandingAI's ADE Gen2 releases DPT-3, a model that turns PDFs into text, page structure, and source locations. A separate extraction call returns whatever fields you ask for. I tried it on a loan estimate and a closing disclosure from my doc lab. I asked for estimated and final cash to close, plus estimated and final closing costs. My code loaded those fields into SQLite. Across both pages, all six dollar amounts matched the source. Cash to close went from $16,054 to $14,147.26, while closing costs went up from about $8,000 to about $9,700. The loan estimate's two final amounts weren't on the page and ended up empty in SQLite, just as we would expect. I think there's a lot of use cases for structured extraction and then putting it into a database like SQLite, but also Snowflake or Postgres or whatever you're using in production. A lot of these documents have tables or specific values that you want to be able to query or show in a dashboard all the time, and this seems like a great way to do it. If you try this out on your documents, let me know how it goes.

articlearXivSource: 09.03.26

STAIR (STructure Aware Information Retriever): A novel dataset and LLM based retriever for document structure augmentation

research papernew

Quality

Reviewed 09.09.26

STAIR: Find document sections using a table of contents

My take — There's a new paper about training an LLM to find the right section of a document using its table of contents. The paper shows an example with a question about plurality voting. The table of contents points to an electoral systems section of a politics textbook. They started with books that already have a table of contents, extracted those, and mapped the sections to the text. They generate training questions from the books and fine-tune Mistral-7B to select the matching section. When you search, you put your question and the complete table of contents into the model. It gives you a section identifier, and your application can then go fetch that section's text. I wasn't able to find a public repository for the trained model that was linked in the paper, so that might be coming soon. But this idea of using the table of contents, the kind of manually curated structure, to find sections of documents seems really important. There's a lot of PDFs that start with a table of contents or some sort of header. I wonder if you could use a similar approach to generate a table of contents based on all of the headers. Models like Chandra identify which ones are headers, and you could use that to create the section mapping needed for this work. It would be interesting to see that and see if that helps retrieval.

modelHugging FaceSource: 09.04.26

tencent/EVIE family released

Quality

Reviewed 09.09.26

EVIE: Search document page images

My take — Tencent released EVIE, a family of open-weight models for searching document page images. You index the pages, then give it a question, and it ranks the pages that match. These matches can include charts and diagrams, the things that don't get represented very well in text. Each page is turned into multiple vectors (late interaction), so different parts of the image can contribute to the match, whether it's part of the text or the diagram. I ran it on a variety of documents that I had and gave it questions like finding the CDC fruit and vegetable chart, NASA's process diagram, and the loan estimate's cash-to-close page. The intended page was ranked first for all three. This wasn't a widespread benchmark, and I'd like to find where this fails, but in a few realistic cases it did work. If you give this a shot, I'd love to hear how it works for you in a real production workflow.

X@datalabtoSource: 09.04.26

The school year is starting, and we're excited to share how we worked with Davis County School District to bring STEM to braille. 🎒🏫 Ryan is a Teacher for Stude

articleDatalab BlogSource: 09.04.26

How Davis County School District brings STEM to braille with Chandra

Quality

Reviewed 09.07.26

OCR in the Schools: STEM Materials in Braille

My take — A teacher in Davis County is using Chandra's OCR to help get math and science students materials in braille. He's a certified braille transcriber, and this lets him get teaching materials ready for students where state transcription services don't have them ready yet. Some students arrive during the school year. Some curriculum gets written after the final deadline for sending it to the state. So Ryan Hunsaker has to produce those himself. He'd already tried OCR, but it left him with equations missing and paragraphs out of order. Chandra produces Markdown and LaTeX that he sends through Pandoc into his braille tools. He says checking OCR now takes 5 or 10 minutes. I like that he measured the time he spends fixing the output. A model can get most of a page right and still leave you with lots of cleanup to the point where you haven't saved much work. Measuring the time from having model outputs ready to having something useful enough to send out to people is a really important thing to look at. This is a great example, and I love that this is helping. Datalab case study: https://www.datalab.to/blog/davis-county-datalab-casestudy