IndexOutOfBoundsException in FopGlyphProcessor when shaping Thai characters (Complex Scripts)
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 45/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Estancado
- Stack tecnológico
- java
- Área
- backend, internationalization
Línea de trabajo
Start by reading FopGlyphProcessor.convertToBytesWithGlyphs and trace how FOP's CharAssociation maps shaped glyphs to source characters. Reproduce the Thai Sara Am case with FOP 2.11, then check that glyphs map to their original characters without an index error. The report names no test file, so locate or add a regression test for this case.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Describe the bug
I found a bug in FopGlyphProcessor when rendering Thai language with FOP support enabled. The application crashes with IndexOutOfBoundsException because the processor assumes a 1:1 mapping between characters and glyphs.
To Reproduce
When rendering Thai characters like "ำ" (Sara Am), the FOP shaping engine decomposes one character into two glyphs (Nikkhahit + Lak Khang).
The current loop in FopGlyphProcessor.convertToBytesWithGlyphs iterates based on the glyph count but tries to access the charBuffer using the same index:
for (int i = 0; i < limit; i++) {
// ...
longTag.put(glyphCode, new int[]{..., charBuffer.get(i)}); // This throws Exception when limit > charBuffer size
}
Expected behavior
The processor should handle cases where the number of glyphs is greater than the number of characters by correctly mapping glyphs back to their original source characters using FOP's CharAssociation.
Screenshots
System
OpenPDF version: 3.0.0
FOP version: 2.11
Language: Thai
- Lenguaje dominante
- Java
- Estrellas
- 4.4k
- Forks
- 714
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
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 LibrePDF/OpenPDF
-
Bump brotli4j to 1.24.0Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
IndexOutOfBoundsException in PdfReaderPosiblemente ocupada @andreasrosdalw la tomó hace 95 días. Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
`PdfSmartCopy` can take effectively unbounded time on nested shared Form XObjectsPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abiertobug
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
-
enhancement
Dificultad 5/5 Más de una semana Aptitud para principiantes 38/100
Todos los issues de LibrePDF/OpenPDF
Issues similares
-
status: waiting-for-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
spring-projects/spring-framework#37614 ·
Los mantenedores suelen responder en 1 día
-
azure-spring azure-spring-aad Client
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Azure/azure-sdk-for-java#51046 · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
helm-knative-apply.sh fails with Helm 4Posiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abiertoarea: triage theme: undefined
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
jhipster/generator-jhipster#35895 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
oracle/graalvm-reachability-metadata#11659 ·
Los mantenedores suelen responder en 1 día