Kissaki

I didn't add a star at the end for the word search, so at least for that example, the sarcastic ones were all 'amazingly' and consequently not counted, and the 'amazing' at the end seems literal. I haven't looked at any other cases, though.

Glad you're so appreciative and worked through it! I gladly share, discuss, and respond.

I'll have to read up on palette filters. :) I do semi-regularly use ffmpeg, but palette filters are not something I have heard or used before.

I assume in this case it's a downsampling into fewer colors, evading the issues of almost-same-colors?

Especially given the last square/check pattern makes me thing of codecs splitting into square blocks and then encoding those. It could make sense that this division leads to different results for one reason or another, which then produces a check pattern without it being there before.

For comparison, "amazing" occurs six times.

Only one of them barely reaching 200. For the size of the Linux kernel I find these numbers surprisingly low.

I don't see a sharp drop as a sign of corporate oversight at all.

Stuff may be tackled en-batch. Or individuals can care. Or it can be an organic team decision or effort.

1, 2, 4, 5, 6 all look fine resized in the post and full size

3 looks fine full size but has slight visual artifacts resized in the post (check/square pattern)

collapsed inline media

I can barely see it on my monitor. So on worse monitors it may not even be visible. #272a31 vs #262b31

animated webp may also be an option

The screenshot is from my desktop with wide enough screen on Lemmy web (programming.dev).

The issue is one of scaling.

When I open the image without being resized into the website layout, it has the following visual pattern:

collapsed inline media

When I zoom out to 50% it looks (almost?) fine

collapsed inline media

Did you scale the source with ffmpeg? Do you have a visual pattern in your console background? The simplest solution would be to have a solid color as background. The second best to render a small enough size that it does not get resized in the browser.

At 1920x1038, it's very big right now. I'm surprised the font is big enough to be readable. I assume you scaled it up or have a high dpi display resulting in this.

That visual pattern compression though

collapsed inline media

Supporting soft subs is a complex topic though. Three formats, font embedding, positioning and animations. It's a ton of effort, and anything less than "full featureset support" will mean they don't render how you design them in your full-set editor and local media play. And there will be differences and bugs, at least for a while. I suspect font rendering with various fonts in a media render context will have it's own set of issues.

I also think it'd be nice, but I can totally see how it may not make sense technically (complexity with its burdens vs need) or economically.

Browsers are already absurdly complex though so… maybe? :P

It doesn't open with a summary or overview but dives right in to exploration, but I think the point comes across:

The copy and paste key codes, which have no physical keys anymore, are - to a degree - supported in software. Their claim is that those key codes are the tool for universal copy and paste, and then it's the input interpretations job (key and combination mapping) to offer bindings to those key codes.

GTK added support the copy and paste keyboards in January 2025. QT also added support for copy and paste key codes the same month. I'm not sure of the first released version of the GTK toolkit that will contain the fix. For QT, it will be QT 6.10, scheduled for release in September 2025. Together, this will cover many apps built for Gnome and KDE as well as others that use the same toolkits.

… followed by some more "current state of support for those key codes".

merge

The HackerOne report that does not even apply has 44 upvotes.

collapsed inline media

What do upvotes mean on HackerOne?

I guess, at least here, they're mindless "looks interesting" or "looks well worded" or something?