html

Attention over time

7-day rolling share of analyzed posts/comments mentioning this entity · 90 daily points ending 2026-08-28

Final complete day: 2026-08-28. Attention was 1.5% — this entity appeared in 39 of 2,594 analyzed posts/comments in the seven days ending that day (56 mentions).

Each point is a seven-day rolling window of complete UTC days; a point is comparable only when at least 100 analyzed posts or comments fall inside it. A day with no analyzed records counts as zero; missing coverage is marked and never shown as zero. The series ends at the latest complete analyzed day — it never extends into the current incomplete day. How attention is measured.

Recent mentions

1. 2026-08-28 23:16 UTCPost

   OSS: Convert PDF to HTML with 100% visual parity - I ran into two problems using unpdf and PDF.js in edge functions: RAM usage and visual accuracy. Both load the entire file into a byte array before processing. So I built a dependency-free, low-memory reader for edge workers: The trick was using PDFium as the reference renderer: I pulled down more than 100 test PDFs from various open-source projects and rendered them with PDFium. Then I converted each PDF to HTML, rendered that HTML in a browser, and compared the resulting pixels. I used deterministic pixel matching rather than a VLM, so visual regressions were reproducible. That led to a separation between two kinds of output: \- **Visual HTML** preserves the PDF’s presentation as closely as possible. \- **Semantic HTML** reflows the content into a simpler reading order. The visual representation came first because a PDF’s apparent reading order is encoded in its geometry. If you simplify too early, you lose the evidence needed to distinguish a table from a newspaper column or group an image with its caption. The reader uses HTTP range requests and bounded caches, so it can render the first page without downloading a huge document into memory. The semantic side is still evolving. It uses statistical layout evidence - font size, alignment, indentation, spacing, repeated headers, hanging indents, and page-to-page continuity. The goal is to produce simplified, reflowed, lossless HTML. Unfortunately there is no good "oracle" for this, or clear and obvious "correctness", other than "reading order must be correct". This is useful for LLMs and data extraction (and is the second reason I had to write this thing, aside from RAM). This is a follow up to my earlier low-memory PDF writer package (similar reasons there too), so the emerging package layout is: - @boxpdf/reader: streaming PDF → document model - @boxpdf/html-writer: document model → visual or semantic HTML - @boxpdf/writer: document model → PDF - @boxpdf/html-reader: HTML → document model The PDF-to-HTML accuracy became an ordinary testing problem once PDFium was treated as the oracle. Render both versions, compare the pixels, inspect the failure, improve the general rule. It’s early, but it now handles a pretty hostile corpus: embedded fonts, Type 3 glyphs, clipping paths, vector graphics, raster images, forms, rotations, tables, multi-column papers, and very large streamed documents. I’d be especially interested in difficult PDFs that break other converters. Weird fonts, charts, scanned documents, malformed files, enormous files - anything unpleasant makes a useful fixture.

2. 2026-08-28 16:18 UTCComment

   wget/HTTrack miss the JS-rendered bits because they never actually run the page. Snapshotting API JSON into the webroot (like the top comment) is the right move if your UI is a thin client over a few endpoints. If the HTML itself is assembled in JS, I'd also prerender: crawl the sitemap in a headless browser, wait for network idle, save the fully rendered HTML, then rewrite asset URLs so CSS/fonts/images are local. Quick check: after the crawl, open a couple of pages with JS disabled and see if the content is still there. If it isn't, you saved a shell, not a snapshot. Tradeoff is maintenance vs fidelity. JSON snapshots keep the original JS app working but you also keep whatever client-side bugs you already have. Full HTML snapshots are dumber and more portable, but you lose in-page interactivity unless you carefully keep the JS. For a backend you're shutting down, I'd prerender HTML and only freeze ./api JSON for the bits that still fetch at runtime.

3. 2026-08-28 16:17 UTCPost

   Kualo to Greengeeks - nameservers or redirects first? - Need serious help - migrating peer-reviewed journal - I'm at the end of my tether here. I'm singlehandedly trying to revamp an old custom html/php site (a peer-reviewed journal that's been running for a decade) hosted on Kualo and move it to GreenGeeks with a WP installation. The site is on a temporary domain (no SSL) and is basically finished. I got the domain transfer today. But I have no clue what I'm supposed to do next. I have 20 pages of notes. I know my way around plugins, CSS, etc. But I simply cannot figure out what order to do the major steps in... I'm genuinely exhausted. All I can do is give you these notes: * Let the domain transfer finish in the background (takes a few days). * Update Nameservers & SSL: * Update domain nameservers to point to GreenGeeks. * Turn on SSL certificate * Run Better Search Replace for all database urls * Set Up Redirects * SEO * Turn off maintenance plugin " 1. Point the nameservers to GreenGeeks. 1. Wait for ecologicalcitizen.net to reach your GreenGeeks site. 2. Get SSL working. 1. Make sure works properly. 3. Change WordPress to the real domain. 1. In Settings → General, change both WordPress Address and Site Address from the temporary URL to 2. You may be logged out; log back in using the new address. 4. Run Better Search Replace. 1. Use it for the remaining temporary-domain references and other internal URL/path changes in your database (PDFs, artwork, images, etc.). 2. You don't need it just to change the WordPress Address/Site Address. 5. Set up your 301 redirects. 1. Do this while Maintenance Mode is still ON. 2. This handles old URLs that have changed/disappeared, including the relevant old article, author and PDF URLs. 6. Check the site. 1. Make sure the new pages, images, PDFs, links, etc. work. 7. Go live. 1. Turn off Maintenance Mode. 2. Allow search engines to index the site. 8. Test old URLs. 1. Check that important old URLs redirect to their new destinations rather than producing 404s." I need to redirect thousands of URLs so I already have loads of rules written out in a document, with some idea what do for regex syntax... e.g., Regex: /what-is.php?... → /definitions/ This is blindingly complicated. I simply am beyond my capabilities here. I thought the above plan was fine, but it's not because apparently you can do the redirects first by using relative paths. Also, if you do nameserver changes first then surely everyone will get 404s. I seriously need help. This is a collossal task. In fact, if I can't do this, an entire journal dies, along with my livlihood.

4. 2026-08-28 14:27 UTCComment

   I use Puppeteer to wait for network idle then dump the DOM after hydration. This captures the JS rendered state that wget misses entirely. Save the full HTML including inline styles and base64 encoded assets to eliminate external dependencies. Run this against your sitemap before shutting down the backend so you get the exact current state without guessing at API responses.

5. 2026-08-28 13:55 UTCComment

   You can hook up a script or an LLM to a browser-based tool like Chrome Devtools MCP or Playwright, render a sitemap of your entire site. Have it loop through every page and write the HTML of each page in a folder based structure with static HTML files. Then deploy that static copy to GitHub Pages, change the DNS so the URL points to the GH pages and done. How many pages is this for? Hundreds/thousands, I would invest some time in a proper pipeline that automates this. If it's more like 25 then I would just do it manually. There's options like which lets you manually download a webpage with all images, CSS, fonts, etc.. included into 1 HTML file.