| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| provenance:programming:crawler:pagegraph [2026/09/22 04:19] – Quote-check refresh 2026-09-22: report_pagegraph.mjs gains the pypdf fallback; re-run gives 0 rescued, figures unchanged; embedded output regenerated; below-threshold cause corrected (PDF line-break hyphen, not column repair). Authored by Claude karel.kubicek.claude | provenance:programming:crawler:pagegraph [2026/09/22 04:33] (current) – Figures-vs-script finding accepted: report_pagegraph.mjs's hardcoded 'Manual follow-up' string still asserted the retracted column-repair cause; corrected in the script and the embedded block regenerated from the re-run. Authored by Claude karel.kubicek.claude |
|---|
| The below-threshold quote is the WebREC sentence “Our approach builds on an existing Chromium-based measurement system called PageGraph”. It is present in the source paragraph; both stored renderings join ''Chromium-based'' as ''Chromiumbased'', so the automated matcher reports 29% rather than exact support. I checked the surrounding paragraph manually. It is a rendering mismatch, not an unsupported quote. | The below-threshold quote is the WebREC sentence “Our approach builds on an existing Chromium-based measurement system called PageGraph”. It is present in the source paragraph; both stored renderings join ''Chromium-based'' as ''Chromiumbased'', so the automated matcher reports 29% rather than exact support. I checked the surrounding paragraph manually. It is a rendering mismatch, not an unsupported quote. |
| |
| **The ''pypdf'' fallback added on 2026-09-22 does not rescue it, and the reason corrects this page's own earlier diagnosis.** The re-run scores the quote at the identical 29% — 2 of its 7 five-word windows — against ''paper.cols.txt'' and against ''pypdf'''s rendering of the same ''paper.pdf''. The cause is not the two-column repair. The raw ''paper.txt'' dump shows the word broken across a line in the PDF itself: | **The ''pypdf'' fallback added on 2026-09-22 does not rescue it, and the reason corrects this page's own earlier diagnosis.** The re-run scores the quote at the identical 29% — 2 of its 7 five-word windows — against ''paper.cols.txt'' and against ''pypdf'''s rendering of the same ''paper.pdf''. The cause is not the two-column repair. Lines 343–345 of the raw ''paper.txt'' dump, **verbatim and with the two columns still interleaved as that file stores them**, show the word broken across a line in the PDF itself. The right-hand column is the passage; the left-hand column is unrelated text from the facing column: |
| |
| <code> | <code> |
| Chromium. Our approach builds on an existing Chromium- | And second, .web is general, allowing it to generate Chromium. Our approach builds on an existing Chromium- |
| based measurement system called PageGraph, which has been | archives to support reproducible studies beyond what exist- based measurement system called PageGraph, which has been |
| | ing common measurement tools and archive formats allow. used in prior work [9, 58, 59]. PageGraph comprehensively |
| </code> | </code> |
| | |
| | Read the right-hand column alone: ''%%Chromium-%%'' ends line 343 and ''based'' begins line 344. |
| |
| Every renderer strips a hyphen at a line break, because that is what a line-break hyphen usually is — and here it is a **real** hyphen in a real compound word. ''.cols'' and ''pypdf'' therefore produce the same wrong token, and no second rendering of this PDF can recover it. The matcher's own de-hyphenation only fires on ''%%-%%'' followed by whitespace, so it does not fold the needle to match. This is a class of below-threshold quote the PDF fallback is structurally unable to help with, and it is recorded rather than engineered around: widening the fold to strip every intra-word hyphen would make the matcher accept quotes it should not. See //Quote-check refresh, 2026-09-22// at the foot of this page. | Every renderer strips a hyphen at a line break, because that is what a line-break hyphen usually is — and here it is a **real** hyphen in a real compound word. ''.cols'' and ''pypdf'' therefore produce the same wrong token, and no second rendering of this PDF can recover it. The matcher's own de-hyphenation only fires on ''%%-%%'' followed by whitespace, so it does not fold the needle to match. This is a class of below-threshold quote the PDF fallback is structurally unable to help with, and it is recorded rather than engineered around: widening the fold to strip every intra-word hyphen would make the matcher accept quotes it should not. See //Quote-check refresh, 2026-09-22// at the foot of this page. |
| IEEE-SP/2021/detecting-filter-list-evasion-with-event-loop-turn-granularity-javascript-signat | PageGraph | methodology | partial (72%) | "To solve this problem, we used and extended PageGraph, a system for representing the execution of a page as a directed graph." | IEEE-SP/2021/detecting-filter-list-evasion-with-event-loop-turn-granularity-javascript-signat | PageGraph | methodology | partial (72%) | "To solve this problem, we used and extended PageGraph, a system for representing the execution of a page as a directed graph." |
| Summary: 9 quotes checked: 5 exact, 3 partial (>=60% of 5-word windows), 0 rescued from the PDF, 1 below threshold in both renderings, 0 without full text. | Summary: 9 quotes checked: 5 exact, 3 partial (>=60% of 5-word windows), 0 rescued from the PDF, 1 below threshold in both renderings, 0 without full text. |
| Manual follow-up: the below-threshold WebREC quote is present in the source rendering at the PageGraph paragraph; the repaired .cols text joins "Chromium-based" as "Chromiumbased", which defeats the normalised quote matcher. It is a column-repair mismatch, not an unsupported claim. | Manual follow-up: the below-threshold WebREC quote is present in the paper at the PageGraph paragraph; raw paper.txt breaks "Chromium-" at the end of a line and resumes with "based", so BOTH paper.cols.txt and the pypdf rendering join it as "Chromiumbased" and the normalised quote matcher scores 29% against each. It is a line-break-hyphen mismatch in the PDF text layer, not a column-repair artefact and not an unsupported claim; no second rendering can rescue it. |
| </file> | </file> |
| |
| against the published block found **no other line had moved** — the population query, | against the published block found **no other line had moved** — the population query, |
| the year table, the role fold and the four source facts all reproduce byte-for-byte. | the year table, the role fold and the four source facts all reproduce byte-for-byte. |
| No figure outside the quote section was touched, and no ''{[citekey]}'' was added or moved. | No figure outside the quote section was touched, and no ''%%{[citekey]}%%'' was added or moved. |
| |
| ^ Item ^ Value ^ | ^ Item ^ Value ^ |
| | Script change | ''scripts/report_pagegraph.mjs'': imports ''pdfText'' from ''scripts/pdftext_cache.mjs''; a below-threshold verdict is re-scored against the ''pypdf'' rendering and reported as ''rescued'' at ≥60%; the summary line gained a rescued bucket | | | Script change | ''scripts/report_pagegraph.mjs'': imports ''pdfText'' from ''scripts/pdftext_cache.mjs''; a below-threshold verdict is re-scored against the ''pypdf'' rendering and reported as ''rescued'' at ≥60%; the summary line gained a rescued bucket | |
| | Positive control | the fallback was confirmed live, not assumed: ''scripts/pdftext.py'' returns 98,886 characters for the WebREC paper and the same 2-of-7 window hits, so the 0 is a measured zero and not a silently-failed subprocess | | | Positive control | the fallback was confirmed live, not assumed: ''scripts/pdftext.py'' returns 98,886 characters for the WebREC paper and the same 2-of-7 window hits, so the 0 is a measured zero and not a silently-failed subprocess | |
| | Reviewers | one ''sonnet'' figures-vs-script pass | | | Reviewers | one ''sonnet'' figures-vs-script pass, one ''sonnet'' citations pass | |
| | | Reviewer finding accepted | The figures-vs-script pass caught that ''report_pagegraph.mjs'' still carried the **retracted** explanation in a hardcoded string: its "Manual follow-up" line said //"It is a column-repair mismatch"//, so every re-run reproduced a debunked causal claim underneath the prose that had retracted it. The string is now corrected **in the script**, not on the page, and the embedded block regenerated from the re-run. A figure can be corrected in prose and survive inside the published output that is supposed to prove it | |
| | | Reviewer finding accepted | The citations pass caught that the ''paper.txt'' excerpt first published here was **not verbatim**: it had been de-interleaved by hand, so grepping ''paper.txt'' for those two lines returns nothing at all. The real three lines are now published with both columns intact, read straight out of the file rather than retyped. The //claim// was right — the hyphen is a line break in the PDF's own text layer — but an excerpt presented as a raw dump has to be a raw dump. Fixed the same day | |
| | Pages saved | this page and [[:programming:crawler:pagegraph]] | | | Pages saved | this page and [[:programming:crawler:pagegraph]] | |
| |
