DEV Community: shaojie gong

A complete NotebookLM research workflow

shaojie gong — Fri, 06 Nov 2026 13:07:39 +0000

Research tools become difficult to use when collection, organization, citation and study are treated as one giant feature.

The first stage is Collect. Bring source links into a notebook and check what NotebookLM was able to load. The second stage is Organize. Use predictable notebook names, folders, tags and saved records so useful material can be found later.

The third stage is Cite. Export structured source information for Zotero or generate APA, MLA, Chicago and BibTeX references, then verify the metadata. The fourth stage is Study. Export selected flashcards to Anki while preserving the source on each card.

Each stage has a visible result: a source list, an organized saved record, a verified citation or an Anki deck. That makes the workflow easier to debug and easier to learn.

NotebookBloom brings these actions into one panel, but the operating rule stays simple: finish one useful job before opening the next tab.

Practical checklist

Use a public or non-sensitive notebook for the first test. Verify the output before deleting the intermediate file, and keep the product limitation visible.

Resizing images on a canvas without jagged edges: halving steps, fit-to-box math and Safari's canvas limit

shaojie gong — Fri, 06 Nov 2026 02:09:50 +0000

I build MakeQuickWork, a small set of free browser tools, on my own. This post is about the Resize Image tool and the three things that took longer than the resize itself.

Resizing an image in the browser looks like one call: draw the image onto a smaller canvas with drawImage. That works, and on a big photo it also looks bad. The edges go jagged and fine texture turns into noise.

Getting it to look right took one loop. Most of the rest of the time went into the size fields: what "keep aspect ratio" should mean when someone enters both a width and a height, and how big a canvas a phone will actually agree to create.

The tool is here: https://makequickwork.com/image/resize-image/. Everything runs in the tab. The image is decoded, resized and encoded locally, and the result is a normal download.

Decoding: let the browser rotate it

Phone photos are often stored sideways with an EXIF Orientation tag. If you ignore it, a portrait photo comes out lying down. createImageBitmap can apply it for you:

const bmp = await createImageBitmap(file, { imageOrientation: "from-image" });

HEIC is the exception. Safari decodes it natively; Chrome, Edge and Firefox don't. So the decoder tries createImageBitmap first and falls back to libheif compiled to WebAssembly, which is only downloaded the first time someone actually opens a HEIC file. The page itself loads about 11 KB of JavaScript.

Downscaling: halve, then finish

A single drawImage from 3200 px wide to 1080 px samples too few source pixels per output pixel, and the result aliases. Raising imageSmoothingQuality to "high" helps, but browsers differ in how much. Halving repeatedly until the next halving would undershoot, and doing the last step at the exact size, gives consistently clean results:

/** Resizes with repeated halving, which stays sharp where a single large downscale gets jagged. */
export function resize(src: HTMLCanvasElement, width: number, height: number) {
  let cur = src;
  while (cur.width / 2 >= width && cur.height / 2 >= height) {
    const half = newCanvas(cur.width / 2, cur.height / 2);
    const ctx = half.getContext("2d")!;
    ctx.imageSmoothingQuality = "high";
    ctx.drawImage(cur, 0, 0, half.width, half.height);
    if (cur !== src) cur.width = cur.height = 0; // free the intermediate
    cur = half;
  }
  const out = newCanvas(width, height);
  const ctx = out.getContext("2d")!;
  ctx.imageSmoothingQuality = "high";
  ctx.drawImage(cur, 0, 0, width, height);
  if (cur !== src) cur.width = cur.height = 0;
  return out;
}

Setting width = height = 0 on canvases you're done with matters more than it looks. On iOS, canvas memory is tight and isn't always released promptly, so a batch of large photos can fail halfway if intermediates hang around.

Enlarging goes through the same function. The loop simply doesn't run, and you get a single high-quality drawImage. It's allowed, but it can't invent detail. More on that below.

"Keep aspect ratio" means a box

This was the design question I spent the most time on. If keep-ratio is on and someone types width 1080 and height 1080 for a 4:3 photo, there are three reasonable answers: crop to a square, stretch to a square, or fit inside the square. I picked fit. Width × height is a box, and the image is scaled by the smaller of the two factors:

const sx = o.width > 0 ? o.width / w : Infinity;
const sy = o.height > 0 ? o.height / h : Infinity;
const s = Math.min(sx, sy);
if (!Number.isFinite(s)) throw new Error("Enter a width or a height.");

An empty field becomes Infinity, so leaving the height blank means "width 1080, height whatever it needs to be". It also makes batches behave: a landscape and a portrait image in the same 1080 × 1080 box each keep their own proportions. There is no cropping anywhere in the tool. If you need an exact size, turn keep-ratio off and the image is stretched to it.

The width and height fields are prefilled from the first image's dimensions, and while keep-ratio is on, typing one side recalculates the other from that image's ratio. That way the numbers you see always match what the first image will become.

The canvas size ceiling

iPhone Safari refuses to create canvases above roughly 16 megapixels. It doesn't throw a helpful error; you just get a blank image. So every target size is clamped before anything is drawn:

const s = Math.min(1, MAX_SIDE / tw, MAX_SIDE / th, Math.sqrt(16_000_000 / (tw * th)));

