Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory safety for web fonts

developer.chrome.com

Post reply on HN
Print view View original

191–200 of 230 posts

Re: Memory safety for web fonts

#191

Post by codedokode »

steveklabnik wrote: post #189
codedokode wrote: post #188

> Fonts are passed through the OpenType Sanitizer prior to processing. Are font formats so bad that the files need to be sanitized? Also, note that the identified integer overflows as one of causes of vulnerabilities. It is sad that today many languages do not detect overflows, and even modern architectures like RISC-V do not include overflow traps although detecting an overflow doesn't require many logic gates. C is…

Rust traps on overflow in debug mode, and does two’s compliment overflow in release mode. You can turn the traps on in release if you wish, but the cost is deemed too expensive to do so by default, especially when bounds are always checked, so it isn’t as severe of an issue in Rust.

This becomes a vicious circle. Language developers do not want to make the language safer because legacy CPUs do not support overflow trapping, and CPU designers do not bother to add it because nobody needs it. For example, RISC-V spec says that they decided to not add overflow trapping because it is "easy" to do in 3 or 4 existing instructions.

Re: Memory safety for web fonts

#192

Post by mook »

slyzmud wrote: post #84
fresh_broccoli wrote: post #28

It's very annoying that Google's websites, including this blog, are automatically translated to my browser's preferred language. Sillicon Valley devs clearly believe that machine translation is a magical technology that completely solved internationalization, like in Star Trek. No, it's far from it. Ever since internet has been flooded with automatically translated garbage, the experience of international users, at l…

The worst offender to me is Google Maps. I'm a native Spanish speaker but set my phone to English because I hate app translations. The problem is when I want to read reviews it automatically translates them from Spanish (my native language) to English. It doesn't make any sense!

At least it's still Latin. In places like Korea, the roads are often only in transliterated Latin alphabet, so if you read the local language (and know places in that language) you'd need to transliterate it back to know what it's saying.

This despite Google already knowing what languages I can read…

Re: Memory safety for web fonts

#193

Post by emidoots »

raggi wrote: post #183
maxdamantus wrote: post #173

I hope that if we switch away from FreeType, we'll still have a way to use TTF hinting instructions fully. Windows/macOS don't seem to have a way to enable proper hinting anymore [0], and even FreeType (since 2.7 [1]) defaults to improper hinting (they call it "subpixel hinting", which doesn't make sense to me in theory, and practically still seems blurry, as if it's unhinted). In case anyone's wondering what properl…

I really want hinting, subpixel and anti-aliasing available on all systems, and i want to pick the appropriate set of techniques based on the dpi and font size to minimize error, fuzzy excesses, and balance computation cost. Obviously we still don't all have high DPI all the time and likely won't for a long while. Apple dropping support was a disaster, and I currently run Apple devices plugged into to regular DPI scr…

If you want consistency, you only need to convince everyone to switch to a single font renderer (e.g. freetype). That won't happen, though, because OS font renderers have quirks that cause them to render the same things in subtly different ways, and users have come to unintentionally expect those quirks. Even if rendering is 'better' in one app.. if it doesn't match the others or what the user is used to.. then it won't 'feel native'.

Maybe if what freetype is pushing for (fonts are WASM binaries) continues to take hold, and encompass more of fonts, we'll find more consistency over time though

Re: Memory safety for web fonts

#194

Post by glandium »

steveklabnik wrote: post #74
ameliaquining wrote: post #68

Earlier quoted context omitted.

IIUC word tearing in Java cannot cause arbitrary memory corruption. Any read is guaranteed to see either the old value, or the new value, or half of each. Since these are just numbers we're talking about, not pointers, and the language doesn't otherwise allow memory-unsafe things like pointer arithmetic, a data race resulting in word tearing in Java can at worst result in a runtime crash or a logic bug, not arbitrary…

Yes, you are correct that Java's guarantee is stronger. > By contrast, in Go, all it takes to cause full-blown undefined behavior, in the same sense as C or C++ or Rust It's a little more tricky than that. UB in C/C++/Rust is something that the compiler can use to transform the code. This can lead to other issues. Go's compiler will not do those kinds of things. So on one hand, yes, it can lead to arbitrary Bad Thing…

> Go's compiler will not do those kinds of things.

Go's compiler is notorious for choosing to compile quickly rather than optimize code.

But is that true of gccgo?

Re: Memory safety for web fonts

#196

Post by nyanpasu64 »

acdha wrote: post #92
hombre_fatal wrote: post #76

Earlier quoted context omitted.

On the other hand, parceling a large function into smaller functions can create indirection that is even harder to follow and harder to verify as bug-free.

Maybe, but it usually has the opposite effect. If you have well-designed and named functions the indirection is a feature since it reduces the amount of context you need to remember and gives you a visible contract instead of having to reason about a large block of code.

This works if you know what each callee performs, which you frequently don't when you're visiting a new codebase (it may have an unknown function you have to read to know, functionality not relevant to your problem, or you may have to analyze two or more functions in the context of each other to understand a bug).

