Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#1,279 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
42/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
cpp, css, html
Ambito
frontend, web-dev

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
C++
Stelle
41
Fork
10
Merge medio
10h 30m
PR unite (30g)
342

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di opendocument-app/OpenDocument.core

Tutte le issue di opendocument-app/OpenDocument.core

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.