With MAX_SIDE = 16_000, output stays within 16,000 px per side and about 16 MP total in every browser. If you ask for 8000 × 6000, you get less than that, scaled down proportionally. I'd rather be honest about the limit than have the tool work on a desktop and silently fail on a phone.

Encoding and the batch

JPG and WebP are saved at 92% quality; PNG stays lossless. WebP needs a detour: Safari's canvas.toBlob can't write WebP, so WebP output goes through libwebp compiled to WebAssembly in every browser. Multiple results are zipped with fflate. Output names carry the size, like photo-1080x720.jpg, so a folder of exports stays readable.

EXIF doesn't survive the round trip through a canvas, so GPS location and camera details are gone from the output. For most uses that's a bonus, but if you need the metadata, keep the original.

What it looks like on real files

On my test images, with width 1080, height empty and keep-ratio on:

beach-sunset.jpg: 3200 × 2400, 2.9 MB → 1080 × 810, 68.8 KB, saved as beach-sunset-1080x810.jpg
receipt.jpg: 900 × 1200, 41.3 KB → 1080 × 1440, 63.8 KB

The second one is the case I want to point out. The receipt was narrower than 1080, so the box enlarged it. The file got bigger and the text got slightly softer, because upscaling interpolates pixels; it doesn't recover anything. If you only want to shrink, check the source dimensions first or use the percentage mode.

How I check nothing is uploaded

The site is static (Astro on Cloudflare Pages), and there is an automated test that processes a file in every tool and fails on any POST, or any third-party request other than Google Analytics, during processing. It also fails if an analytics event contains a file name. You can verify it yourself in the DevTools Network tab. You do need a connection to load the page and the WebAssembly modules.

If you've solved the downscale problem a different way on canvas, or think crop-to-fill should be an option next to fit, I'd like to hear about it in the comments.

Bulk-import playlists, channels, RSS and links

shaojie gong — Thu, 05 Nov 2026 12:26:51 +0000

Bulk import is useful when the input already has structure: a YouTube playlist, a channel, an RSS feed or a prepared list of links.

Open the target NotebookLM notebook first. Choose the matching import mode, paste the URL or list, and start with a small batch. This makes it easier to see whether the source type is supported before reaching a notebook limit.

After import, inspect the final source list. A video may appear without useful text when no transcript is available. A private or restricted page may fail. A large playlist can exceed the remaining source capacity.

The result should show how many sources were imported and how many failed. A silent partial import is harder to correct than an explicit failure count.

NotebookBloom automates the repeated Add source steps. It does not remove NotebookLM's own source limits or guarantee that every external page exposes usable content.

Practical checklist

Use a public or non-sensitive notebook for the first test. Verify the output before deleting the intermediate file, and keep the product limitation visible.

My 100 KB image compressor produced 36 KB files. The bug was using a different encoder to search.

shaojie gong — Thu, 05 Nov 2026 02:15:09 +0000

I'm the developer of MakeQuickWork, a small site of free browser tools. This is how its Compress Image tool hits a file-size target, and the bug that made the first version miss it by two thirds.

Plenty of upload forms say "photo must be under 100 KB". So besides the usual Light / Recommended / Strong levels, the tool has a Target size mode: type a number of KB and get the best-looking file that fits.

The first version worked in the sense that every output was under 100 KB. On my 3200×2400 test photo it produced a 36 KB file at quality 31%. Under the limit, technically. Also a third of the budget, and visibly worse than it needed to be.

The setup

Everything runs in the tab. Encoders are WebAssembly builds via jSquash: MozJPEG for JPG, libwebp for WebP, OxiPNG for PNG. None of them ship with the page. The tool page loads roughly 10 KB of JavaScript, and each encoder is fetched the first time you actually compress something in that format. Files are never uploaded, which you can check in the Network tab: https://makequickwork.com/image/compress-image/

Quality mode is straightforward: decode to a canvas, encode at 85%, 75% or 60%. Target mode is a search problem: find the highest quality q where encode(q).size <= target.

Bug: searching with a stand-in encoder

MozJPEG through WASM isn't instant on a 7.7-megapixel image, and a search needs several encodes. The browser's canvas.toBlob(..., "image/jpeg", q) is much faster. So version one did the search with canvas, found the quality that landed just under 100 KB, then wrote the final file with MozJPEG at that same quality.

That assumes "quality 31%" means the same thing in both encoders. It doesn't. MozJPEG is built to squeeze harder than a typical encoder, and at low quality the gap gets large. Canvas needed 31% to fit in 100 KB. MozJPEG at 31% came out at 36 KB.

The tempting fix is a correction factor. I didn't trust one: the gap between encoders depends on the image content, so any constant is wrong for some photo. The fix that's actually correct is boring. Search with the same encoder that writes the file.

// Search with the same encoder that writes the file: a faster stand-in (the browser's JPG encoder)
// compresses very differently and would pick a much lower quality than needed.
const enc = (c: HTMLCanvasElement, q: number) => encode(c, to, { quality: q, optimize: true });

Making the real encoder affordable

That made each search step slower, so I needed fewer steps. Plain bisection on q between 0.30 and 0.92 takes five or six encodes to get close. But file size isn't random in quality: it grows smoothly and roughly exponentially. So I interpolate on log(size) between the two ends:

