Upgrade StorageRead Aloud speaks invisible text in arXiv PDFs (embedded LaTeX equation source)
Zotero 10.0.2-beta.1, Windows 11.
Read Aloud speaks text that is present in a PDF's text layer but drawn so that it cannot be seen. This is common in arXiv preprints: many LaTeX toolchains embed the source of each equation into the text layer so that it can be copied. In the extracted text each one begins with an angle-bracketed "latexit" tag and is followed by a few thousand characters of base64:
latexit sha1_base64="qQMnvb8XIEx0lTFxXVL9hX3DKns=" ... AAAB6HicbVBNS8NAEJ3Ur1q/qh69...
None of it is visible on the page, but Read Aloud reads it out - several minutes of base64, spelled character by character.
REPRODUCING
1. Open the PDF of arXiv:2003.01176 (Nagpal et al., "Deep Survival Machines"). Any arXiv PDF whose extracted text contains "latexit" will do.
2. Start Read Aloud and let it reach the equations, roughly a fifth of the way in.
3. It begins spelling out base64.
WHAT THOSE RUNS LOOK LIKE IN THE TEXT LAYER
font-size: 0px
color: rgba(0, 0, 0, 0)
box: 0 x 0
There are hundreds of such spans in that one paper. The PDF is fine and pdf.js reproduces it faithfully - the text really is drawn invisibly - so it looks like Read Aloud's segmentation could simply skip runs that have no rendered extent.
A SECOND EFFECT: VERY LARGE SINGLE SEGMENTS
The embedded source is one long run with no sentence punctuation, so it becomes a single Read Aloud segment. In that paper:
- longest ordinary sentence: 618 characters
- the five invisible runs: 2305, 4550, 4841, 4947 and 4980 characters
A 4980-character segment is about twelve minutes of speech in one unit, so skipping by sentence does not get past it quickly. The highlight position for that single segment also consists of 4951 separate rectangles, which seems like a lot to hand the page renderer at once.
SUGGESTION
Dropping text with a zero-area glyph box (and, more generally, text rendering mode 3) when Read Aloud builds its segments would remove this entirely. A cap on segment length might be worth having independently of it.
Read Aloud speaks text that is present in a PDF's text layer but drawn so that it cannot be seen. This is common in arXiv preprints: many LaTeX toolchains embed the source of each equation into the text layer so that it can be copied. In the extracted text each one begins with an angle-bracketed "latexit" tag and is followed by a few thousand characters of base64:
latexit sha1_base64="qQMnvb8XIEx0lTFxXVL9hX3DKns=" ... AAAB6HicbVBNS8NAEJ3Ur1q/qh69...
None of it is visible on the page, but Read Aloud reads it out - several minutes of base64, spelled character by character.
REPRODUCING
1. Open the PDF of arXiv:2003.01176 (Nagpal et al., "Deep Survival Machines"). Any arXiv PDF whose extracted text contains "latexit" will do.
2. Start Read Aloud and let it reach the equations, roughly a fifth of the way in.
3. It begins spelling out base64.
WHAT THOSE RUNS LOOK LIKE IN THE TEXT LAYER
font-size: 0px
color: rgba(0, 0, 0, 0)
box: 0 x 0
There are hundreds of such spans in that one paper. The PDF is fine and pdf.js reproduces it faithfully - the text really is drawn invisibly - so it looks like Read Aloud's segmentation could simply skip runs that have no rendered extent.
A SECOND EFFECT: VERY LARGE SINGLE SEGMENTS
The embedded source is one long run with no sentence punctuation, so it becomes a single Read Aloud segment. In that paper:
- longest ordinary sentence: 618 characters
- the five invisible runs: 2305, 4550, 4841, 4947 and 4980 characters
A 4980-character segment is about twelve minutes of speech in one unit, so skipping by sentence does not get past it quickly. The highlight position for that single segment also consists of 4951 separate rectangles, which seems like a lot to hand the page renderer at once.
SUGGESTION
Dropping text with a zero-area glyph box (and, more generally, text rendering mode 3) when Read Aloud builds its segments would remove this entirely. A cap on segment length might be worth having independently of it.