DEV Community: NullPointerZen

Two canvas font shortcuts worked in three browsers and drew the fallback in Firefox

NullPointerZen — Thu, 15 Oct 2026 08:07:56 +0000

You build a share card on a canvas: a headline in a nice serif, a price, a button that saves the whole thing as a PNG. The first time the page opens, the saved image has the headline in plain sans-serif. Reload and it looks right, and the console is empty both times. I make small share-image generators for a content team and wanted to know which way of "waiting for the font" I could lean on, so I wrote a test page to compare them.

The plain version first. @font-face is the CSS rule that gives a font a name and says where its file lives. Declaring it doesn't download the file, and canvas fillText doesn't wait for it. On my page, drawing straight after the declaration came out in the fallback, the generic font listed after mine in the font string, with no error. That happened in all four browsers I tried, Chromium 149, Chrome 155, Firefox 151 and WebKit 26.5, on one Apple M4 running macOS.

So I have to wait for something, and I had three candidates. The first two are shortcuts that look like waiting. One is to put some ordinary page text in the font and draw in the load event, which fires once the page and its resources have finished loading. The other is a preload, <link rel="preload" as="font" crossorigin>, which asks the browser to fetch the file early, and then drawing as soon as that link reports it is done. Neither one asks about the font itself. It is like deciding the kettle has boiled because the toast popped. The third asks directly: document.fonts.load() takes a font string and returns a promise that resolves when that font has been loaded.

Every cell was compared pixel by pixel with two reference renders, one drawn with the font fully loaded and one with the fallback alone. The rows to look at are the fifth, sixth and eighth. Both shortcuts are green in three columns and red under Firefox 151, and the document.fonts.load row is green all the way across. The test font is a 3,755-character subset of Noto Serif SC, 1,046,216 bytes as WOFF2. Noto Serif SC and Pacifico, the Latin font mentioned below, are both SIL OFL 1.1.

Firefox was the odd one out both times. With the preload, drawing the moment the download finished gave the fallback there, and drawing again 1,000 ms later gave the custom font. I didn't look into why. The second row of the chart bothered me more. The load shortcut only worked anywhere because some page text used the font. When I removed that text, drawing in load gave the fallback in all four browsers, and the custom font appeared when I drew again 1,500 ms later. document.fonts.ready, a promise for the page's fonts as a whole, behaved the same way. With the text on the page it was fine in all four. Without it the promise came back in under 20 ms and I got the fallback in all four. A wait that only holds while some unrelated text stays on the page is one I don't trust myself to keep intact.

Awaiting document.fonts.load gave the custom font in all four browsers, with the Chinese subset, with Pacifico, and with the full 11.6 MB Noto Serif SC file. The wait does cost time. On my local server throttled to a fixed 20 Mbps, a rate I set myself and not a real network, the same subset took about 0.5 seconds to come back. I also tried document.fonts.check(), the call that answers whether a font is ready. It returned true for a font name I had never declared, in all four browsers, so I don't use it as a gate.