const top = await enc(c, 0.92);
if (top.size <= target) best = { blob: top, q: 0.92 };
else {
  const floor = await enc(c, 0.3);
  if (floor.size > target) continue; // too big even at low quality: try a smaller size
  best = { blob: floor, q: 0.3 };
  let lo = { q: 0.3, size: floor.size }, hi = { q: 0.92, size: top.size };
  for (let i = 0; i < 4 && best.blob.size < target * 0.92 && hi.q - lo.q > 0.03; i++) {
    const t = (Math.log(target * 0.97) - Math.log(lo.size)) / (Math.log(hi.size) - Math.log(lo.size));
    const q = Math.min(hi.q - 0.02, Math.max(lo.q + 0.02, lo.q + (hi.q - lo.q) * t));
    const blob = await enc(c, q);
    if (blob.size <= target) (best = { blob, q }), (lo = { q, size: blob.size });
    else hi = { q, size: blob.size };
  }
}

Details that matter:

It aims at 97% of the target, not 100%, so the guess lands under more often than over.
It stops as soon as the best result is within 8% of the target. 92 KB vs 97 KB isn't visible; another encode is.
The ±0.02 clamp keeps a bad guess from collapsing onto an endpoint.
best only ever holds a blob that fit, so the result can never be bigger than the target.

Usually that's two or three encodes after the endpoints, which roughly halved the time on a large photo compared with bisecting. It still takes a few seconds on a big image, because it really does encode several times. Quality mode is a single encode.

Same photo, same 100 KB target, after the fix: 96.1 KB at quality 56%.

When quality isn't enough

If even quality 30% doesn't fit, the image is too big in pixels for the budget. Only then does it shrink dimensions, stepping down through scales (0.85, 0.7, 0.55 and so on) and re-running the search at each. Quality first, pixels last, because most people uploading a photo to a form care more about it not looking smeared than about its exact resolution. If the image would have to drop below 48 px on its short side, it gives up and says so.

Other rules

PNG can't target a size. PNG is lossless, so there's no quality knob to turn. In target mode a PNG is saved as JPG, or as WebP if it has transparency, and the result row says which.
Never return a bigger file. In quality mode, if re-encoding in the same format produces something larger (common with already-optimised JPGs), the original is kept and labelled "already well compressed".
PNG colour reduction is on by default: UPNG.js quantises to at most 256 colours, then OxiPNG repacks. That's a big win for screenshots and icons, but it can band on photos and gradients. Off means lossless repacking only.
1 KB = 1024 bytes, because when a form says 100 KB I'd rather err on the strict side.
EXIF is removed, since the image is re-encoded from a canvas. Rotation is applied first.

In Recommended mode, on my test photos: the 2.9 MB photo went to 258.6 KB (91% smaller), and a 123.0 KB phone-style photo to 53.1 KB.

Checking the "no upload" part

The site is static (Astro on Cloudflare Pages), so there's no endpoint to receive a file. On top of that, an automated test processes files with each tool and fails if there's any POST or any third-party request other than Google Analytics, or if an analytics event contains a file name. GA4 is there for anonymous page and "tool used" counts. You need a connection to load the page and the encoders.

The lesson I keep relearning: a fast proxy for the real computation is fine for a progress bar, not for a decision. If you've done size targeting differently (a model of size vs quality per image, maybe), I'd like to hear about it.

Try it: https://makequickwork.com/image/compress-image/ or with 100 KB preset: https://makequickwork.com/image/compress-image-to-100kb/

Search across indexed NotebookLM notebooks

shaojie gong — Wed, 04 Nov 2026 13:41:09 +0000

Cross-notebook search needs a clear coverage model.

NotebookBloom indexes the chat and Studio content loaded when Search opens inside a notebook. Once indexed, that notebook can appear beside other indexed notebooks and saved source records, citations, cards and prompts.

The extension does not silently crawl every notebook in the account. An unopened notebook is not searchable, and source text that the page never loaded is not available to the local index.

A practical first test is small. Open one notebook, let indexing finish, and search for a distinctive phrase from the current conversation. Use Go to result and confirm that the notebook returns to the matching context.

The limitation is part of the privacy design: the index and query stay in the browser rather than being uploaded to a central search service.

Practical checklist

Use a public or non-sensitive notebook for the first test. Verify the output before deleting the intermediate file, and keep the product limitation visible.

Safari's canvas can't write WebP: notes from building a browser-only image converter

shaojie gong — Wed, 04 Nov 2026 01:19:07 +0000

I'm the developer of MakeQuickWork, a small set of free browser tools. This post is about its Image Converter: what I expected to be a 20-line canvas wrapper, and the parts that weren't.

The naive version of an image converter in the browser fits in a tweet: createImageBitmap(file), draw it on a canvas, call canvas.toBlob(cb, "image/webp"). In Chrome that works. Then you open it on an iPhone and the "WebP" file you get back is a PNG with the wrong extension, because Safari's canvas can't encode WebP and silently falls back to PNG.

That was the first of a handful of things that shaped the tool. It converts to JPG, PNG or WebP, opens JPG, PNG, WebP, GIF, BMP, AVIF and HEIC, and everything happens in the tab. No upload: https://makequickwork.com/image/image-converter/

Don't trust the extension

Files saved from the web lie about themselves all the time. A CDN serves WebP to a browser that asked for it, the user hits "Save image as", and they end up with photo.jpg that is actually WebP. So the first thing the pipeline does is read the first bytes and decide for itself:

