fix(html): a selection no longer paints the pdf's hidden text layer - #907
Merged
Merged
Conversation
A pdf view draws its glyphs in one layer and keeps the real Unicode in another, which is `color:transparent` so that it can be selected and copied without being seen. A browser paints selected text in the highlight's own foreground colour, and that overrides `transparent`: as soon as the reader selected anything, the hidden glyphs appeared on top of the drawn ones, in a substitute font and at their own advances. The invisible classes now state `color:transparent` for `::selection` too, so a selection paints its background and nothing else. This covers the dual layer's `.i`, the single layer's `.i`, `.ov` and `.sp`, and the per-font `.fnN` an embedded font's invisible run carries. Checked in chromium, and against the Android app's WebView on a pdf whose hidden layer was visible before. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FJJdfqpnVCKBNHXjAVxSou
`::selection` matches the element that paints the text, not its ancestors. In the single layer `.i` and `.fnN` sit on the line block, so a run that carries a `margin-left` span, and a `mark` inside `.ov` or `.sp`, kept the highlight's own colour. The rules now take the descendants too, as the dual layer's `.i *::selection` already did. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0149gFxhkvKTBQidz6brU8Vt
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A pdf view draws its glyphs in one layer and keeps the real Unicode in another, which is
color:transparentso that it can be selected and copied without being seen. A browser paints selected text in the highlight's own foreground colour, and that overridestransparent: as soon as the reader selects anything, the hidden glyphs appear on top of the drawn ones, in a substitute font and at their own advances.The invisible classes now state
color:transparentfor::selectiontoo, so a selection paints its background and nothing else..i(and its run spans).i,.ovand.sp.fnNthat an embedded font's invisible run carriesHow it was found
Reported against the Android app: selecting text in a pdf makes a second, offset copy of the words appear. Measured in the app's WebView, and reproduced in chromium with a two-layer page - one box with the rule and one without.
Nothing renders differently, so the reference output is unchanged.