Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#1,279 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
42/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
cpp, css, html
Bereich
frontend, web-dev

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
C++
Sterne
41
Forks
10
Ø Merge
10 Std. 30 Min.
Gemergte PRs (30 T.)
342

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus opendocument-app/OpenDocument.core

Alle Issues in opendocument-app/OpenDocument.core

Ähnliche Issues

Weitere Issues zu C++

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.