export function sniff(b: Uint8Array): SourceFormat {
  const ascii = (from: number, to: number) => String.fromCharCode(...b.subarray(from, to));
  if (b[0] === 0xff && b[1] === 0xd8 && b[2] === 0xff) return "jpg";
  if (b[0] === 0x89 && ascii(1, 4) === "PNG") return "png";
  if (ascii(0, 4) === "RIFF" && ascii(8, 12) === "WEBP") return "webp";
  if (ascii(0, 3) === "GIF") return "gif";
  if (ascii(0, 2) === "BM") return "bmp";
  if (ascii(4, 8) === "ftyp") {
    // ISO-BMFF: major brand plus a list of compatible brands.
    const size = Math.min((b[0] << 24) | (b[1] << 16) | (b[2] << 8) | b[3], b.length);
    const brands = [ascii(8, 12)];
    for (let i = 16; i + 4 <= size; i += 4) brands.push(ascii(i, i + 4));
    if (brands.some((x) => x === "avif" || x === "avis")) return "avif";
    if (brands.some((x) => ["heic", "heix", "hevc", "hevx", "heim", "heis", "mif1", "msf1"].includes(x))) return "heic";
  }
  return "unknown";
}

AVIF and HEIC are both ISO-BMFF containers, so they share the ftyp box. Checking only the major brand isn't enough: some files put mif1 up front and the interesting brand in the compatible list. AVIF is checked first because an AVIF file can also list mif1.

The sniffed format decides the decode path and a couple of later details, like whether a "transparent areas filled with white" note makes sense.

Decoding: let the browser do it, with one fallback

For almost everything, decoding is:

const bmp = await createImageBitmap(file, { imageOrientation: "from-image" });

imageOrientation: "from-image" applies the EXIF Orientation tag, so phone photos come out upright instead of sideways.

HEIC is the exception. Safari decodes it natively, so I try createImageBitmap first. When that throws (Chrome, Edge, Firefox), the tool loads libheif compiled to WebAssembly and decodes the bytes itself. AVIF has no fallback: current Chrome, Edge, Firefox and Safari decode it, and if one doesn't, the error message says to try a current browser instead of failing silently.

After decoding, everything is drawn onto a canvas. The canvas is capped at about 16 megapixels, because iPhone Safari refuses to allocate canvases above roughly 16.7M pixels. If an image is bigger, it is scaled down to fit and the result row says so (scaled to W × H (browser size limit)), rather than quietly handing back a smaller file.

Encoding: three formats, three paths

PNG is the easy one: canvas.toBlob(cb, "image/png"). Transparency is kept.

JPG has no alpha channel, and if you encode a transparent canvas as JPEG, the transparent pixels typically come out black. So the canvas is first drawn onto a white-filled copy, then encoded with canvas.toBlob(cb, "image/jpeg", quality). If the source actually had transparent pixels, the result row says "transparent areas filled with white". I'd rather tell people than let them discover a white box around their logo later.

WebP never goes through the canvas encoder. It always uses libwebp compiled to WebAssembly, via jSquash:

// Safari's canvas cannot write WebP, so always use the WASM encoder.
const { default: webp } = await import("@jsquash/webp/encode");
const out = await webp(ctx.getImageData(0, 0, w, h), { quality: Math.round(quality * 100) });

I could have used the native encoder where it exists and WASM only on Safari. I chose WASM everywhere so that the same input and the same quality setting give the same file in every browser. Debugging "it's 20 KB bigger on my machine" across two different encoders didn't sound fun.

Quality is a select with three values: Maximum (0.95), High (0.9, default) and Medium (0.8). PNG hides the select, since it's lossless.

On my test images (three small JPGs at High) the WebP versions came out at 41.3 → 24.6 KB, 91.7 → 57.8 KB and 37.9 → 22.1 KB. That's three files, not a benchmark; photos and screenshots behave very differently.

What it deliberately doesn't do

Animation. GIF and animated WebP give you the first frame only. Encoding animated WebP is a different project.
EXIF. Metadata isn't copied. Orientation is applied to the pixels, and GPS, camera model and date are gone. For a converter that's usually what people want, but it's a choice, so it's listed on the page.
Transparency in JPG. It can't exist, hence the white fill.

Batch, ZIP and stale results

You can drop many files at once. One result downloads directly; several are zipped with fflate using level: 0. Images are already compressed, so store-only zipping is basically a memory copy and doesn't stall a phone.

One small rule that took me a while to settle: any change to the options (format or quality) throws away earlier results. Without that, you could convert to WebP, switch to JPG, click Download, and get WebP files. Now clicking the button after a change reconverts everything with the new settings.

Keeping the page light

The tool page ships about 10 KB of JavaScript. The decode/encode module is a dynamic import, and the WebP encoder (and libheif, if needed) only downloads the first time you actually convert something. Someone who lands on the page from search and leaves doesn't pay for a WASM binary.

The site is static (Astro on Cloudflare Pages), so there's no upload endpoint at all. There's also an automated test that processes files in every tool and fails on any POST or any third-party request other than Google Analytics (used for anonymous page counts; the test also fails if an analytics event contains a file name). You do need a connection to open the page and fetch the code.

If you've hit other browser quirks with canvas encoding, or have an opinion on "same encoder everywhere" vs "native where possible", I'd like to hear it in the comments.

