Summary
Every document parser has to decide reading order, and the usual designs pay for it in either speed or labeling. OXR moves it into recognition and makes layout analysis a pluggable module.
Where should reading order live in a document parsing pipeline?
Most of the attention in document parsing goes to recognition. But where you put reading order decides how fast the pipeline runs and how much data you have to label to adapt it to your business.
That question shaped OXR, a 1.3B open-source document parsing model from the team behind SoMark. It turns PDFs and document images into Agent-Friendly data, in Markdown or JSON.
OXR runs reading order together with recognition, in the same model and the same stage, and keeps layout analysis as a separate, lighter model that you can swap out. Together with its recursive self-improvement (RSI) training, this task-level design is part of why OXR ranks #1 on olmOCR-Bench, OmniDocBench, and DocParsingBench, and ranks #1 among open-source document parsing models in speed tests on an RTX PRO 6000. The rest of this post explains why we designed it this way and how it compares with the other options.
Every parser runs the same three steps
Over the past two years, document intelligence has filled with new players, and most of them started with parsing. The industry has settled on three steps:
- Layout analysis: detect the position and type of each element on the page.
- Element recognition: process each element according to its type.
- Reading order: arrange the elements in natural reading order.
Every one of these tasks has the same shape. Text is image to text, a formula is image to LaTeX, a table is image to an HTML table, and layout analysis is image to a string of coordinates. They all turn an image into a language sequence, so in principle one vision-language model (VLM) can do all of them. What differs between systems is how the work is split across models and stages, and that split is where the reading order cost comes from.
Four designs, four different bills
1 model, 1 stage
DotsOCR, DeepSeekOCR, and MinerU-VLM do layout analysis, reading order, and recognition in one pass. It is simple and slow, because the whole page comes out one token at a time.
1 model, 2 stages
Dolphin and others run layout analysis and reading order first, then recognize all elements in parallel. That speeds up a page several times over, and MinerU went back to this approach in versions 2.0 and 2.5.
A VLM still emits layout boxes one at a time, though, orders of magnitude slower than a conventional detector that outputs hundreds at once. The field accepted this because the order in which the VLM emits boxes is the reading order. Moving layout analysis out of the VLM would mean solving reading order with another model.
3 models, 3 stages
MonkeyOCR pulled everything apart: layout analysis, then recognition, then reading order. Layout analysis became very fast, but reading order turned into its own sequential stage with a heavy model. LayoutReader is the only open-source reading order model, and it is large and slow.
2 models, 2 stages
PaddleOCR-VL merged layout analysis and reading order into one small specialized model. That let layout analysis leave the VLM and return to detector speed, and it became the standard answer almost overnight. Many models released in 2026, including GLM-OCR and Falcon-OCR, use its layout-and-order model directly and build only their own recognition model.
So is that the best we can do? The merged design has a price. Every new layout annotation needs a matching reading order annotation, which doubles the labeling work. Training it also means leaving the familiar PyTorch ecosystem: PaddleOCR is well engineered, but you lose the community's toolchain.
Layout rules differ by business, so layout analysis should stand alone
How a document is written depends on the organization, the language, and the author, so there is no universal definition of layout. The same page can be divided in different valid ways:
- Element type: is a text box a title plus text, or one table?
- Region boundary: is a dense group of pictures one region, or one region per picture?
- Content grouping: is a picture full of text one figure, or a figure plus text elements?
Each answer serves a different need. For high-quality parsing, the need to customize layout analysis never goes away, so it helps to make that part independent.
OXR's answer: reading order goes with recognition
Layout Analysis → Recognition + Reading Order
Reading order benefits from understanding the content, so it belongs with recognition. Layout definitions depend on the business, so layout analysis stands on its own. OXR is also two models in two stages, with the split in a different place. A lightweight layout model returns only region types and bounding boxes. OXR then recognizes each region and, in the same stage, predicts the reading order from the full-page image plus each region's ID, type, and boundaries.
Faster and more accurate
Parallel layout detection plus parallel element recognition already put two-model, two-stage designs far ahead of the others on speed. Reading order takes far less time than recognition, so running them together removes the time that reading order used to add to the pipeline. Layout analysis no longer carries reading order either, so a smaller layout model can reach the same accuracy.
Reading order also becomes content-aware. It is predicted from the full page, with content and layout context together, so OXR can work out how columns, headings, captions, and body text relate, which a purely visual ordering model can miss.
Pluggable layout analysis
Layout analysis is now a fully independent model and task, and OXR doesn't restrict its form or categories. You can pick any approach from the object detection community, which has matured over decades, and plug it into the pipeline. In practice:
- Start with the built-in layout model. It's in the
layout_analysisfolder of the OXR weights on Hugging Face. - Bring your own detector if your business has its own layout rules. Adapt the interface, then re-evaluate reading order on your data.
- Fine-tune the layout model on your own annotations. Reading order is already trained into OXR, so you don't need to label it.
The built-in model is based on D-FINE, a recent SOTA object detector. We trained and optimized it, and OXR ships the PyTorch model. D-FINE's authors don't provide deployment support, so we also optimized its operators and exported it for ONNX and TensorRT. That engineering code isn't open source yet because of commercial contracts we've already delivered.
Where reading order belongs
Beyond model capability, how tasks fit together can be what separates one pipeline from another. Combining tasks or splitting them each has benefits and costs. Reading order rarely makes benchmark headlines, but it decides how fast your pipeline runs and how much labeling it takes to adapt a model to your documents. With reading order handled inside OXR, you can spend your effort on the layout rules that are specific to your business.
Real documents are more varied than any design anticipates. Try OXR on a page with a complex layout.
If you find a page where OXR's reading order breaks, please share it through our feedback form. Those are exactly the cases we want to learn from.
About OXR and SoMark
OXR is a 1.3B open-source document parsing model from the team behind SoMark. It ranks #1 on olmOCR-Bench, OmniDocBench, and DocParsingBench and delivers SOTA parsing speed. The model uses a recursive self-improvement (RSI) loop during post-training.
If OXR saves you time, give it a ⭐ on GitHub: https://github.com/SoMarkAI/OXR
Top comments (0)