Add a public API that gives the text of a file in reading order, for text-to-speech
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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
- Lenguaje dominante
- C++
- Estrellas
- 41
- Forks
- 10
- Merge medio
- 11 h 27 min
- PR fusionados (30 d)
- 312
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de opendocument-app/OpenDocument.core
-
enhancement
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
opendocument-app/OpenDocument.core#1214 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
opendocument-app/OpenDocument.core#1211 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 3/5 1-2 días Aptitud para principiantes 42/100
opendocument-app/OpenDocument.core#1210 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 3/5 1-2 días Aptitud para principiantes 45/100
opendocument-app/OpenDocument.core#1209 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 4/5 3-5 días Aptitud para principiantes 38/100
opendocument-app/OpenDocument.core#1208 ·
Los mantenedores suelen responder en 1 día
Todos los issues de opendocument-app/OpenDocument.core
Issues similares
-
bug IO
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
MrNeRF/LichtFeld-Studio#3824 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
-
bug code-review testing tooling
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
aristocratos/btop#1945 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 79/100
boykopovar/AnyPS5#11291 ·
Los mantenedores suelen responder en 1 día