https://makequickwork.com/image/image-converter/

Flashcards not captured? Check these five things

shaojie gong — Tue, 03 Nov 2026 12:59:47 +0000

A zero-card import can come from two different stages: capturing the cards from NotebookLM or sending the captured cards to Anki.

Start with capture. Let NotebookLM finish generating the set. Confirm that the current notebook owns the visible cards. If the extension was updated while the page stayed open, refresh the page so the new content scripts load.

Use NotebookBloom 1.1.6 or newer. Version 1.1.5 added support for NotebookLM's Blob iframe and structured card content. Reopen the Cards panel and run Import from notebook again.

Only after the cards appear inside NotebookBloom should you troubleshoot APKG or AnkiConnect. APKG does not require a running local bridge. AnkiConnect does.

The failure-event decline after the parser fix is encouraging, but a troubleshooting guide remains useful for users who learned that the old button returned zero and stopped trying.

Practical checklist

Use a public or non-sensitive notebook for the first test. Verify the output before deleting the intermediate file, and keep the product limitation visible.

Decoding iPhone HEIC photos in Chrome: libheif as WebAssembly, loaded on demand and kept out of the bundle

shaojie gong — Tue, 03 Nov 2026 01:48:14 +0000

I'm the developer of MakeQuickWork, a small set of free browser tools. This post is about its HEIC to JPG converter and the two or three things that took longer than the conversion itself.

iPhones save photos as HEIC by default. Copy a few of them to a Windows laptop, or try to attach one to a form that only takes .jpg, and you find out how unevenly that format is supported. I wanted a converter that runs in the tab, so the photos are never uploaded: https://makequickwork.com/image/heic-to-jpg/

The interesting part is that the browser you're in decides how much work there is.

Two decode paths

Safari can decode HEIC itself. Chrome, Edge and Firefox can't, which covers most Windows and Android users, i.e. most of the people who actually have the problem. So the decoder tries the native path first and falls back to libheif compiled to WebAssembly:

if (format === "heic") {
  try {
    // Safari decodes HEIC natively, rotation included.
    const bmp = await createImageBitmap(file, { imageOrientation: "from-image" });
    source = bmp;
  } catch {
    // Everyone else: libheif (WebAssembly), loaded on first use.
    const { decodeHeic } = await import("./heic");
    const data = await decodeHeic(bytes);
    const c = newCanvas(data.width, data.height);
    c.getContext("2d")!.putImageData(data, 0, 0);
    source = c;
  }
}

Both paths end on a canvas. From there it's canvas.toBlob() as JPG (quality Maximum, High or Medium) or PNG. Rotation is applied on both paths, so photos come out the right way up.

format doesn't come from the file extension or the MIME type. Windows often reports HEIC files with an empty MIME type, so the file input accepts .heic,.heif by extension, and the code then reads the ftyp box and checks the brands (heic, heix, mif1 and friends). A JPG renamed to .heic gets a clear "this is not a HEIC photo" message instead of a decoder crash.

Why the decoder isn't in the bundle

libheif is LGPL-3.0. I'm not a lawyer, but the spirit of the LGPL is that users should be able to swap the library for their own build. If I let the bundler inline it into a hashed chunk, that's hard to do in any practical sense.

So it's not bundled. A build script copies the unmodified libheif.js and libheif.wasm from libheif-js 1.23.5 to /vendor/libheif/, next to the licence text and a SOURCE.txt that points to the corresponding source and says you may replace the two files. The app loads them from that fixed path with a plain <script> tag.

A side effect I like: the decoder is about 1.4 MB, and it's a separate request that only happens when it's needed.

Two gotchas with the Emscripten build

It couldn't find its own .wasm. Loaded via a <script> tag on the main thread, this build failed to locate and fetch libheif.wasm by itself. The fix was to fetch it myself and hand it over as wasmBinary:

const res = await fetch("/vendor/libheif/libheif.wasm");
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const wasmBinary = new Uint8Array(await res.arrayBuffer());

// Emscripten writes its exports onto the options object.
const mod: Record<string, unknown> = {
  wasmBinary,
  // HeifDecoder is attached right after onRuntimeInitialized, so wait one tick.
  onRuntimeInitialized: () => setTimeout(() => resolve(mod)),
};
factory(mod);

HeifDecoder wasn't there yet. onRuntimeInitialized fires, you reach for mod.HeifDecoder, and it's undefined. The JS wrapper attaches it right after that callback returns. A setTimeout with no delay was enough. It's an ugly line, so it has a comment.

The loader promise is cached, and reset on failure, so a flaky connection gives a "check your connection and try again" message and the next attempt starts clean.

Lazy loading, with a test that holds me to it

The page itself loads only a few KB of JavaScript. The decoder is downloaded when the first HEIC is actually converted, and Safari, which decodes HEIC itself, doesn't need it. There's a Playwright test that opens the page and fails if any request to libheif happens before a file is chosen, plus one that converts the sample photo and checks that both vendor files were fetched from /vendor/libheif/.

(That screenshot is Chrome: it can't preview HEIC, so the rows show an icon instead of a thumbnail until they're converted.)

On my test files, three 1280×854 HEIC samples of 701.3 KB each, the JPGs at High quality came out at 417.7 KB. Those are small samples, not full-size iPhone photos, so don't read much into the ratio. Several files come back as a ZIP; one file downloads directly.