Re: Memory safety for web fonts

#197

Post by nullpoint420 »

grishka wrote: post #174
da_chicken wrote: post #153

Earlier quoted context omitted.

Apple put all their chips behind Retina/HiDPI displays. To that end, they've got really good HiDPI resolution scaling, they no longer sell displays incapable of Retina features (in laptops or stand-alone), and they have removed features that only serve to support sub-4k displays. To Apple, 4k is the minimum standard. If you want a 2k monitor you can buy one and hook it up, but Apple isn't interested in making it look…

Well, in my particular case, I use an M1 Max MBP with a 2K monitor that I already had when I bought the MacBook. The problem with 27" 4K monitors is that you can't have integer scaling on them. If you set the scaling factor to 1x, everything will be too small, if you set it to 2x, everything will be huge, and macOS can't properly do fractional scaling because what it actually does is render everything into a 2x frame…

Your sights are set on Apple when IMO, they should be aimed at the rest of the display industry.

Why don’t they produce 5K/6K monitors that allow for 2x integer scaling? The $1,600 Studio Display is only $1,600 because it has no competition.

Re: Memory safety for web fonts

#198

Post by snvzz »

codedokode wrote: post #191
steveklabnik wrote: post #189

Earlier quoted context omitted.

Rust traps on overflow in debug mode, and does two’s compliment overflow in release mode. You can turn the traps on in release if you wish, but the cost is deemed too expensive to do so by default, especially when bounds are always checked, so it isn’t as severe of an issue in Rust.

This becomes a vicious circle. Language developers do not want to make the language safer because legacy CPUs do not support overflow trapping, and CPU designers do not bother to add it because nobody needs it. For example, RISC-V spec says that they decided to not add overflow trapping because it is "easy" to do in 3 or 4 existing instructions.

>RISC-V spec says that they decided to not add overflow trapping because it is "easy" to do in 3 or 4 existing instructions.

It is not just "easy" to do, but actually easy to do, without quotes.

And much, much easier than as an exception/trap.

And it is explicit, which makes it even better. No hidden behaviour.

Re: Memory safety for web fonts

#199

Post by AndriyKunitsyn »

maxdamantus wrote: post #173

I hope that if we switch away from FreeType, we'll still have a way to use TTF hinting instructions fully. Windows/macOS don't seem to have a way to enable proper hinting anymore [0], and even FreeType (since 2.7 [1]) defaults to improper hinting (they call it "subpixel hinting", which doesn't make sense to me in theory, and practically still seems blurry, as if it's unhinted). In case anyone's wondering what properl…

>In case anyone's wondering what properly hinted text looks like, here's a screenshot

I'm not an expert, but - I'm sorry, it's not.

The point of hinting is to change the shape of the glyphs so the rasterized result looks "better". What "better" is, of course, purely subjective, but most people would agree that it's better when perceived thicknesses of strokes and gaps are uniform, and the text is less blurry, so the eye can discern the shapes faster. I don't think that your rendering scores high points in that regard.

I'll take a phrase from your rendering: "it usually pays" [0]. I don't like it, I'm sorry. The hinter can't make up its mind if the stroke width should be two pixels wide, or three pixels with faint pixels on the sides and an intense one in the center - therefore, the perceived thicknesses vary, which increases eye strain; "l"s are noticeably different; "ys" at the end clumped together into one blurry thing; and there's a completely unnecessary line of faint pixels on the bottom of the characters, which hinting should have prevented.

The second line is how it looks on Windows on 150% scale. Verdana is a different font, so it's an unfair comparison (Verdana was designed specifically to look good on low resolutions), and the rainbows can be off-putting, but I still think the hinter tucks the shapes into pixels better.

Maybe I don't understand something, or maybe there's a mistake.

[0] https://postimg.cc/cKCQR60F

Re: Memory safety for web fonts

#200

Post by grishka »

nullpoint420 wrote: post #197
grishka wrote: post #174

Earlier quoted context omitted.

Well, in my particular case, I use an M1 Max MBP with a 2K monitor that I already had when I bought the MacBook. The problem with 27" 4K monitors is that you can't have integer scaling on them. If you set the scaling factor to 1x, everything will be too small, if you set it to 2x, everything will be huge, and macOS can't properly do fractional scaling because what it actually does is render everything into a 2x frame…

Your sights are set on Apple when IMO, they should be aimed at the rest of the display industry. Why don’t they produce 5K/6K monitors that allow for 2x integer scaling? The $1,600 Studio Display is only $1,600 because it has no competition.

> Why don’t they produce 5K/6K monitors that allow for 2x integer scaling?

Because 5K panels are probably more expensive to produce than 4K ones, and because that would only benefit Mac users since Windows can do fractional scaling just fine. I'm not sure about that but it might also be that not all GPUs used in PCs can drive monitors larger than 4K.

Post reply on HN