Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#1,279 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
42/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
cpp, css, html
Domaine
frontend, web-dev

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
C++
Étoiles
41
Forks
10
Merge moyen
10 h 30 min
PR mergées (30 j)
342

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de opendocument-app/OpenDocument.core

Toutes les issues de opendocument-app/OpenDocument.core

Issues similaires

Plus d'issues C++

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.