What the output doesn't keep

Going through a canvas has consequences, and I'd rather list them than have someone find out later:

No EXIF. GPS location, camera model and date are not carried over. For photos you're sending to someone, I count that as a side benefit.
Live Photos give you the still image only. Depth and HDR extras are dropped.
Colour. iPhones shoot in Display P3; the canvas saves sRGB, so very saturated colours can look slightly less intense on a wide-gamut screen.
Size. iPhone Safari refuses canvases above roughly 16.7 million pixels, so anything bigger is scaled to stay under ~16 MP, and the result row says so.
Only HEIC/HEIF. Other formats go to the separate Image Converter.

Checking that nothing is uploaded

The site is static (Astro on Cloudflare Pages), so there's no endpoint to upload to. An automated test still processes a file with each tool and fails on any POST, or on any third-party request other than Google Analytics (used for anonymous page counts), and also if an analytics event contains a file name. You can watch the Network tab yourself while converting. You do need a connection to load the page and, outside Safari, the decoder.

The open question for me is moving decoding into a Web Worker so a batch of large photos doesn't block the main thread. If you've run an Emscripten build like this in a worker, I'd like to hear what broke.

Your first two minutes with NotebookBloom

shaojie gong — Mon, 02 Nov 2026 12:38:08 +0000

A feature tour is a poor first task. A new user needs one result they can recognize.

For NotebookBloom, the shortest path is a small Anki export. Open a NotebookLM notebook that already contains flashcards. Open NotebookBloom, choose Cards, import the current notebook, and export APKG.

Open the deck in Anki and inspect one card. If the front, back and source are present, the first workflow is complete. The user now knows where the panel lives and what a successful result looks like.

Only then does it make sense to introduce citations, local search, bulk import, folders and saved prompts. Showing every feature before the first result increases reading without increasing confidence.

The 30-day analytics window recorded 195 installation events and 54 first-value users. That is a same-period proxy rather than a cohort conversion rate, but it is enough to make first value the next product priority.

Practical checklist

Use a public or non-sensitive notebook for the first test. Verify the output before deleting the intermediate file, and keep the product limitation visible.

Compressing PDFs in the browser: most of the work is deciding which images not to touch

shaojie gong — Mon, 02 Nov 2026 01:16:08 +0000

I build MakeQuickWork, a small set of free browser tools, on my own. This is how its Compress PDF tool works and where the edge cases were.

A PDF that's too big is almost always a PDF full of images. Scans from a phone app, a report with photos pasted in, a brochure exported at print resolution. The text and vector parts are usually a few hundred KB at most. So the plan for Compress PDF was narrow on purpose: find every image, make it smaller if that's safe, and copy everything else byte for byte.

The "if that's safe" part ended up being most of the code.

It all runs in the tab. The page itself loads about 3 KB of JS; the PDF library and the MozJPEG encoder (WebAssembly, via jSquash) are only fetched once you actually pick a file and compress. The PDF is never uploaded, which you can watch in the Network tab: https://makequickwork.com/pdf/compress-pdf/

Walking the image XObjects

I use a maintained fork of pdf-lib. After loading the document, I enumerate every indirect object and keep the raw streams whose /Subtype is /Image. That catches images regardless of which page or form XObject references them, and an image shared by ten pages gets compressed once.

Before touching anything, a first pass collects every object referenced as /SMask or /Mask. Those are transparency masks. Lossy-compressing a soft mask gives you grey halos around logos, so they're off limits.

Then each image goes through a list of reasons to skip it:

filter is not exactly DCTDecode (JPEG) or FlateDecode (lossless). That rules out JPEG 2000, JBIG2 and CCITT fax images
colour space isn't DeviceRGB, DeviceGray or a 1- or 3-channel ICCBased profile. CMYK print images are skipped rather than risk a colour shift
BitsPerComponent isn't 8, or the image has a /Decode array, or it's an image mask
smaller than 64 px on a side (icons, bullets: not worth it)

Anything that survives gets decoded to a canvas.

Two decoders

JPEG images are easy: the stream contents already are a JPEG file, so createImageBitmap(new Blob([bytes], { type: "image/jpeg" })) does the work, with imageOrientation: "none" so the browser doesn't apply EXIF rotation the PDF never asked for.

Flate images are raw pixel rows, zlib-compressed. pdf-lib inflates them, but many PDFs also use a PNG predictor (/DecodeParms << /Predictor 15 >>), which means every row starts with a filter-type byte and is delta-encoded against its neighbours. The browser can't help there, so I undo the five PNG filters (None, Sub, Up, Average, Paeth) by hand in a small loop before putting the pixels into ImageData. Any other predictor value: skip.

Not every lossless image should become a JPEG

A Flate image in a PDF is often a screenshot, a chart or a logo. Converting those to JPEG makes ringing around text and edges, and they're usually small as Flate anyway. I didn't want a classifier, so it's a cheap heuristic: sample every 7th pixel and check whether it's identical to the pixel before it.

/** Flat colour graphics (screenshots, charts, logos) look bad as JPG and are usually small as Flate. */
function isFlatGraphic(rgba: Uint8ClampedArray) {
  let same = 0, total = 0;
  for (let i = 4; i < rgba.length; i += 4 * 7) {
    total++;
    if (rgba[i] === rgba[i - 4] && rgba[i + 1] === rgba[i - 3] && rgba[i + 2] === rgba[i - 2]) same++;
  }
  return total > 0 && same / total > 0.5;
}

