![\"Larsen](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F2259646%2Ffafad76fe45d780addb95d2527520e80%2FLarsen_2002_p73_PyTesseract_blocks.png?generation=1771078654568517&alt=media\")
\n![\"AKT](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F2259646%2Fba6ef6d29fa4e3560cad9725e1feeba0%2FAKT_1_1990_p34_PyTesseract_blocks.png?generation=1771078674775408&alt=media\")
A public notebook on lighter/faster OCR of PDF docs is now live. Hopefully, this will make many of the documents more accessible.
\nThe biggest and heartful thanks to @mpware for starting a thread on OCR experiments with The Assur-nada Archive (Larsen 2002), sharing their results as a public dataset, starting the discussion (Any luck with letters from Larsen PDF?) and being an inspiration for using the GLM-OCR model. Without all of the above this work would not be possible.
\nThe notebook constitutes a minimum working example for anyone attempting to OCR the PDF documents for the Deep Past Challenge by using nothing more than a T4 machine provided by Kaggle. The code base was created with the help of Gemini 3 on Google Colab. It is not the cleanest, not the prettiest but I strived to make it leaner and faster than it would be for loading an entire page. Current output is pretty good and typically needs only a bit of manual work to be fully compliant.
\nThe GLM-OCR struggles to capture emphatic s (ṣ) and t (ṭ), and sometimes even vowels. It will typically use HTML tags for sub/superscripts (<sub></sub> and <sup></sup>) but may use LaTeX notation as well (e.g., $ gu_{5} $ for gu₅). It's also not consitent about it, so be on the lookout.
The OCR result is a list of translations for each block. This is intentional and is meant to be the most general to work with most PDF documents. In some cases like The Assur-nada Archive (Larsen 2002) the transliterations form a leftmost column, while translations for a right-most column. For such cases it is trivial to use the extracted block position metadata (saved to a metadata.csv file) to filter out the transliteration/translation blocks and re-arrange/join the text. It is not the case for the AKT series, for which the both transliterations and translations come after one another and occupy the full width (at least for AKT 1990; I have not checked all of them).
\n
Reconstructed text (left) compared with the original text (right). There are still some errors. but not too many. Sub/supersctipts formatted to the _/^ notation.\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F2259646%2F32bbc8a9204122a90a0426f5728df6c7%2F16.%20CCT%2032b%20-%20OCR-original%20comparison.png?generation=1771078863552481&alt=media\")
Good luck!
", "messages": [ { "id": "3406072", "postDate": "02/14/2026 14:24:46", "content": "A public notebook on lighter/faster OCR of PDF docs is now live. Hopefully, this will make many of the documents more accessible.
\nThe biggest and heartful thanks to @mpware for starting a thread on OCR experiments with The Assur-nada Archive (Larsen 2002), sharing their results as a public dataset, starting the discussion (Any luck with letters from Larsen PDF?) and being an inspiration for using the GLM-OCR model. Without all of the above this work would not be possible.
\nThe notebook constitutes a minimum working example for anyone attempting to OCR the PDF documents for the Deep Past Challenge by using nothing more than a T4 machine provided by Kaggle. The code base was created with the help of Gemini 3 on Google Colab. It is not the cleanest, not the prettiest but I strived to make it leaner and faster than it would be for loading an entire page. Current output is pretty good and typically needs only a bit of manual work to be fully compliant.
\nThe GLM-OCR struggles to capture emphatic s (ṣ) and t (ṭ), and sometimes even vowels. It will typically use HTML tags for sub/superscripts (<sub></sub> and <sup></sup>) but may use LaTeX notation as well (e.g., $ gu_{5} $ for gu₅). It's also not consitent about it, so be on the lookout.
The OCR result is a list of translations for each block. This is intentional and is meant to be the most general to work with most PDF documents. In some cases like The Assur-nada Archive (Larsen 2002) the transliterations form a leftmost column, while translations for a right-most column. For such cases it is trivial to use the extracted block position metadata (saved to a metadata.csv file) to filter out the transliteration/translation blocks and re-arrange/join the text. It is not the case for the AKT series, for which the both transliterations and translations come after one another and occupy the full width (at least for AKT 1990; I have not checked all of them).
\n
Reconstructed text (left) compared with the original text (right). There are still some errors. but not too many. Sub/supersctipts formatted to the _/^ notation.\n
Good luck!
", "rawMarkdown": "[A public notebook on lighter/faster OCR of PDF docs](https://www.kaggle.com/code/angantyr/text-extraction-from-pdf-docs-using-glm-oc) is now live. Hopefully, this will make many of the documents more accessible.\n\nThe biggest and heartful thanks to @mpware for starting a thread on OCR experiments with The Assur-nada Archive (Larsen 2002), sharing [their results as a public dataset](https://www.kaggle.com/datasets/mpware/dpc-larsen), starting the discussion ([Any luck with letters from Larsen PDF?](https://www.kaggle.com/competitions/deep-past-initiative-machine-translation/discussion/670040)) and being an inspiration for using the GLM-OCR model. Without all of the above this work would not be possible.\n\nThe notebook constitutes a minimum working example for anyone attempting to OCR the PDF documents for the [Deep Past Challenge](https://www.kaggle.com/competitions/deep-past-initiative-machine-translation/overview) by using nothing more than a T4 machine provided by Kaggle. The code base was created with the help of Gemini 3 on Google Colab. It is not the cleanest, not the prettiest but I strived to make it leaner and faster than it would be for loading an entire page. Current output is pretty good and typically needs only a bit of manual work to be fully compliant.\n\n### Known issues\nThe GLM-OCR struggles to capture emphatic s (ṣ) and t (ṭ), and sometimes even vowels. It will typically use HTML tags for sub/superscripts (`` and ``) but may use LaTeX notation as well (e.g., ` $ gu_{5} $ ` for `gu₅`). It's also not consitent about it, so be on the lookout.\n\n# Format\nThe OCR result is a list of translations for each block. This is intentional and is meant to be the most general to work with most PDF documents. In some cases like The Assur-nada Archive (Larsen 2002) the transliterations form a leftmost column, while translations for a right-most column. For such cases it is trivial to use the extracted block position metadata (saved to a `metadata.csv` file) to filter out the transliteration/translation blocks and re-arrange/join the text. It is not the case for the AKT series, for which the both transliterations and translations come after one another and occupy the full width (at least for AKT 1990; I have not checked all of them).\n## Input\n\n\n## Output\nReconstructed text (left) compared with the original text (right). There are still some errors. but not too many. Sub/supersctipts formatted to the _/^ notation.\n\n\nGood luck!", "votes": null }, { "id": "3406084", "postDate": "02/14/2026 15:03:17", "content": "This seems excellent! I appreciate your effort.
", "rawMarkdown": "This seems excellent! I appreciate your effort.", "votes": null }, { "id": "3406097", "postDate": "02/14/2026 15:44:46", "content": "Very good! I've started to work on AKT PDF files. I hope to get better results with Larsen and AKT as soon as Kaggle and the sponsor will annonce the rules about < gap > < big_gap >. It looks like that bad (or good) handling of them could lead to -+2 or 3 on LB. From what I've read on discord it should be next week.
", "rawMarkdown": "Very good! I've started to work on AKT PDF files. I hope to get better results with Larsen and AKT as soon as Kaggle and the sponsor will annonce the rules about < gap > < big_gap >. It looks like that bad (or good) handling of them could lead to -+2 or 3 on LB. From what I've read on discord it should be next week.", "votes": null }, { "id": "3406172", "postDate": "02/14/2026 21:38:32", "content": "Good news, everyone!
\nDue to a mistake on my end, I happened to verify that the notebook is able to work without a GPU.\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F2259646%2Ff66de8c226a96ba68689b438f22346ee%2FGLM-OCR%20working%20with%20no%20GPU.png?generation=1771105078994578&alt=media\")
This seems excellent! I appreciate your effort.
", "votes": null, "replies": [] }, { "id": 3406097, "author_name": "mpware", "author_url": "", "post_date": "02/14/2026 15:44:46", "content": "Very good! I've started to work on AKT PDF files. I hope to get better results with Larsen and AKT as soon as Kaggle and the sponsor will annonce the rules about < gap > < big_gap >. It looks like that bad (or good) handling of them could lead to -+2 or 3 on LB. From what I've read on discord it should be next week.
", "votes": null, "replies": [] }, { "id": 3406172, "author_name": "angantyr", "author_url": "", "post_date": "02/14/2026 21:38:32", "content": "Good news, everyone!
\nDue to a mistake on my end, I happened to verify that the notebook is able to work without a GPU.\n