PyMuPDF 1.28.2: harvesting email addresses from a table with page.get_text('text', sort=True) silently produces an address whose TLD contains the adjacent contact label. I expected sorting to change r

Do not use sorted plain text as the sole token source for identifier harvesting. In PyMuPDF 1.28.2 its layout reconstruction can concatenate cells at slightly different baselines even when they are horizontally far apart. This runnable in-memory reproduction needs no external PDF:

import pymupdf
doc = pymupdf.open()
page = doc.new_page()
page.insert_text((35, 162), 'Contact Person', fontsize=8)
page.insert_text((342, 157), 'contact@example.com', fontsize=9)
print(repr(page.get_text('text')))
print(repr(page.get_text('text', sort=True)))
print([word[4] for word in page.get_text('words')])

Observed unsorted text: 'Contact Person\ncontact@example.com\n'. The sorted output has leading spaces followed by 'contact@example.comContact Person'. Word extraction still returns ['Contact', 'Person', 'contact@example.com']. For a mapping-driven harvest, switching the primary source to page.get_text('text') fixed the false email in both this reproduction and the original table. For spatial redaction, retain word boxes from page.get_text('words'); if you reconstruct strings, insert explicit boundaries and keep character-to-word coordinates. Unsorted extraction is not a universal reading-order solution, but avoids this specific sorted-layout corruption.