If more than half the samples match their neighbour, the image stays lossless. Photos almost never pass that; flat UI screenshots almost always do. On the Light level, Flate images aren't re-encoded at all.

Downscale, encode, and only replace if it's clearly worth it

Each level is a maximum long side and a MozJPEG quality: roughly 300 DPI / q82 for Light, 150 DPI / q72 for Recommended, 100 DPI / q55 for Strong, assuming the image covers a normal page. The canvas is downscaled, then encoded as baseline JPEG, because some older PDF readers don't handle progressive JPEG inside a PDF.

Then the check that matters most for quality:

// Only replace when it is clearly smaller; re-encoding a small JPG for 2% is not worth the loss.
const limit = kind === "flate" ? 0.7 : 0.9;
if (jpg.length >= stream.contents.length * limit) continue;

A JPEG has to come out at least 10% smaller to replace the original; a lossless image has to shrink by at least 30%, since that swap also changes it from lossless to lossy. When it does get replaced, the new stream keeps the original dictionary minus Filter/DecodeParms/Length, with new width, height and a plain DeviceRGB/DeviceGray colour space.

The lossless leftovers

Some PDF generators write content streams with no filter at all. After the image pass, any unfiltered stream over 256 bytes gets deflated, kept only if that saves 10% or more. Then the document is saved with object streams on, which packs the many small objects together.

Text, fonts, vector paths, links, bookmarks and form fields aren't touched by any of this, so text stays selectable and searchable. That's the main difference from approaches that rasterise whole pages.

What it does to a real scan

On my test file, three phone-scanned pages, Recommended took it from 0.6 MB to 165 KB, 73% smaller. The page shows original size, compressed size and percent saved:

And the honest part: a mostly-text PDF barely shrinks, because there's nothing big to recompress. If the result isn't at least about 3% smaller, the tool doesn't download anything and tells you to keep the original. Strong makes photos visibly softer. Password-protected PDFs aren't supported yet, and it's one file at a time.

Checking that nothing is uploaded

The site is static (Astro on Cloudflare Pages), so there's no endpoint to upload to. There's also an automated test that processes a file in each tool and fails on any POST or any request to a third party other than Google Analytics, and fails if an analytics event contains a file name. GA4 is there for anonymous page views and a "tool used" event. You still need a connection to open the page and fetch the encoder the first time.

If you've got a PDF that you expected to shrink and didn't, I'm curious what's inside it. CMYK and JBIG2 are the two skips I'm least sure about keeping.

https://makequickwork.com/pdf/compress-pdf/

Why flashcard sources disappear on the way to Anki

shaojie gong — Fri, 30 Oct 2026 13:28:14 +0000

A flashcard can look complete and still be hard to trust.

The question and answer are visible, so a quick copy or TSV export often preserves them. The source may live somewhere else in the interface: a document title, a citation reference, a URL or the notebook context. Unless the export maps that information into a field, Anki never receives it.

I prefer a dedicated Source field on the note type. It can be rendered on the back of the card below the answer. That keeps the study surface clean while leaving a path back to the evidence.

Before studying, inspect three cards from different parts of the deck. Confirm that the source belongs to the correct card and that any URL opens the intended material.

Full disclosure: I built NotebookBloom because I needed this workflow. The field-design advice applies whether the cards come from NotebookBloom, a spreadsheet or a custom script.

Practical checklist

Use a public or non-sensitive notebook for the first test. Verify the output before deleting the intermediate file, and keep the product limitation visible.

Splitting PDFs in the browser: a forgiving page-range parser, synced thumbnails and a ZIP that sorts correctly

shaojie gong — Fri, 30 Oct 2026 01:30:36 +0000

I'm the developer of MakeQuickWork, a small set of free browser tools. This post walks through how its Split PDF tool works, with the parts that took longer than I expected.

"Split PDF" sounds like a one-liner: open the document, copy some pages, save. The copying really is the easy part. What took most of the time was everything around it: letting people describe pages the way they naturally write them, keeping a text field and clickable thumbnails in agreement, and producing output files that behave well once they land in someone's Downloads folder.

The tool runs entirely in the browser. The PDF is read into memory, processed in the tab, and saved with a normal download. Nothing is uploaded, which you can check in the DevTools Network tab while you use it: https://makequickwork.com/pdf/split-pdf/

Three modes, one engine

Users ask for three different things when they say "split":

Extract pages: "give me pages 2–3 as a new PDF". Click thumbnails or type 1-3, 5. Output is one PDF.
Every page separately: one PDF per page, delivered as a ZIP.
Custom ranges: 1-3, 4-6, 7- gives one PDF per range, also in a ZIP.

Under the hood all three reduce to a list of [from, to] ranges. "Every page" is just [1,1], [2,2], ..., and extract mode is a single output built from the expanded page list. So the core is a range parser and a "copy these pages into a new document" function.

There's also no dedicated "delete pages" button. Removing pages is select all, deselect the ones you don't want, extract. I went back and forth on adding one, but it would be the same code path with an inverted selection, and one fewer mode to explain felt better.

A range parser that explains itself

