gk [ticket:13313#comment:24 observed] that different operating systems render glyphs in the same font differently:
I just tested that on two 32bit Linux systems (one Ubuntu 12.04 and one Debian testing) and even there are differeces visible with bundled fonts (the diff is attached). I guess this means shipping the alpha with it is fine (it can't get worse wrt to the status quo :) ) but we might want to have an estimation about what the current solution really helps us for the stable series before we ship it there.
So I wonder whether it's possible to force Firefox/Tor Browser to use a cross-platform method for rendering fonts.
Designs
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items
0
Link issues together to show that they're related.
Learn more.
Another option is to try to minimize text rendering differences by adjusting anti-aliasing, hinting, and other similar settings. We'll have to investigate how these are implemented across different platforms.
Here's a weird difference between OS X and linux. In TBB 5.0a4, we have Noto fonts used for everything, including chrome elements. But the chrome elements in linux look very different from those in OS X. For example, here is a comparison of the URL bar.
On the left is Ubuntu/XFCE, and on the right is OS X.
So why the massive difference in rendering? Obviously the linux version is ugly and pretty unacceptable.
Here's another example of web page text being rendered differently across platforms, even though they all are using the same font (Noto Sans). From top, Ubuntu (GNOME), OS X, Windows. Note that Ubuntu (GNOME) has a different URL bar from Ubuntu (XFCE):
It looks like Ubuntu GNOME is failing to generate bold and italics fonts (which may be related to not having Bold variants installed). Windows seems to render bold text wider than OS X. Regular text seems to be very similar on Linux and Windows, but a little different on Mac. The chrome text on Ubuntu GNOME is overly large and possibly fixed-width.
Putting this on tbb-5.0 because if we don't figure out some way to improve this situation, we're going to need to drop the whole patch for 5.0 (which is fine, but we need to be aware of that possibility when looking at the 5.0 radar over the next few days).
David, do you think there might be anything in the raw data from your survey that would help us to identify fingerprintable glyph rendering settings?
The main things are hinting and antialiasing settings. The other thing was people having different versions of the same named font (different versions of Verdana, for example). But that should be prevented by font file whitelisting.
gk [ticket:13313#comment:24 observed] that different operating systems render glyphs in the same font differently:
I just tested that on two 32bit Linux systems (one Ubuntu 12.04 and one Debian testing) and even there are differeces visible with bundled fonts (the diff is attached). I guess this means shipping the alpha with it is fine (it can't get worse wrt to the status quo :) ) but we might want to have an estimation about what the current solution really helps us for the stable series before we ship it there.
The differences in linux32diff:ticket:13313, i.e. differences in 1 or 2 pixels of height, look like they are probably caused by hinting settings. That's what gk and I found last September when we were looking intensively at some examples. Could you try e.g. U+20B9 at
What we did before was to make screenshots of the renderings and then diff them. (In Gimp, Open as Layers, then change the layer mode of the top layer to "Difference".) Here's an example from the past of what a difference in hinting settings looks like:
You can tell it is due to hinting because the non-black pixels are all shades of gray. If the difference had instead been caused by LCD subpixels, then they would be colored.
In the past, we wanted to disable all subpixel antialiasing, because of hardware differences in RGB versus BGR subpixel ordering, and vertical versus horizonal subpixels (when people rotate their monitors). A quick and dirty test for subpixels is to run the xmag program and check the edges of glyphs. If subpixels are disabled, then the antialiased pixels will all be gray; otherwise they will be shades of blue and red. (See https://www.bamsoftware.com/talks/fc15-fontfp/fontfp.html#textrendering for example.)
Also FYI, about:support on Firefox will show you various graphics settings, such as whether acceleration is being used, and whether DirectWrite is being used on Windows. The difference between cairo and skia might also matter.
Here is a sample of how rendering differs on two Debian 8 systems with the same bundled fonts (Tor Browser 5.0a4). It's an animation with two frames, wait for it to cycle.
The rendering is quite different, even if the integer pixel metrics are the same. (Canvas fingerprinting would not be fooled.) In this case, the checksum difference is not because the rendering settings, but because of font selection in one code point, which is unrelated to this ticket.
After carefully examining several free fonts including Noto Sans and Noto Serif, I decided at this stage that the best way to keep users happy is to follow Mike's suggestion and use native Latin system fonts. For Mac I chose (Verdana, Georgia, Courier) and for Windows (Arial, Georgia, Courier New). These fonts are installed by default on their respective operating systems. This approach potentially sacrifices some fingerprinting protection, because different Windows or Mac versions may have different versions of Arial, for example. So it will make sense to revisit this problem and see if it is possible either to suppress any variations in default fonts, or to find free fonts that look as good as the default counterparts.
The font situation in Linux is much more complex. No fonts can be relied upon in every linux flavor. So I chose to bundle Arimo, Tinos, and Cousine fonts (Sans, Serif, and Monospace respectively), which I think are aesthetically better than the Noto Latin fonts. (Arimo and Tinos are metrically idential to Arial and Times.) I also added dcf's fontconfig patch, which makes sure no fonts are used outside the bundled font directory, and also standardizes certain font settings, such as hinting and aliasing.
Obviously I haven't been able to try every OS flavor -- so I'm very interested to hear what checksums people get on various systems using David's test: https://people.torproject.org/~dcf/fonttest.html
I also modified the prefs in Tor Browser to enforce a strict font fallback order for every supported language. It will be interesting to see if this patch allows David and Mortiz to get matching checksums on their two Debian systems.
(In the pref patch, I also removed Noto Kufi Arabic in favor of Noto Naskh Arabic.)
Trac: Keywords: N/Adeleted, TorBrowserTeam201508R added Status: new to needs_review
Obviously I haven't been able to try every OS flavor -- so I'm very interested to hear what checksums people get on various systems using David's test: https://people.torproject.org/~dcf/fonttest.html
Checksum: 1-8854c333
1-8854c333-2015-08-08.txt1-8854c333.png
It seems like the fonts.conf settings are not taking hold--at least the rgba one. When I zoom in, I see subpixel antialiasing.
Different from 5.0a4, the comment:13 bundles have Tor Launcher and the URL bar, etc. in a serif font (Tinos I suppose) rather than a monospace one.
It seems like the fonts.conf settings are not taking hold--at least the rgba one. When I zoom in, I see subpixel antialiasing.
When I turn on the CONFIG option of FC_DEBUG, I can see that Fontconfig is loading my normal configuration files in /etc, in addition to Tor Browser's packaged one.
However it doesn't change the checksum relative to comment:15. It is still 1-8854c333. And when I zoom in, I can still see subpixel antialising. This is surprising to me because I know that both system fonts.conf and subpixels were on my mind when I made the fonts.conf from legacy/trac#13313 (moved), and I'm pretty sure I tested them back then.
However it doesn't change the checksum relative to comment:15. It is still 1-8854c333. And when I zoom in, I can still see subpixel antialising. This is surprising to me because I know that both system fonts.conf and subpixels were on my mind when I made the fonts.conf from legacy/trac#13313 (moved), and I'm pretty sure I tested them back then.
I went back and tested the bundles from comment:1:ticket:13313 (https://people.torproject.org/~dcf/pt-bundle/4.0-alpha-3-fonts-1/). They indeed turn off subpixel antialiasing and do not load the Fontconfig files under /etc. Here are a transcript and screenshot. You can zoom in and see that there is no colored fringe around the letters.
I discovered that my whitelisting patch interferes with font rendering settings for fonts.conf on linux. So here are two patches that revert the whitelisting for Linux only. Instead, on Linux, we rely completely on dcf's fonts.conf file. I tested and was able to confirm that the font settings in fonts.conf (such as hinting and antialias) are then correctly used by Tor Browser.
The rest of the whitelisting patch is still useful for Mac and Windows, especially because we are using some default OS fonts. On Linux, I think dcf's patch is best -- we should avoid using system fonts as these are much more varied between Linux flavors.
Unfortunately, even though the fonts.conf settings are working correctly, I am getting different checksums between Ubuntu and Debian. So apparently some other settings or libraries need to be included. I'll investigate this further after Aug 21.
Not sure what you are meaning but this ticket is still up for review. Thus, 16672+3 is not merged yet. That said what got merged is the patch for legacy/trac#16707 (moved). Maybe that made you think we merged 16672+4?
r=mcs, r=brade
Kathy and I looked at the https://github.com/arthuredelstein/tor-browser/commits/16672+3 commits; we think they are OK. One thing to keep in mind is that completely relying on the fonts.conf file means that users should always use our scripts to start Tor Browser... but I think they already have to do so for other reasons.
The switch to 5.5a3 makes it much more painful to read monospace on Linux it seems. I am not sure if I can pinpoint all the issues I have but having to read is and j is definitely one of them. Attached are two screenshots that show the differences between 5.5a2 and 5.5a3.
The switch to 5.5a3 makes it much more painful to read monospace on Linux it seems.
IMO, it's exactly the other way around. 5.5a2 is a blurry mess. Apparently, 5.5a2 has vertical anti-aliasing enabled, 5.5a3 doesn't.