Add a public API that gives the text of a file in reading order, for text-to-speech
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
Direzione di ricerca
Start by reading internal/html/pdf_file.cpp and the existing odr::internal::pdf::extract_text implementation, then inspect the public odr::PdfFile API and its Java binding. The issue proposes an API but leaves paragraph grouping, location representation, and list versus iterator design open. Done means decoded files expose text units in reading order with locations and no layout duplicates, through a JNI call per file or page.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Context
OpenDocument.droid reads documents aloud with Android text-to-speech. It gets the text from the rendered HTML, because the core has no public API for it. For PDFs, this failed (opendocument-app/OpenDocument.droid#725). The fix is in opendocument-app/OpenDocument.droid#731, but it depends on internal details of the PDF HTML:
- It reads the selection layer with the selector
.p > .sel. It must skip thearia-hiddenglyph layer (.vis), because both layers contain the text. - It joins the
textContentof the lines, because.phascontent-visibility:auto. A page off screen skips rendering, so itsinnerTextis empty.
If the core changes this HTML, text-to-speech in the app stops with no error.
What exists now
odr::internal::pdf::extract_textgives the text runs of a page. The HTML writer ininternal/html/pdf_file.cppgroups them into the lines of the.sellayer.- The public
odr::PdfFileand its Java binding have onlydecrypt,annotate,is_annotatable, and permissions. They have no text API. - For documents, Java can walk
Document.rootElement()and readText.content(). That walk needs one JNI call for each element. PDF has no element tree.
Proposal
Add a public API that gives the text of a decoded file as a list of units in reading order:
- A unit is a paragraph if the format has paragraphs. For a PDF, it is a block of lines that the core groups as a paragraph, or one page if the core cannot group the lines.
- Each unit has a location in the HTML, for example a page index and an element ID. The app needs the location to scroll to the unit and to highlight it while it reads. Without a location, the API is worse than the HTML route.
- The text has no layout duplicates: no hidden glyph layers, and no hyphens that only break a line.
- The API is available in the JNI binding as one call, or as one call for each page. It must not need one JNI call for each element.
Questions
- Can PDF paragraph grouping use the same code as the line grouping of the selection layer?
- Does an iterator for each page fit better than one list, for large PDFs?
- Can search and copy in the app use the same API later?
🤖 Generated with Claude Code
- Lingua principale
- C++
- Stelle
- 41
- Fork
- 10
- Merge medio
- 11h 27m
- PR unite (30g)
- 312
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di opendocument-app/OpenDocument.core
-
enhancement
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
opendocument-app/OpenDocument.core#1214 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
opendocument-app/OpenDocument.core#1211 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 42/100
opendocument-app/OpenDocument.core#1210 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
opendocument-app/OpenDocument.core#1209 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 38/100
opendocument-app/OpenDocument.core#1208 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di opendocument-app/OpenDocument.core
Issue simili
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
-
bug code-review testing tooling
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
aristocratos/btop#1945 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 79/100
boykopovar/AnyPS5#11291 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
k2-fsa/sherpa-onnx#4100 ·
I maintainer di solito rispondono entro 2 giorni