People type page ranges in many ways: 1-3,5, 1 - 3; 5, 8- for "to the end", -3 for "from the start". Some will paste an en dash from a Word document. And when the input is wrong, a red border tells you nothing, so every failure gets a sentence telling you how to fix it.

Here is the parser, lightly trimmed:

export type Range = [number, number];
export class RangeError extends Error {}

/** Parses "1-3, 5, 8-" into ranges. `-3` means 1–3, `8-` means 8 to the end. */
export function parseRanges(text: string, pageCount: number): Range[] {
  // "2 - 6" means 2-6, so join the dash to its numbers before splitting on spaces.
  const parts = text
    .replace(/\s*([-–])\s*/g, "$1")
    .split(/[,;\s]+/)
    .map((p) => p.trim())
    .filter(Boolean);
  if (!parts.length) throw new RangeError("Enter the pages you want, for example 1-3, 5.");
  return parts.map((part) => {
    const m = /^(\d*)\s*[-–]\s*(\d*)$/.exec(part) ?? /^(\d+)$/.exec(part);
    if (!m) throw new RangeError(`"${part}" is not a page or range. Use numbers like 4 or 2-6.`);
    const from = m[1] ? Number(m[1]) : 1;
    const to = m.length > 2 ? (m[2] ? Number(m[2]) : pageCount) : from;
    if (from < 1 || to < 1) throw new RangeError("Page numbers start at 1.");
    if (from > pageCount || to > pageCount)
      throw new RangeError(`This PDF has ${pageCount} page${pageCount === 1 ? "" : "s"}.`);
    if (from > to) throw new RangeError(`"${part}" goes backwards. Write it as ${to}-${from}.`);
    return [from, to];
  });
}

A few decisions worth calling out:

Separators are generous. Commas, semicolons and whitespace all separate parts, and both - and – work as the range dash. Because whitespace is also a separator, an early version split 2 - 6 into three tokens. Now the input is normalized first with .replace(/\s*([-–])\s*/g, "$1"), which pulls the dash onto its numbers, so 2 - 6 works exactly like 2-6.
The error names the bad token. "6-3" goes backwards. Write it as 3-6. is more useful than "invalid range", and it costs one template string.
The page count is part of the error. If you type 12 on a 10-page file, you get This PDF has 10 pages. That answers the next question before you ask it.
Open-ended ranges resolve immediately. 7- becomes [7, pageCount] at parse time, so the rest of the code never deals with "infinity".

Keeping thumbnails and the text field in sync

In extract mode there are two inputs for the same state: you can click page thumbnails or type in the "Pages to extract" field. Both have to agree at all times.

The source of truth is a Set<number> of selected pages. The two directions work differently:

Thumbnail click → text. Toggle the page in the set, then rewrite the text field from the set with a small formatter that collapses runs: {1,2,3,5} becomes 1-3, 5.
Text → thumbnails. Parse on every input event and update the set, but do not rewrite the text field. If you reformat while someone is typing 1-, the cursor jumps and their half-finished range disappears. So typing only flows one way until the next click.

If the text doesn't parse, the selection clears, the error sentence appears under the field, and the button is disabled. The button label follows the set too ("Extract 2 pages"), which turned out to be the clearest confirmation that the parser understood you.

Copying pages without touching them

For the actual work I use a maintained fork of pdf-lib. Copying pages from one document into a new one keeps their content streams, fonts and images as they are, so nothing is re-rendered or re-compressed. Text stays selectable and vector graphics stay vector. Each page also keeps its own size.

PDF.js (Mozilla) is used separately, only to draw the thumbnails. Both libraries are loaded lazily after you pick a file, so the page itself stays light.

The main known limit: password-protected PDFs aren't supported yet. One more behavior worth knowing: in extract mode the pages are written in page order, so typing 5, 2 gives you page 2 then page 5.

A ZIP that sorts correctly

The two multi-file modes return a ZIP. Two small details made a visible difference.

Zero-padded names. If a 120-page file is split per page and named page-1.pdf ... page-120.pdf, most file managers sort page-10 before page-2. Padding to the width of the page count fixes that:

const width = String(pageCount).length;      // 120 → 3
const pad = (n: number) => String(n).padStart(width, "0");
// report-page-001.pdf, report-page-002.pdf, ..., report-pages-004-006.pdf

If someone types the same range twice, the second file gets a -2 suffix instead of silently overwriting the first.

No compression. The ZIP is built with fflate's zipSync(files, { level: 0 }). PDFs are already compressed internally, so deflating them again burns CPU for a few percent at most. Store-only zipping is close to a memory copy, which matters on phones.

How I check that nothing is uploaded

"Runs in your browser" is easy to claim, so there is an automated test that loads each tool, processes a file, and fails if the page makes any POST or any request to a third-party host other than Google Analytics during processing (the site uses GA4 for anonymous visit counts, and the test also fails if an analytics event contains the file name). The site is static (Astro on Cloudflare Pages), so there is no upload endpoint to call in the first place. You do need a connection to open the page and load the tool code.

Wrapping up

The PDF part was maybe a fifth of the work. The rest was input handling, state sync and file naming, which is the part users actually touch. If you have opinions on range syntax (should 5- on a 5-page file be allowed? it is today) or ideas for edge cases I missed, I'd like to hear them in the comments.

Try it here: https://makequickwork.com/pdf/split-pdf/