Live data from Hacker News

Memory safety for web fonts

developer.chrome.com

211–220 of 230 posts

Re: Memory safety for web fonts

#211

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…

I'm not entirely sure how you got that first line, but if it's derived from my image, your system must be scaling the image, which introduces blur. Since you mentioned a 150% scale, I'm guessing your image viewer is rendering each pixel in my image as 1.5 pixels (on average) on your screen, which will explain the scaling/blurring, making it difficult to demonstrate proper hinting on your screen with raster images (I alluded to this in my previous post).

Here's an updated version of your image, with the actual pixel data from my image copied in, at 8x and 1x scale [0]. It should be possible to see the pixels yourself if you load it into a tool like GIMP, which preserves pixels as you zoom in.

It should be fairly clear from the image above that the hinting causes the outlines (particularly, horizontal and vertical lines) to align to the pixel grid, which, as you say, both makes the line widths uniform and makes the text less blurry (by reducing the need for antialiasing; SSAA is basically the gold standard for antialiasing, which involves rendering at a higher resolution and then downscaling, meaning a single physical pixel corresponds to an average of multiple pixels from the original image).

Out of interest, I've done a bit of processing [1] to your image to see what ClearType is actually doing [2], and as described in the FreeType post I linked, it seems like it is indeed using vertical hints (so the horizontal lines don't have the colours next to them—this is obvious from your picture), and it seems like it is indeed ignoring any horizontal hints, since the grey levels around the vertical lines are inconsistent, and the image still looks horizontally blurry.

I might as well also link to this demo I started putting together a few years ago [3]. It uses FreeType to render with hinting within the browser, and it should handle different DPIs as long as `devicePixelRatio` is correct. I think this should work on desktop browsers as long as they're scaling aware (I think this is the case with UI scaling on Windows but not on macOS). Mobile browsers tend to give nonsense values here since they don't want to change it as the user zooms in/out. Since it's using FreeType alone without something like HarfBuzz, maybe some of the positioning is not optimal.

[0] https://gist.githubusercontent.com/Maxdamantus/3a58d8e764b29...

[1] After jiggling the image around and converting it back from 8x to 1x, I used this command to show each RGB subpixel in greyscale (assuming the typical R-G-B pixel layout used on LCD computer monitors):

    width=137; height=53; stream /tmp/image_1x.png - | xxd -p | sed 's/../&&&/g' | xxd -r -p | convert -size $((width*3))x$((height)) -depth 8 rgb:- -interpolate nearest-neighbor -interpolative-resize $((100*8))%x$((300*8))% /tmp/image_8x_rgb.png
[2] https://gist.githubusercontent.com/Maxdamantus/3a58d8e764b29...

[3] https://maxdamantus.eu.org/ftv35-220719/site/

Re: Memory safety for web fonts

#212
post #110

Earlier quoted context omitted.

Just imagine the mess in Belgium!

Actually I can imagine that multilingualism would force the devs to rely on Accept-Language instead of GeoIP. Talking out of my arse here :)

One imagines the the large number of Indian and Chinese H1B workers at large tech companies are multi-lingual or at least bilingual.

Re: Memory safety for web fonts

#213
post #206

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…

Yes, Skrifa executes TrueType hints and has a new autohinting implementation written in Rust. We use these modes in Chrome.