To see how a finished product deals with this, I used ImgIng (https://imging.ai/), whose online design editor has text layers with downloadable fonts and says under the font menu how big the first download is. I delayed the Korean font's response on purpose, picked Noto Sans Korean and clicked export about 0.2 seconds later. The file was written only after the font response arrived, and it was byte-for-byte identical to the PNG I exported after waiting, 39,765 bytes, against 39,854 for the system-font export.

In the top half the status bar says the text layer font is still downloading and the layer is 648 wide. In the bottom half the glyphs have changed and the width reads 677. I only watched this one flow, in Chromium 149 with one font, and I haven't seen how it is written inside.

My share-card pages now await document.fonts.load with the exact font string right before the first draw. How any of this behaves on phones, on Windows, in release Safari or in Edge I can't say, because I tested none of them.

I closed every VideoFrame and memory still climbed by gigabytes

NullPointerZen — Wed, 14 Oct 2026 08:08:05 +0000

I build small tools for a content team, and a lot of them come down to the same job: open a video, do something to every frame, save the result. In a browser you hand the compressed video to a VideoDecoder, which turns it back into full pictures, and each picture arrives as a VideoFrame. Every guide attaches one rule: call close() when you are done with a frame, because it is big. On my 1080p sample one frame reported 3,110,400 bytes, about 3.1 MB.

So I wrote the loop by the book. The sample is a clip of waves from Wikimedia Commons that I converted to H.264 MP4 with ffmpeg 7.1 and looped end to end into 60 seconds of 1920×1080, which makes 1,500 frames. It is a stitched loop, not real long footage. I unpacked it with mp4box.js 0.5.2 and handed every compressed chunk to the decoder in one go. Decoded frames went into an array, and a second loop took them out one at a time: draw on a small canvas, read one pixel, wait 10 ms to stand in for real work, close().

const waiting = [];
const decoder = new VideoDecoder({ output: f => waiting.push(f), error: console.error });
decoder.configure(cfg);
for (const chunk of chunks) decoder.decode(chunk); // all 1,500, no questions asked

In Chromium 149 all 1,500 frames came out, nothing was logged, and every one of them got its close(). System memory still peaked 3,752 MB above where it started. That reading is noisy, and the same scene can land more than 1 GB apart between two runs, but it is gigabytes either way.

The reason turned up when I ran the plainest version, the one that closes each frame the moment it arrives. The same 1,500 frames were through in 752 ms. Decoding the whole clip takes under a second, and my pretend work takes 10 ms per frame. The array in the middle is where the difference went: at its worst it held 1,421 frames that were decoded and not yet processed. Each one did get closed when its turn came. Until then it was a full picture in memory.

It reminds me of moving flats. The driver empties the van onto the pavement in minutes, and I carry one box upstairs at a time. Every box gets there in the end, but for most of the afternoon the pavement is covered in my stuff. close() is me putting a box away. It says nothing about how fast the driver unloads.

The red line is the loop above. It shoots up to about 1,400 waiting frames in the first couple of seconds and needs the rest of the 20 seconds to come back down. The blue line is the same work with the feed paced, which means I check two numbers before handing over the next chunk. One is decoder.decodeQueueSize, the count of chunks the decoder has accepted and not decoded yet. The other is the length of my own array.

for (const chunk of chunks) {
  while (decoder.decodeQueueSize > 8 || waiting.length > 4) await nap(2); // nap = setTimeout as a promise
  decoder.decode(chunk);
}

With that one extra line the backlog peaked at 17 frames instead of 1,421, and the system memory peak was 165 MB. The total time barely moved, 18.9 s against 20.3 s, which I read as "about the same" and nothing more.

What threw me is where the memory was. In the unpaced run the browser's own process memory, summed over all its processes, changed by 0 MB. On macOS the frames sat in graphics buffers, blocks of memory the system shares with the graphics side and calls IOSurface. Running ioclasscount IOSurface in a terminal counts them.

Look at the fourth and fifth bars: 1,488 extra buffers for the unpaced loop, 29 for the paced one. On a 4K clip of a river I only fed 400 frames to spare the machine, and the backlog peaked at 332 without pacing and 16 with it.

For comparison I wanted a per-frame pipeline that somebody had already shipped. For that I used ImgIng (https://imging.ai/). Its video matting tool is still labeled Beta, and the site says desktop Chrome and Edge are supported first. I ran it on the same 1,500-frame wave clip in Chromium 149. Sampled every 2 seconds for the whole job, the graphics-buffer count stayed between −2 and 79 above its starting level and did not rise with progress. Waves have no subject to cut out, so this is about memory and says nothing about matting quality.

This is what the tool looks like while it works. There is nobody in the wave clip, so I took the screenshot with a different one: 8 seconds of a street guitarist in Ljubljana, video by Isak Zvegelj on Wikimedia Commons (CC BY 3.0). I did not re-measure memory with it.

One thing I can't explain yet. In the unpaced run the backlog drained from 1,403 frames down to 4, but the buffer count stayed between 1,430 and 1,490 the whole time and only fell when the browser quit. I haven't looked into why. Everything here is from one Apple M4 with 16 GB on macOS, and I don't know where frames live on other systems. No run fell over, so I can't say where the ceiling is. What I do now is log the peak of waiting.length next to the frame count. If the two are close, the frames are queuing.

The wave footage is by David Shay (דוד שי) and the river footage by Nesnad, both from Wikimedia Commons under CC BY-SA 4.0.

Five ways to grab a frame from a portrait video, and they don't agree on which way is up

NullPointerZen — Tue, 13 Oct 2026 08:06:57 +0000

A portrait clip opens fine on the watch page. Tall, upright, nothing to see. Then you scroll back to the list and its thumbnail is a wind turbine lying on its side. I build small internal tools for a content team, and this is the kind of bug that lands on my desk as a screenshot with three question marks.

It took me a while to accept that the video was never upright in the first place. A lot of portrait video is stored with the pixels lying down, as an ordinary landscape picture, and the file carries a separate note that says "turn this 90 degrees when you play it". I think of it as a sticky note on the box. A player reads the note and turns the picture. Anything that opens the box without looking at the lid gets the picture the way it was packed.

To find out who reads the note, I took an example clip from Wikimedia Commons, a wind turbine against a blue sky. I painted a red block in its top-left corner and a green one in the top-right to mark which way is up. Then I had ffmpeg 7.1 store it sideways as 1920×1080 H.264 with the note attached, which ffmpeg reports as rotation of -90.00 degrees. So this is a lab sample, not footage straight off a phone, and I didn't test HEVC, iPhone Safari or Android. I grabbed a frame from it five different ways in Chromium 149, Chrome 154, Firefox 151 and WebKit 26.5 on macOS.

Read each row left to right and follow the red block. Top-left means the frame is upright, bottom-left means it is lying down. The turbine footage is by Grendelkhan on Wikimedia Commons, CC BY-SA 4.0.

Two of the five never let me down. Plain <video> playback was upright in all four browsers and reported videoWidth × videoHeight as 1080×1920. canvas.drawImage(video), the old trick of painting the current frame onto a canvas, was upright in all four as well. The trouble starts with the two newer shortcuts.

const bmp = await createImageBitmap(video); // the current frame as a ready-to-draw bitmap
const vf = new VideoFrame(video);           // the current frame as a WebCodecs object
console.log(bmp.width, bmp.height, vf.displayWidth, vf.displayHeight, vf.rotation);

In Chrome 154 and WebKit 26.5 both lines gave me an upright 1080×1920 frame. In Firefox 151 both came back as 1920×1080 with the turbine on its side, and the VideoFrame had no rotation property at all, so there was nothing to check against. Chromium 149 found a third answer. Its createImageBitmap returned a 1920×1080 bitmap whose picture was the right way up but squashed: my 160×160 corner blocks came out at roughly 284×90. Chrome 154 runs the same line correctly. I haven't gone looking for why the two builds differ.

The fifth way is the one where every browser agrees, and they agree on the wrong answer. If you unpack the MP4 yourself (I used mp4box.js 0.5.2) and feed the compressed samples to VideoDecoder, the browser's raw decoder, the frames come out sideways in all four. In the two Chromium builds the decoded frame even says rotation is 0. That is when the sticky note finally clicked for me. The note is not inside the video stream. It sits in the container, in a field of the track header called the matrix, and the decoder only ever sees the stream. mp4box will show it to you if you ask.

const t = info.videoTracks[0];
const m = t.matrix || file.getTrackById(t.id).tkhd.matrix;
console.log(t.track_width, t.track_height, Array.from(m));
// 1920 1080 [0, 65536, 0, -65536, 0, 0, 0, 0, 1073741824]

Even the width and height in there are the packed size, not what a viewer sees. So when I do the unpacking myself, the rotation is my job too. I assume <video> gets it right because the browser's own unpacker reads the matrix and passes it along, but that is a guess from behaviour, not from reading source.

The container matters in the other direction too. I moved the same sideways pixels and the same note into a VP9 WebM with ffmpeg's -noautorotate, and ffmpeg still read -90 from the file. Chromium 149 and Chrome 154 played it upright at 1080×1920. Firefox 151 and WebKit 26.5 played it lying down at 1920×1080. It was the only time plain playback of a file that still carried its note went wrong for me.

What I do now is boring. For a thumbnail from a playing video I stay with drawImage. For files I control, I get rid of the note by baking the turn into the pixels once. ffmpeg's default transcode did that for my sample: 1080×1920 out, no rotation tag. For the no-install route I used ImgIng (https://imging.ai/) in Chromium 149 on its size-first preset, and the samples tagged 90, 270 and 180 degrees each came out as 608×1080 with upright pixels and no rotation note.

The 180 one still bothers me. In every cell that failed, that sample came out upside down with its width and height unchanged, so a "wider than tall" check catches nothing. My corner blocks catch it, but only on files I made myself.

I ran a cropped-image DOCX through 5 converters. None got it all right

NullPointerZen — Mon, 12 Oct 2026 08:05:20 +0000

Cropping a picture in Word feels final. You drag the black handles, the part you don't want disappears, and you save. But Microsoft's own support page on shrinking picture file sizes offers an option called "Delete cropped areas of pictures", and that option only makes sense if the cropped part is still sitting in the file. In OOXML terms a document can keep the whole image and add three small settings next to it: crop percentages for each edge (a:srcRect), the display size (wp:extent) and a rotation (a:xfrm rot). Any converter that turns the DOCX into a web page has to read those settings back. I wanted to know which ones actually do, since docs full of trimmed screenshots are exactly what people ask me to turn into pages.

One honest caveat first. I don't have Word on this Mac, so my test file is not a Word export. I wrote the DOCX by hand following the OOXML structure, with seven image cases: plain scaling, an uneven crop on all four sides, a 15° rotation, a screenshot with its bottom cut off, a squashed resize, a crop plus a 90° rotation, and an even 15% crop on every side. The screenshot comes from a fake order admin page I built myself, so the recipient, phone number, address and payment ID under "Shipping info" are placeholders. The photo is a landscape from Wikimedia Commons by Dietmar Rabich, CC BY-SA 4.0.

I ran the same file through mammoth.js 1.13.0, docx-preview 0.4.1, the macOS Quick Look thumbnail and macOS textutil. For a browser tool I used ImgIng's DOCX to HTML (imging.ai) on the same 7-case sample in a Chromium 149 open-source build, going through the site's Chinese-language deployment. Here is what each one did.

Converter	Crop	Scale	Rotation	Cropped part still in the output
mammoth.js 1.13.0	Ignored, whole image shown	Ignored, fills the container	Ignored	Yes, all 7 images are full originals
docx-preview 0.4.1	Right content, drifts off its frame on uneven crops	Correct	Right direction, no space reserved	Yes, behind `blob:` URLs
ImgIng export	Right content, same drift	Correct	Same as docx-preview	Yes, 7 data URIs byte-identical to the originals
Quick Look thumbnail	Ignored, whole image squeezed into the frame	Correct	Correct	Not applicable, it's a bitmap
textutil	All 7 images dropped	n/a	n/a	No images at all (1,380 bytes of HTML)

mammoth was the rough one. It skips the crop completely, so the shipping block I had trimmed off the screenshot shows up right there on the page. The red box is mine.

docx-preview gets the visible content right, which is why its failure took me a minute to spot. Going by the inline styles it writes, it clips the image to the crop area and then scales it up from the element's center. When an edge pair is cut unevenly, the picture drifts. The four-side case slid right and up. The screenshot with only its bottom cut moved up 69.7 px and covered the heading above it, leaving just "Scree" visible. The even 15% crop didn't move at all.

ImgIng landed in the same spot, and I'd rather say that plainly than dress it up. It read the crop content and the display size correctly, and the conversion made 0 non-GET requests. Still, the four-side case drifted by (58, −19) px and the bottom-cut screenshot went up 70.4 px over its heading. The UI gave no warning about crops or rotation either. The bigger catch is in the exported file. It is 9,665,338 bytes, and all seven inline images are the untouched originals. Decode the screenshot and you get the full 1800×1240 PNG with the placeholder phone number and address intact. Hidden on screen is not the same as removed.

What fixed it was baking the crop before converting. A small script cut each media file to its srcRect and then cleared the setting. The DOCX shrank 21.0%, ImgIng's offsets went to (0, 0) and (0, −0.4), and the cropped area could no longer be found in any of the three outputs. In Word itself the equivalent should be that "Delete cropped areas" option, but I haven't tried it without a copy of Word. Pure CSS can only hide the cut part. The bytes still ship with the page.

I didn't test Word, WPS, LibreOffice or pandoc, I only checked ImgIng's export in Chromium 149, and floating images weren't part of the sample. If your docs have cropped screenshots, rename a copy to .zip and open word/media. Full-size originals in there mean the crop never happened, so bake it or retake the screenshot before converting, then look at the line right above any bottom-cropped image.

My PDF came out blank because the load event doesn't wait for fonts

NullPointerZen — Sun, 11 Oct 2026 08:04:21 +0000

I made a one-page placeholder statement to test PDF export, the kind of thing a billing page spits out. The body uses Noto Sans SC and the title uses ZCOOL KuaiLe, a round, playful Chinese display font that's easy to spot when it's missing. Both came from Google Fonts through a <link> tag. My print script did what most snippets online do. It opened the page, waited for the load event and called page.pdf() straight away, in an open-source Chromium 149 build on an M4 Mac. The PDF looked fine at a glance, except the title was in PingFang, the Mac system font. I ran it again in a fresh browser. Same thing, 3 times out of 3. Then I dropped display=swap from the font URL, and the PDF came back as 1,073 bytes of nothing. A blank page, no text layer, no error, also 3 out of 3.

That sent me back to a question I had never really asked. When the browser prints, where do its fonts come from, and are they ready at that moment? On a page like mine there are three sources. System fonts are already on the machine, so they're ready, but they're whatever that machine has. Remote web fonts have to be downloaded, and load doesn't wait for them. The Google Fonts version of my page pulled 16 woff2 slices, 412,984 bytes in total, because the CSS splits the font by unicode-range and only fetches the slices the page uses. At the moment load fired, 13 of the 101 Noto slices were still loading. Fonts bundled with the page are the third source, and I assumed they'd be instant. They weren't.

What to look at in this one is the title line. The top PDF was printed the moment load fired, and the rounded KuaiLe title is simply gone, replaced by the system font. The body text looks normal, so if you only skim the PDF you'd never notice.

This one is the version without swap. The default font-display treats the font as blocking, so while it's still downloading the text is drawn invisible. Print during that window and you get the empty page on the left, with no warning at all.

For the bundled case I put the two TTF files in a fonts/ folder next to index.html and pointed @font-face at them with relative URLs. Printing right after DOMContentLoaded in a cold browser, the body text and the table text vanished in 4 of 8 runs. Only the KuaiLe title and the empty table lines were left, 6,476 bytes. One earlier run came out fully blank. Printing after load was correct every time, 71,102 bytes. Local files were faster than Google Fonts, just not fast enough for a print call fired that early.

Two waits fixed the remote case. Printing after networkidle, or after load plus await document.fonts.ready, gave the correct 117,799-byte PDF in all 3 runs each. I went with fonts.ready because it waits for the thing I care about. My script now also logs how many fonts are still loading before it prints.

const pending = await tab.evaluate(() =>
  [...document.fonts].filter(f => f.status === 'loading').length);
console.log('fonts still loading:', pending);
await tab.evaluate(() => document.fonts.ready);
const pdfBytes = await tab.pdf({ format: 'A4', printBackground: true });

Code notes: tab is the page I opened. document.fonts lists every font face the page declared, with a status for each, so the first line counts the ones still in flight. In my runs it was never zero right after load, so I keep the log line in. document.fonts.ready is a promise that resolves once nothing is loading anymore.

Then I wanted to see what happens on a machine I don't control. I used ImgIng (https://imging.ai/) HTML to PDF with the same placeholder statement, importing it once as a single file and once as a whole folder. Import and preview happen in the browser. When you click convert, it sends one POST with a script-free snapshot to a server-side Chromium 151 on Linux. I counted 0 non-GET requests before the click and exactly 1 after. For pages with @font-face rules, its quality report says it waited for document.fonts and the page images. Remote fonts still never made it. With the network toggle off, which is the default, the report said the remote resource was blocked. With it on, the preview downloaded the fonts, but the snapshot kept the <link> as is, and the server PDF used Noto Sans CJK SC. Inlined fonts weren't a sure thing either. The full 3.27 MB KuaiLe file didn't show up in the server PDF, while a 48 KB subset of the same font did. I can't tell why from the outside.

What I haven't tested is Firefox and WebKit printing, the real Chrome print dialog, and folder fonts with font-display: swap. If you print pages to PDF, log the loading count before page.pdf(). Don't print until it reaches zero, then open the PDF and check the title font.

I tried 13 OCR preprocessing tricks on screenshots. None helped

NullPointerZen — Sat, 10 Oct 2026 08:04:58 +0000

Almost every OCR tip I found said the same thing. Before recognizing a screenshot, clean it up: go grayscale, binarize it, run a denoise filter, maybe upscale it 2x. I had never checked whether any of that actually helps, so I took one small set of screenshots and ran every trick on the list, one at a time, against text I already knew. On clean screenshots, not a single step beat the untouched original. Several of them made things a lot worse.

The samples were boring on purpose. I wrote a small web page, a made-up Chinese notice about community service hours, and screenshotted parts of it at 1x and 2x device pixel ratio: 16 px body text, 12 px sidebar text, 11 px light-gray footer text (#999 on #f5f5f5), and a 13 px fee table. I added two crops from a holiday notice template I found online, white text on red. That gave me 10 crops with an exact answer key. For recognition I used ImgIng (https://imging.ai/), with its default Professional OCR tier plus Fast OCR and Ultimate OCR on every version, in a Chromium 149 open-source build on an M4 Mac. As a reference engine I ran tesseract.js 5 with default parameters and chi_sim+eng. Recognition runs in a local Worker, and across roughly 800 runs I saw zero non-GET requests. The first run of each tier does download a model.

The score is character error rate: edit distance divided by the length of the answer, summed over all 10 crops. Here is every version side by side.

Look for the short bars first. The original scored 0.1% on Professional OCR. The only versions that matched it were grayscale at 0.1% and the built-in "Scan enhancement" switch at 0.2%. That switch describes itself as "Gentle grayscale, contrast and sharpening; no forced binarization." It didn't lower the error rate on this set, and that seems fine to me, because the steps it skips are the ones that cost the most. Everything else added errors. The small losses were a 2x upscale (0.6%), JPEG re-saves at quality 60 and 30 (0.8% and 1.1%), Otsu binarization (1.1%), a fixed threshold of 200 (1.2%), adaptive thresholding (1.4%) and non-local-means denoising (2.7%). The big losses were a 3×3 median filter at 9.7%, threshold 160 at 9.4%, threshold 128 at 25.8% and threshold 100 at 32.2%.

Threshold 128 looks like a sensible default, so I went back to see what happened. The gray footer text is simply lighter than the threshold. Its darkest pixel is 153, which sits above 128, so binarizing turns the whole strip white. All three tiers and tesseract.js returned 0 characters from it. So for that strip I got an empty result rather than a handful of typos.

The median filter fails in a quieter way. On 12 px text captured at 1x, the strokes merge into blobs. My guess is that a 3×3 window is about as wide as a stroke at that size, but I only looked at the output. That single crop went from 0% to 32.4% on Professional OCR.

I also expected the tiers to matter more than they did. On the originals, Fast, Professional and Ultimate landed at 0.8%, 0.1% and 0.7%. They are less than one point apart. Threshold 128 moved every tier by about 25 points. Picking the wrong filter hurt far more than picking a different tier. Preprocessing didn't clearly help tesseract.js either. Its original scored 6.2%, and its best version was the 2x upscale at 5.8%.

Vertical text needs its own paragraph, since every tier scored a scary 92.3% on my four-column sample. The characters were fine, though. Counted without regard to order, Professional OCR got 0.0% to 7.7% wrong. The columns came out left to right, while this kind of vertical text reads right to left. None of the binarizing, denoising or upscaling variants fixed that, and they all stayed between 89.7% and 94.9%. What fixed it was the rotate-left-90° button in the image adjustments. After rotating the 2x screenshot, all three tiers read it with 0 errors. On the smaller 1x capture, Fast and Professional still dropped two punctuation marks, which works out to 5.1%.

This covers clean screenshots only. I ran each combination once, so a 1-point wobble means nothing, and I haven't tested real phone photos yet. Still, my routine changed. I recognize the untouched file first and keep that result as a baseline. If I really want to binarize, I measure the darkest gray in the text before picking a threshold, and I compare the output against the baseline instead of assuming it improved. If the text runs vertically, I rotate it before I touch anything else.

256 colors turned a soft PNG shadow into a black band. I tried 4 fixes

NullPointerZen — Fri, 09 Oct 2026 08:15:08 +0000

I cut a transparent sticker PNG down to 256 colors and dropped it on a white page, and its soft grey shadow came back as a solid black band with a hard outer edge. On a black background the same file looked almost normal. I'm not a graphics person (I studied literature and drifted into writing internal tools), so I skipped the palette theory and just tried every fix I could, scoring each by file size and by how far the semi-transparent pixels drift from the original on white. The drift is the mean absolute RGB difference (0 to 255) over pixels that are semi-transparent in the source, after straight-alpha blending onto the background.

The sample is a pink ribbon sticker with a big soft shadow, 760×1662 and 441,038 bytes, a third-party image from Wikimedia Commons (by K B, CC BY 2.0). I only show its top loop. A Noto Color Emoji face (Apache 2.0) was my second sample. Everything ran on an Apple M4 Mac.

The black band comes from two alpha levels

First I counted distinct alpha values per file with Pillow and NumPy.

for img in sys.argv[1:]:
    alpha = np.asarray(Image.open(img).convert("RGBA"))[..., 3]
    soft = ((alpha > 0) & (alpha < 255)).sum()
    print(f"{img.split('/')[-1][:28]:28}  levels={len(np.unique(alpha)):3}  soft={soft:>7,}")

ribbon.png                    levels=256  soft=225,652
ribbon-png8-default.png       levels=  2  soft=      0
ribbon-34-levels.png          levels= 34  soft=215,937
ribbon-q84.webp               levels=256  soft=225,652

The original has 256 alpha values and 225,652 semi-transparent pixels, 17.9% of the image. The second file is the PNG-8 that ImgIng's image compressor gave me on 2026-09-30 with default settings (256 colors, dithering on), and only two alpha values are left. Every pixel at 128 or above became opaque and everything below became fully transparent, matching a plain 128 threshold pixel for pixel on both samples. The shadow's dark core turns into a block and its faint rim vanishes. ImgIng's png-compress page says its transparent PNG-8 supports multi-level alpha, but the files I exported that day had two. The background matters too. On white the two-level ribbon scores 44.17, on blue #1976D2 it's 20.79, and on black only 2.33, because a near-black shadow disappears into a black page. Preview only on dark and you'll miss it.

More alpha levels bring the soft edge back

The format isn't the limit. An indexed PNG's tRNS chunk gives every palette entry its own alpha, so I wrote a rough reducer of my own that keeps some palette slots semi-transparent. It isn't pngquant or any product's output, so compare its sizes only with each other.

Each bar is the same ribbon on white, shorter is closer. Ten alpha levels drop the error from 44.17 to 8.23 and 98 levels reach 1.75. At 10 you still see contour rings in the shadow, while 98 is close to the source. Size barely moved: 111,178 bytes for two levels, 121,346 for 34, about 9.1% more. A Chromium 149 open-source build, Firefox 151 and WebKit 26.5 (not a Safari release) all read back the same 34 levels as Pillow.

Dithering only made the file bigger

On the two-level output dithering never touches alpha. The alpha channel was identical with it on or off and the white error stayed at 44.07 versus 44.06, while the ribbon grew from 93,317 to 148,242 bytes and the emoji from 11,213 to 23,528.

Left is the original, middle my 34-level file, right the same with Floyd-Steinberg dithering on color and alpha. The steps turn into grain and look smoother, but stray light dots show up in the pink where solid pixels went semi-transparent. Error rose from 3.48 to 4.29 and the file grew 65% to 200,717 bytes. The number of alpha levels decides the edge, not dithering.

WebP kept every alpha level

For the WebP conversion I used ImgIng (https://imging.ai/) at its default quality 84 in the same Chromium build, and the ribbon went from 430.7 KB to 98.8 KB with alpha matching the original pixel for pixel, error 0.61 on white, black and blue. It ran in the browser tab with zero non-GET requests during export. Color is still lossy, and on the emoji the 4.02 error came from color while all 17 alpha levels survived. The same tool's default PNG-8 was 144.8 KB with the band.

My order now is simple. Soft shadows, glows or feathered edges go to WebP, and I run the script above on the result. If it must stay PNG-8, the palette needs dozens of alpha levels, and I leave dithering alone. I check on white and on a color, never only black. Colored shadows, glassy art, pngquant, low color counts and social-app recompression are all untested, and two images make a way to check your own files, not a rule.

One PDF said no printing or copying. Each reader obeyed differently

NullPointerZen — Thu, 08 Oct 2026 08:04:31 +0000

A PDF that opens without asking for anything can still be encrypted. I ran into it with a file I had made myself: a tool called it "encrypted" while every viewer I had opened it instantly. The file only had a permission password. The user password was empty, so any reader unlocks it silently, and the permission flags inside say what you may not do: print, copy, edit. Whether those flags mean anything depends on who reads the file. So I made seven two-page placeholder PDFs myself, a fake "Sample Agreement" with no real content, and fed them to five different handlers to see who actually enforces what.

I tried the same files in five handlers

One file had no encryption at all. Five had a permission password only, with different ciphers (AES-256, AES-128, RC4-128 and RC4-40) and different flags: some denied everything, one denied only copying, one denied only printing. The last one had a real open password. The handlers were the built-in viewers of Chromium 149 (an open-source build) and Firefox 151, Firefox again with its pdfjs.enablePermissions setting turned on, pdf.js 6.3 used as a library in a page, and PyMuPDF 1.26 as a processing library. Here is the whole result for the file that denies everything.

Read it row by row. Green means the handler refused the action, orange means the action still worked, grey means the handler just passed the flags to the calling code. No two viewer rows match.

Chromium still allowed drawing

Out of the box, Chromium enforced more than anything else I tried, and still not everything. Dragging across the text gave the normal blue highlight, which made me think copying worked. Pasting into a text box gave me nothing. The unencrypted twin pasted all four lines. Printing was blocked in a quieter way: the print button stayed visible, and on the four files that deny printing, clicking it did nothing. I never saw a real print dialog in this build, so "blocked" here means the click had no effect. The part that surprised me was drawing. All seven files, including the ones that deny annotation, let me enter drawing mode, leave a stroke and light up the undo button. I did not try saving the result.

Firefox enforced nothing by default

With default settings, Firefox 151 printed, copied and opened every edit tool on all seven files. After I turned on pdfjs.enablePermissions, it hid the print button on the files that deny printing and greyed out the edit tools on the files that deny editing. Copying still worked, even on the file whose only restriction was "no copying". The toolbar change is easy to see side by side.

The cipher changed nothing

I expected RC4 versus AES to matter somewhere. It didn't. The AES-256, RC4-128 and RC4-40 files carry the same flags and behaved identically in Chromium and in both Firefox modes. Only the flags changed the outcome. The open-password file is a different animal: both viewers stopped at a password prompt, and after I typed the password, Chromium still refused copying and printing, because the flags apply after opening too.

Processing tools have to pick a side here too. The compressor I used was the PDF one on ImgIng, with my permission-only and open-password test files as input. It processes PDFs on the device, and my run made zero non-GET requests. Every encrypted file I gave it failed with the same message: 这份 PDF 有加密或权限保护，需要先解除保护 ("this PDF has encryption or permission protection; remove the protection first"). The file that only denied copying failed as well. The interface doesn't say why it refuses, and oddly the progress card still read "全部完成" (all done) with zero files compressed. I tested the Chinese version of the site, so that's where the quoted text comes from.

My takeaway after all this is modest. A permission password is a request that each reader decides how to honour, and the answers differ a lot. If you send PDFs, don't treat the flags as a guarantee, since the same file was copy-protected in one viewer and not in the other. If you receive one and need an editable copy, ask the author for a version without restrictions, or, if the file is yours and you remember the owner password, re-export it from the software that created it. I didn't test Acrobat, macOS Preview or release Safari, so check those yourself before you rely on them.

Changing the preview background exposed my empty video screenshot

NullPointerZen — Wed, 07 Oct 2026 08:04:07 +0000

Before changing a video conversion setting, I would change the background behind its failed screenshot. That sounds cosmetic, but it answered a useful question in my test: was the image black, or was I looking through an empty image at a dark surface? The two can look similar in a preview. They are different things to hand to another tool, and exporting again can make the distinction harder to see.

I used a short public clip of waves on an Icelandic beach. The test copies were six seconds long, 640×360, and had no audio. One was an H.264 MP4 and the other a VP8 WebM. I opened them through a small local HTTP page that could draw the video into a canvas at different loading stages. This was a controlled reproduction, not a claim about a particular editing application losing someone’s footage.

The early capture looked empty even though the page already knew the video dimensions. Pixel inspection made that concrete: after loadedmetadata, every alpha value in the resulting canvas was zero. Across Chromium 149, Firefox 151, and a WebKit 26.5 test build, ten runs per format gave 60 such outputs from this first source clip. Drawing did not throw an error. A checkerboard behind the image simply became visible through it.

Waiting until loadeddata changed those same HTTP tests. All 60 outputs then contained opaque, non-black waves. That was enough to make me check when the picture was being taken before converting the input to another format. Both versions had failed at the early stage and produced a picture later. It was not evidence that MP4 or WebM is always the better thumbnail source; it was a reason to leave the file alone while checking the capture timing.

This illustration comes from a separate Chromium check of the empty canvas. The PNG decoded with zero alpha. A JPEG made from that same empty canvas decoded as opaque black: RGB zero and alpha 255. The checkerboard is the test page’s background, not pixels in the video. This page is an independent reproduction and is not an ImgIng export screen. The JPEG result was checked in Chromium only, so I would not silently apply it to every browser and export pipeline.

That changed which file I would retain while troubleshooting. I would keep the transparent PNG as evidence instead of using only the JPEG someone sees against a black page. The JPEG has lost the visible clue that the original canvas was empty. Once all I have is opaque black, I need the input video and capture position to distinguish a real dark frame from an earlier empty drawing. A format change can conceal useful information without fixing the capture.

I also checked a real product preview with ImgIng, operating the Chinese video-matting Beta workbench. The six-second wave video displayed, and I moved to 2.117 seconds before running the current-frame preview. It returned a message that no obvious subject had been recognized. That is another reason to retain the exact result text: it describes the subject-processing stage, not necessarily a missing video frame. I did not test a thumbnail export there or compare matting quality.

There is a limit to the background trick. I added a one-second black introduction to the six-second waves as another controlled clip. Its first loaded frame was genuinely black and opaque in one run per engine. Changing the preview background could not reveal scenery through it. Choosing a later position would change the content being captured; waiting for more loading would not make the selected black opening become a different scene.

The source is Alexander Grebenkov’s Ocean waves at Lækjavik beach, Iceland, under CC BY 3.0, trimmed, resized, and transcoded for these tests. I did not shoot it, and the WebKit test build was not released Safari. For a failed cover, I would first save a PNG, inspect its alpha, and compare the selected moment with the original video. Then I would repeat the capture after current-frame data arrives. That sequence preserves the clue that a dark preview can otherwise hide.

My WebM said Infinity, but the recorded video was still there

NullPointerZen — Tue, 06 Oct 2026 08:03:59 +0000

The player showed an ocean, but its duration was Infinity. I had recorded only a few seconds, so that value looked more alarming than the picture did. Before discarding the WebM, I wanted to separate two questions: had the recording lost its video, or was the player unable to report a useful length at that point? The visible waves were already a reason not to treat those questions as interchangeable.

For the test, a short section of an existing waves video was drawn onto a canvas and recorded through MediaRecorder. This was not a webcam recording or a capture of my desktop. Each of three browser engines produced a WebM recording lasting roughly four seconds, with recording chunks collected into the completed file. I then opened those files in different playback engines. I kept the original recordings rather than replacing them with conversions straight away.

I also used ImgIng during this video check, selecting a size-prioritizing MP4 export in its Chinese compression workbench. That separate operation completed and produced a real output file. It was not the duration repair used below. Keeping the results separate matters: a successful conversion in a tool does not tell me what was wrong with an earlier WebM recording, and I did not verify an ImgIng feature that repairs missing duration information.

The left-hand player contains the recording made by Chromium. The right-hand player contains a remuxed copy of that recording. Both were freshly loaded over local HTTP in Chromium 149 for this screenshot, and the displayed values were read after loadeddata: Infinity on the left, 3.912 seconds on the right. Both pictures contain actual decoded waves. This is a controlled playback page, not the product interface, and the screenshot does not measure how accurately either player seeks.

The file inspection gave the comparison something firmer than a changed readout. The original Chromium recording had no Duration element in its Info section and no Cues. The remuxed file had both. Remuxing here meant copying the existing encoded media packets into a new container layout with FFmpeg, rather than encoding the pictures again. The encoded-packet hashes matched before and after. I did not need to claim improved picture quality to explain the changed duration display.

Changing the playback engine also changed the answer. For this same original Chromium recording, Firefox reported 3.464 seconds and WebKit reported 3.950 seconds at the measured loading point, while Chromium reported Infinity. After remuxing, all three reported 3.912 seconds. Other recordings in the small test behaved differently again: one raw recording appeared only 1.093 seconds long in Firefox, and a request to seek to three seconds was clamped to that shorter position. A displayed length can therefore affect what the player lets me do without proving the video packets have disappeared.

I am keeping the claim narrow. Each recording and playback combination was tested once in the main comparison. The English screenshot was a later reload of an existing pair, not another set of recordings. The engines were Chromium 149, Firefox 151, and WebKit 26.5, with WebKit being a test build rather than released Safari. This does not show that remuxing repairs every WebM, nor does a finite duration prove that every target frame can now be reached correctly.

The footage is a shortened, resized recording derived from Alexander Grebenkov’s Ocean waves at Lækjavik beach, Iceland, used under CC BY 3.0. I did not shoot it. If I hit this symptom in another tool, I would first save the original, check whether it contains visible video, and compare the reported duration in another player. Then I would try a remuxed copy and test duration and seeking separately. Infinity is a useful clue here, not a verdict that the recording is empty.

I tested the OCR switch instead of trusting its label

NullPointerZen — Mon, 05 Oct 2026 08:04:44 +0000

An OCR checkbox is easy to overinterpret. I see it next to a PDF extractor and assume it will recognize the page again when the existing text is broken. That assumption deserves a test. In a controlled example this week, enabling the checkbox produced exactly the same damaged text as disabling it. The tool reached its completed state both times. The Chinese sentence I needed did not return.

The useful question turned out to be narrower than whether the application “supports OCR.” I wanted to know whether this particular option replaced an unreliable text interpretation with a fresh reading of the visible page. Those are different claims. A feature label cannot tell me which one happened, but comparing the actual output can. This post follows that comparison and the separate image-recognition step that eventually gave me usable text.

The input was a synthetic one-page notice, created for testing rather than taken from someone’s company documents. It contained five lines of Chinese and English, including a holiday interval, a return date, and a deadline. One copy retained its font’s ToUnicode mapping. In another copy, that mapping was removed without changing the page’s drawing instructions. This let me compare two known inputs rather than guess what an unfamiliar PDF originally contained.

Under the same MuPDF rendering conditions, both copies produced identical 893 by 1263 pixel page images. Text extraction told a different story. PyMuPDF, pypdf, and PDF.js each recovered 56 Chinese characters from the normal copy and none from the missing-mapping copy. English and digits survived. I therefore had a precise failure to test: could the browser tool recover the missing Chinese content, rather than merely produce another nonempty result?

I chose a sentence containing both Chinese words and dates as the comparison target. Checking only the year would have been misleading because the broken output still contained numbers. I also kept the unedited output from each attempt. That made it possible to distinguish an actual improvement from a nicer preview, a different line break, or a newly enabled export button. I wanted changed evidence, not a changed interface state.

For the browser portion I used ImgIng, an image and document utility with a public homepage at imging.ai. The tested deployment was its Chinese site, imging.cn, on September 30, 2026. I have not repeated the entire PDF workflow on the international domain. The result screenshot below came from switching that tested tool to its English interface and rerunning image recognition on the same test image.

In the PDF content extractor, the option specifically referred to recognizing text inside images. I processed the missing-mapping PDF once with it enabled and once with it disabled. The resulting text was identical. The title retained its year, parts of the body retained dates and odd characters, and the English line remained readable. Whatever the tool’s internal decision was, this option did not replace the damaged native Chinese text in this sample.

That finding does not establish that the checkbox never works. I did not test every combination of scanned pages, embedded images, and native text. It does establish a stopping point for this input. Repeating the same operation with the same setting would not be evidence of a new recovery route. I needed either a different extraction result or a correctly rendered page image that an independent recognition step could actually inspect.

I tried the PDF-to-image route in the same product next: one page, PNG, and 216 DPI. It failed with “SVG render failed.” This matters because the later OCR result would be easy to present as one uninterrupted success story. It was not. The usable PNG came from an existing external rendering step. It was 105,697 bytes and recorded as a 216 DPI page image. It was not downloaded from the failed online conversion.

I then imported that clear image into the separate Image OCR tool. The default Professional tier returned five lines, with 134 characters reported by the interface. The holiday dates, return date, deadline, and Chinese wording were available for inspection again. That count is not an accuracy percentage. I compared the actual lines against the visible source, and spacing within the Chinese text differed from the PDF’s original spacing.

The distinction between these two OCR operations is the recommendation I would keep. If native extraction is already correct, I would use it. If it is wrong and a clear page image exists, a separate image-recognition step is worth testing. Before relying on an OCR option inside a PDF workflow, I would check whether the disputed sentence changed. The presence of a checkbox, a completion badge, or an export format does not answer that question.

There is also a limit to judging by readability. A separate controlled variant changed the mapping for the Chinese character 假 to 真 while leaving the visible glyph unchanged. All three extractors agreed on the wrong text, with two affected occurrences. The result still contained Chinese and had the expected Chinese character count. Agreement between tools was therefore useful diagnostic information, but the visible source remained necessary for checking meaning.

My browser automation captured the result previews and their text. An attempted save action did not produce a download event in that automated run, so I am not claiming that every local save dialog was verified. Likewise, obtaining OCR text did not repair the original PDF’s mapping or create a new searchable PDF. Those would be additional output requirements. Keeping the original file, the recognition image, and the checked text separate made the limits easier to see.

For a quick test on your own material, choose one disputed sentence before changing tools. Preserve the original extraction, run the proposed alternative, and compare the same words rather than overall character counts. If the route switches to images, confirm that the image is actually readable before recognizing it. Finally, check the text where you intend to use it. That last check catches the unglamorous mistakes, including copying an older result after the newer one finally became correct.

Canvas memory starts at draw

NullPointerZen — Sun, 04 Oct 2026 08:04:03 +0000

I build small internal tools for a content team, and one of them stitches large images on a canvas. When someone asked how big an image it could take before the tab fell over, I realized I had no idea what a canvas actually costs in memory. So I measured it in three engine builds: the Chromium 149 open-source build (not Chrome itself), a WebKit 26.5 build, which is not Safari, and a Firefox 151 build that isn't release Firefox either. Treat every number here as belonging to those builds only. The machine was an M4 Mac with 16 GB of RAM that was busy with other jobs at the same time. All images were synthetic ones I generated with a script, not photos.

How I measured canvas memory

Browser APIs were no help here. performance.measureUserAgentSpecificMemory refused to run in the Chromium build even with cross-origin isolation on, and the other two builds don't have it. The JS heap size shown in DevTools barely moved while a gigabyte-sized canvas sat in memory. So I went one level down and summed phys_footprint from macOS footprint for every process the browser launched, then subtracted the idle page. It's a blunt number, but it's the only one that actually saw the canvas. For a reference point on real in-browser processing I used ImgIng (https://imging.ai/) with a 10000×10000 synthetic JPEG, operating the Chinese-language interface in all three engines. Across its 12 test runs the network log showed zero non-GET requests.

Creating a canvas costs almost nothing

Setting width and height and calling getContext('2d') added less than 1 MiB in all three engines, even for large sizes. Memory shows up on the first draw. After one full-size fillRect, Chromium and Firefox grew by exactly width × height × 4 bytes: a 16384×16384 canvas added 1025 MiB. Reading the whole thing back with getImageData added another copy of the same size, which took Chromium to 2050 MiB above idle. WebKit had its own overhead on top: the same 16384×16384 canvas reached 3265 MiB after the full readback. If you pull pixels out of a big canvas just to loop over them, you are paying for the image twice.

Decoding a big JPEG costs more than the file

A 13.4 MB JPEG at 100 megapixels looks harmless on disk. Decoding it pushed the summed process peaks to 1289 MiB in Chromium, 1550 MiB in Firefox and 3525 MiB in WebKit. Those are peaks added together across processes, and they don't necessarily happen at the same moment, so they overstate how much is held at once.

Many canvases in a row

I kept creating 4096×4096 canvases and holding on to all of them. None of the three builds crashed or lost a canvas before my own safety stop at 7 GiB with solid fills, or 4 GiB with noise. I stopped there on purpose because the machine only has 16 GB, so I still don't know where the real ceiling is. One thing surprised me: with solid colors the system's free memory barely dropped. My guess is macOS memory compression, but I didn't capture the compressor numbers, so that stays a guess.

What I changed in my tool

I budget memory per image as width × height × 4 before drawing anything, then double it if the code needs getImageData on the full canvas. For anything near 100 megapixels I check that budget first and scale down when it doesn't fit. I also stopped reading back whole canvases when I only need a few pixels.