Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

pdf: search marks sit about three letters right of the hit in WebKit

Abierto
  • ¿Algo no está bien?
#1,279 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
42/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
cpp, css, html
Área
frontend, web-dev

Línea de trabajo

Start by reproducing the search in Safari or the iOS simulator, then compare the computed font for the .sr run with Chrome and measure its mark against the .vis glyphs. The issue identifies the .sr and .vis runs but names no source files or tests. Done means the highlight aligns with the searched text in WebKit and no longer obscures the letters beneath it.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Found by the iOS session while it moved OpenDocument.ios to 7.6.0 (opendocument-app/OpenDocument.ios#219). iPhone 18 Pro simulator, iOS 27.0, default dual layer.

Repro:

  1. Make the file: soffice --headless --convert-to pdf book.txt, where book.txt holds 60 chapters of 39 lines like "This is line 1 of chapter 3. The quick brown fox jumps over the lazy dog."
  2. Search chapter 3.

What happens: the count is right (440 in that file), and the search reaches pages that have not loaded. But each yellow mark covers "pter 3. ", not "chapter 3": it starts about three characters late and runs past the end. Page 1 shows it too, so lazy loading is not the cause. The marks are opaque, so they also hide the letters they cover.

What I measured in Chrome: the mark is where it belongs. In the 38-page file, the first "chapter 1" mark starts at x=230, and the monospaced visible text puts that word at about 229. The .sel run is <span class="sr f0 w1">. It sets its text in the substitute face sf, sans-serif and stretches the run to the PDF's width (w1). So a character's place in the run depends on the metrics of the substitute font. My guess: in WebKit that face resolves to another font, or WebKit treats one of its descriptors differently, so positions drift within the run. Not checked in WebKit yet.

To do:

  • Measure the mark against the .vis glyphs in WebKit (Safari or the simulator).
  • Compare the computed font of the .sr run in WebKit and Chrome.
  • Then fix the metrics, or position the mark from the visible glyphs.
  • Separately: the highlight could be translucent, or mix-blend-mode: multiply, so it never hides the text below it.

Not compared with 7.5.2: there, the same search did not jump to a hit at all.

Lenguaje dominante
C++
Estrellas
41
Forks
10
Merge medio
10 h 30 min
PR fusionados (30 d)
342

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

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de opendocument-app/OpenDocument.core

Todos los issues de opendocument-app/OpenDocument.core

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.