Browsers typically say below the styles also which fonts are actually used (there can be multiple, e.g. when substitution is required to render certain characters).
That's a great analogy. For me it is a very similar feeling that I get ripped out of "problem solving mode" into "code review mode" which is often a lot more taxing for me.
It also doesn't help reviewing such code that sometimes surprisingly complex problems are solved correctly, while there's surprisingly easy parts that can be subtly (or very) wrong.
A hard pill to swallow is that a lot of software developers have spent most of their careers "behind the code" instead of out ahead of it. They're stuck for years in an endless "Junior Engineer" cycle of: try, compile, run, fix, try, compile, run, fix--over and over with no real understanding, no deliberate and intentional coding, no intimacy, no vision of what's going on in the silicon. AI coding is just going to keep us locked into this inferior cycle.
All it seems to help with is letting us produce A Lot Of Code very quickly. But producing code is 10% of building a wonderful software product....
Yes you're correct. My memory is a bit fuzzy but it the fact is in the article
> While Skia uses DirectWrite on Windows for certain functionality such as font lookup, the final text rasterization is actually handled directly by Skia. And one major factor in the "washed out" feedback from users is the internal contrast and gamma settings for text rendering.
> Two main differences in text contrast and gamma values were uncovered between Edge's Chromium-based engine and its prior engine. First, Skia does not pick up text contrast and gamma values from the Windows ClearType Tuner. Secondly, it uses different default values for text contrast and gamma than those used by Edge's DirectWrite-based text stack.
I was debugging blurry text in windows at a previous job where we used electron to develop a softphone application and could not understand why the lighter text was harder to read on windows. That would settle the debate.
I hope they will come up with better integration with windows so these differences will disappear.
Wooden building construction for single-family homes is not unusual here (Germany) either, especially for prefabricated buildings. It's cheaper than bricks or premade concrete elements and easier to insulate. From the outside you usually won't see a difference.
I've never seen that on my side in France, the only way you would get a wooden house is some cottage in the middle of the mountains and even that, they are usually only coated wood and are actually made of concrete or rocks behind.
The old houses are made with rocks and the new ones with concrete. The wood is usually just a decoration on top.
Considering that cladding/siding is independent of the construction method, it may not even be visible. Even prefabricated buildings made from wood might have plaster outside, just as concrete buildings could be clad with wood.
Yes that's possible, however the usual fashion is to have the top of the house plastered wood and the bottom left in concrete or rock so you can guess how it's made.
So we end up in a world 20 years from now where most applications still don't use that. I guess the main problem as described here is the mapping, as argument splitting was just one of the possible things that break (next to argument validation or bad file names).
That file was able to lock up or crash most SVG renderers back then.