Hmm.. I tried using the "tools/viewer/viewer --slide GM_typeface_fontations_roboto" example in the skia repository earlier (swapping out the Roboto font for DejaVuSans, since the Roboto font doesn't seem to properly hint horizontally [0]), but the result [1] seems to only be hinted vertically, so similar to the FreeType "v40" interpreter, which supposedly ignores horizontal hints.

Admittedly I haven't looked into how the setup is configured, and haven't tried it in Chrome, so maybe it's still possible to enable full hinting as intended by the font somehow.

[0] https://gist.githubusercontent.com/Maxdamantus/3a58d8e764b29...

[1] https://gist.githubusercontent.com/Maxdamantus/3a58d8e764b29...

Re: Memory safety for web fonts

#214

Earlier quoted context omitted.

Java only has tearing for double and long, which are POD types and so are irrelevant to memory safety. Go has tearing for pointer-like objects (interfaces, slices), which causes the memory safety problems. Data races on those pointer-like objects are undefined behavior in Go, whereas there isn't something comparable in Java. The reason why Go is considered a memory safe language is actually pretty mundane: it's simpl…

I haven’t seen any aligned double or long tearing for over 20 years on workstation or server CPUs.

X86 has a strong memory model, so tearing isn’t an issue for 64-bit or smaller quantities. Other architectures (ARM) are different.

AIUi

Re: Memory safety for web fonts

#215

Earlier quoted context omitted.

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.

Even if Windows/Linux do fractional scaling fine, integer scaling is still desirable if it’s an option. Under both I still run into programs that botch fractional scaling some way or another, and given the proclivity of programs on both platforms to be built with oddball UI toolkits I don’t expect that to ever really fully resolve itself.

It’s one of the chief complaints I have with one of my mostly otherwise good x86 laptops. The 1.5x scaling the display needs has been a pain point on multiple occasions.

Re: Memory safety for web fonts

#216
post #118

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.

Also, the act of breaking it into smaller functions itself may introduce more bugs.

Yes, rewrites are risky, but I really meant not writing such large functions in the first place.

Re: Memory safety for web fonts

#217
post #206

Earlier quoted context omitted.

Yes, Skrifa executes TrueType hints and has a new autohinting implementation written in Rust. We use these modes in Chrome.

Hmm.. I tried using the "tools/viewer/viewer --slide GM_typeface_fontations_roboto" example in the skia repository earlier (swapping out the Roboto font for DejaVuSans, since the Roboto font doesn't seem to properly hint horizontally [0]), but the result [1] seems to only be hinted vertically, so similar to the FreeType "v40" interpreter, which supposedly ignores horizontal hints. Admittedly I haven't looked into how…

In the viewer, press '/' and configure hinting to full, or modify the source in gm/fontations.cpp and call SkFont::setHinting(SkFontHinting::kFull) or kNormal.

Re: Memory safety for web fonts

#218

Earlier quoted context omitted.

>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…

I'm not entirely sure how you got that first line, but if it's derived from my image, your system must be scaling the image, which introduces blur. Since you mentioned a 150% scale, I'm guessing your image viewer is rendering each pixel in my image as 1.5 pixels (on average) on your screen, which will explain the scaling/blurring, making it difficult to demonstrate proper hinting on your screen with raster images (I…

>I'm guessing your image viewer is rendering each pixel in my image as 1.5 pixels

Gosh, you are right, I'm so sorry, it really was my PC. Yes, it really is much nicer once I looked at the real pixels of your screenshot. Thank you for the answer.

Re: Memory safety for web fonts

#219
post #217

Earlier quoted context omitted.

Hmm.. I tried using the "tools/viewer/viewer --slide GM_typeface_fontations_roboto" example in the skia repository earlier (swapping out the Roboto font for DejaVuSans, since the Roboto font doesn't seem to properly hint horizontally [0]), but the result [1] seems to only be hinted vertically, so similar to the FreeType "v40" interpreter, which supposedly ignores horizontal hints. Admittedly I haven't looked into how…

In the viewer, press '/' and configure hinting to full, or modify the source in gm/fontations.cpp and call SkFont::setHinting(SkFontHinting::kFull) or kNormal.

Thanks for the reply. I was able to play around with the settings there, but even when enabling full hinting it's still only hinting vertically (I think this is what it was doing by default, as in my screenshot—this is similar to what the FreeType v40 hinter does, which is used by default from 2.7 as mentioned in my first post).

EDIT: looking into the FreeType code, it looks like the v35 mode turns on the `NO_SUBPIXEL_HINTING` flag [0], which might have also been ported over to skrifa [1]? Though there are "(always enabled)" comments throughout the code suggesting that it can't be configured.

Maybe later I'll try forcing the option and see what happens.

[0] https://github.com/freetype/freetype/blob/5d4e649f740c675426...

[1] https://github.com/googlefonts/fontations/blob/f808570ce1939...

Re: Memory safety for web fonts

#220
post #83

Earlier quoted context omitted.

Note that this can lead to horrid economics for the user. An example being Google unilaterally flipping on VP8/VP9 decode, which at that time purely decoded on the CPU or experimentally on the GPU. It saved Google a few CPU cycles and some bandwidth but it nuked every user's CPU and battery. And the amount of energy YouTube consumed wholesale (so servers + clients) skyrocketed. Tragedy of the Commons.

It also saved licensing costs to MPEG-LA too I guess.

They still have to pay for H.264 and the cost of it are peanuts.
Post reply on HN