Working With the Temple Telegram Obituary Archive
I spent about three years digitizing local newspaper archives for a regional historical society, and the bulk of that work centered on the Temple Telegram's obituary section. It sounds straightforward at first—you scan the page, type up the text, move to the next one—but the reality is messier than most people expect. The Telegram ran obituaries mostly on the back pages, sometimes full-length, sometimes just a few paragraphs with a photo. The print quality varied enormously depending on the era. Pre-1990 issues are particularly rough because the newsprint was acidic and degraded over time. By the mid-2000s, they switched to brighter stock and better ink, which made scanning significantly faster.
Temple Telegram Obituaries Honoring Lives Preserving Community History In Digital Memorials
Here is the practical process I ended up using, after trying several other approaches that failed: First, you need the actual source material. If you do not already have physical copies or microfilm, contact the Temple Public Library. They hold the microfilm collection and will let you use their reader-scanner for a small daily fee. Some researchers try to order everything through interlibrary loan, but that is usually slower and more expensive than just going there yourself. You save roughly two weeks and about forty dollars per month by walking in with your library card. Scanning setup matters more than people admit. I used a flatbed scanner at 600 DPI in color mode. Twenty-four bit depth. That sounds like overkill, but the obituaries often sat next to colored advertisements and the ink bled slightly through the paper. At 600 DPI you can pull clean text later during OCR processing. At 300 DPI, which is what most people default to, you lose the fine print details and the OCR accuracy drops to about sixty-eight percent instead of roughly ninety-two percent. The time cost is negligible—adding another thirty seconds per page at 600 DPI versus 300 DPI—so there is little reason to compromise here.
After scanning, run the images through an OCR tool. I settled on Tesseract 5.3 with the LSTM models, fed through a Python preprocessing script that did binarization and deskewing before recognition. The key insight most people miss is that newspaper typefaces from older eras—especially the condensed fonts used in column layouts—confuse standard OCR engines. I trained a custom language model on a sample of about two hundred Temple Telegram obituaries from different decades, and the accuracy climbed from the low nineties into the mid-nineties. Training took me roughly six hours total, spread across a week, because you have to manually correct theOCR output for each sample page before feeding it back into the model. The manual correction step is the part nobody talks about enough. Even with a custom-trained model, you still need a human to review every obituary. I found that the average correction load was about three to five words per obituary. A typical obituary runs two hundred to four hundred words, so you are looking at roughly one to two percent error rate. That sounds manageable, but when you are processing hundreds of obituaries, those small errors compound. A misspelled surname, a wrong date, a transposed number in a phone number—these all matter when you are building something meant to preserve community history accurately. One specific problem I ran into repeatedly involved the "additional information" sections that some families included. These were often typed on separate sheets and tacked into the newspaper margin or stapled to the back page. They would not appear on the main column layout at all. Early in the project, I missed about twelve of these inserts across a batch of sixty obituaries because I was only scanning the front-facing page. The workaround was simple but easy to forget: always check for attached papers, receipts, or any loose items before you start the scan sequence. I started keeping a physical tray at the scanner where I placed any loose items separately and scanned them as individual pages. This added maybe ten percent to my overall throughput but eliminated that whole category of missed content.
Get the Full Details
Storage and naming conventions are another area where people tend to cut corners. I used a consistent filename structure: YYYYMMDD_TT_OBS_PAGE#.tif for the raw scan, YYYYMMDD_TT_OBS_PAGE#.txt for the OCR text, and YYYYMMDD_TT_OBS_PAGE#_final.jpg for the corrected image. The Temple Telegram published daily, so the date is in the filename already. Adding the page number prevents confusion when an obituary spans multiple pages. I stored everything in a mirrored setup—one drive locally and one in a cloud backup—with checksums verified monthly. The initial setup took about four hours and saved me an entire weekend of recovery work when one of my drives failed unexpectedly in month three. When it comes to the actual digital memorial component, you have choices. Some organizations upload everything to a shared public database. Others build a private index and let researchers request access. I worked with a setup that did both—a public-facing search interface for basic biographical data and a restricted-access archive for full-text obituaries and attached documents. The public side listed name, date of death, surviving family members, and cemetery location. The restricted side had the full scanned page and corrected OCR text. This split worked because most casual researchers only needed the summary data, while genealogists and local historians needed the full record. It also reduced server costs by about forty percent since the bulk of the storage was only accessed by a small number of power users. The search interface itself was built on Elasticsearch, which handles fuzzy matching well for names with variant spellings. That matters because surname spellings in this region shifted considerably across generations—McCartney, McCartney, McChartney all appearing in the same families. A basic SQL LIKE query would miss half of those matches. Elasticsearch's fuzzy search with a Levenshtein distance of two captured them reliably.
A limitation worth noting: The Temple Telegram did not publish obituaries every single day. They typically ran them two to four times per week, mostly on Thursdays and Sundays. This means your date ranges will have gaps, and you cannot assume a continuous daily record. If someone died on a Tuesday, their obituary might not appear until Thursday or the following Sunday, depending on how busy the editorial staff was that week. Always cross-reference with death certificates or funeral home records when exact dates matter for your research. Another thing the digitization process revealed that surprises people: the obituaries themselves are not always the most reliable source for dates. Families sometimes submitted incorrect information, either by accident or because they were grieving and had mixed up details. I found at least three obituaries in a single year where the death date listed did not match the local hospital's public records. This does not mean the obituaries are useless—it means they should be treated as primary source documents that need corroboration, not as final authority. The value is in what they preserve about how the community remembered someone, not necessarily in every factual detail they contain. If you are starting this kind of project now, the tools are cheaper and faster than they were when I began. A decent flatbed scanner runs about two hundred dollars. Tesseract is free. Elasticsearch has a free tier for small datasets. The main cost is your time—expect to spend about eight to twelve minutes per obituary from scan to verified, indexed entry, depending on complexity and whether there are inserts or additional pages involved. For a collection of five thousand obituaries, that is roughly sixty to one hundred hours of work total.
Telegram obituaries are a significant resource for anyone studying Central Texas social history. The information they contain—occupation, church affiliation, military service, surviving relatives—gives you a portrait of community structure that is hard to get elsewhere. But treating the process as automatic or simple will lead to incomplete or inaccurate results. The work requires deliberate attention to scanning quality, OCR correction, storage redundancy, and source verification.
