Opened 4 years ago

Last modified 21 months ago

#16672 assigned defect

Text rendering allows font fingerprinting

Reported by: arthuredelstein Owned by: arthuredelstein
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-fingerprinting-fonts, tbb-5.5, TorBrowserTeam201603
Cc: gk, mcs, dcf, mikeperry, mrphs, nicoo, gacar@… Actual Points:
Parent ID: #18097 Points:
Reviewer: Sponsor:

Description

Using dcf's font fingerprinting demo,

https://www.bamsoftware.com/talks/fc15-fontfp/fontfp.html#demo

gk 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.

Child Tickets

Attachments (9)

Screen Shot 2015-08-03 at 5.25.41 PM.png (24.1 KB) - added by arthuredelstein 4 years ago.
Screen Shot 2015-08-03 at 6.15.53 PM.png (201.6 KB) - added by arthuredelstein 4 years ago.
u+018d-cursive-diff.png (28.2 KB) - added by dcf 4 years ago.
Graphical diff of U+018D in cursive style from September 2014. I think it was between Debian and Ubuntu with different hinting settings.
5.0a4-debian-fonttest.gif (27.2 KB) - added by dcf 4 years ago.
Animation showing difference in rendering on two Debian 8 systems. It originally comes from the thread at ​https://lists.torproject.org/pipermail/tor-qa/2015-August/000654.html.
1-8854c333.png (117.7 KB) - added by dcf 4 years ago.
Screenshot of fonttest.html using packages from comment:13.
1-8854c333-2015-08-08.txt (2.8 KB) - added by dcf 4 years ago.
Output of fonttest using packages from comment:13.
4.0-alpha-3-fonts-1.png (23.1 KB) - added by dcf 4 years ago.
Screenshot using comment:1:ticket:13313 (https://people.torproject.org/~dcf/pt-bundle/4.0-alpha-3-fonts-1/).
Linux55a2.png (7.7 KB) - added by gk 4 years ago.
Linux55a3.png (6.6 KB) - added by gk 4 years ago.

Download all attachments as: .zip

Change History (56)

comment:1 Changed 4 years ago by arthuredelstein

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.

comment:2 Changed 4 years ago by arthuredelstein

Summary: Text rendering allows OS fingerprintingText rendering allows fingerprinting

comment:3 Changed 4 years ago by mcs

Cc: mcs added

comment:4 Changed 4 years ago by arthuredelstein

Cc: dcf added

dcf created a fonts.conf files that should help to homogenize rendering settings across Linux platforms. See https://trac.torproject.org/projects/tor/ticket/13313#comment:1

Also, he did fantastic work on font/text-rendering fingerprinting, reported here:
https://bamsoftware.com/papers/fontfp.pdf
with a demo described at https://trac.torproject.org/projects/tor/ticket/13313#comment:16

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?

Changed 4 years ago by arthuredelstein

comment:5 Changed 4 years ago by arthuredelstein

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.

Changed 4 years ago by arthuredelstein

comment:6 Changed 4 years ago by arthuredelstein

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.

Last edited 4 years ago by arthuredelstein (previous) (diff)

comment:7 in reply to:  6 Changed 4 years ago by gk

Replying to arthuredelstein:

It looks like Ubuntu GNOME is failing to generate bold and italics fonts (which may be related to not having Bold variants installed).

FWIW it is neither related to Ubuntu nor to GNOME. I see that on my Debian with Xfce as well.

comment:8 Changed 4 years ago by mikeperry

Keywords: tbb-5.0 added

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).

comment:9 in reply to:  4 Changed 4 years ago by dcf

Replying to arthuredelstein:

dcf created a fonts.conf files that should help to homogenize rendering settings across Linux platforms. See https://trac.torproject.org/projects/tor/ticket/13313#comment:1

Also, he did fantastic work on font/text-rendering fingerprinting, reported here:
https://bamsoftware.com/papers/fontfp.pdf
with a demo described at https://trac.torproject.org/projects/tor/ticket/13313#comment:16

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.

comment:10 in reply to:  description Changed 4 years ago by dcf

Replying to arthuredelstein:

Using dcf's font fingerprinting demo,

https://www.bamsoftware.com/talks/fc15-fontfp/fontfp.html#demo

gk 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 attachment: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

https://people.torproject.org/~dcf/fonttest.html#viewer

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:
Graphical diff of U+018D in cursive style from September 2014. I think it was between Debian and Ubuntu with different hinting settings.
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.)

Changed 4 years ago by dcf

Attachment: u+018d-cursive-diff.png added

Graphical diff of U+018D in cursive style from September 2014. I think it was between Debian and Ubuntu with different hinting settings.

comment:11 Changed 4 years ago by dcf

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.

comment:12 Changed 4 years ago by dcf

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.
Animation showing difference in rendering on two Debian 8 systems. It originally comes from the thread at ​https://lists.torproject.org/pipermail/tor-qa/2015-August/000654.html.
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.

Changed 4 years ago by dcf

Attachment: 5.0a4-debian-fonttest.gif added

Animation showing difference in rendering on two Debian 8 systems. It originally comes from the thread at ​https://lists.torproject.org/pipermail/tor-qa/2015-August/000654.html.

comment:13 Changed 4 years ago by arthuredelstein

Keywords: TorBrowserTeam201508R added
Status: newneeds_review

Here are some fixup patches for review:

There are two commits for tor-browser-bundle.git:
https://github.com/arthuredelstein/tor-browser-bundle/commits/16672+1
And one commit for tor-browser.git:
https://github.com/arthuredelstein/tor-browser/commits/16672+2

Builds for testing are available at:
https://people.torproject.org/~arthuredelstein/downloads/16672-builds/

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.)

comment:14 Changed 4 years ago by arthuredelstein

Cc: mikeperry added

Changed 4 years ago by dcf

Attachment: 1-8854c333.png added

Screenshot of fonttest.html using packages from comment:13.

Changed 4 years ago by dcf

Attachment: 1-8854c333-2015-08-08.txt added

Output of fonttest using packages from comment:13.

comment:15 in reply to:  13 ; Changed 4 years ago by dcf

Replying to arthuredelstein:

Here are some fixup patches for review:

There are two commits for tor-browser-bundle.git:
https://github.com/arthuredelstein/tor-browser-bundle/commits/16672+1
And one commit for tor-browser.git:
https://github.com/arthuredelstein/tor-browser/commits/16672+2

Builds for testing are available at:
https://people.torproject.org/~arthuredelstein/downloads/16672-builds/

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
attachment:1-8854c333-2015-08-08.txt
attachment:1-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.

comment:16 in reply to:  15 ; Changed 4 years ago by dcf

Replying to dcf:

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.

$ FC_DEBUG=1024 ./start-tor-browser.desktop -d
FC_DEBUG=1024
        Loading config file /home/david/nightly-16672/tor-browser_en-US/Browser/TorBrowser/Data/fontconfig/fonts.conf
        Scanning config dir /etc/fonts/conf.d
        Loading config file /etc/fonts/conf.d/10-scale-bitmap-fonts.conf
        Loading config file /etc/fonts/conf.d/11-lcdfilter-default.conf
        ...

If I remove this line from fonts.conf,

<include ignore_missing="yes">conf.d</include>

Then Fontconfig only loads Tor Browser's fonts.conf.

$ FC_DEBUG=1024 ./start-tor-browser.desktop -d
FC_DEBUG=1024
        Loading config file /home/david/nightly-16672/tor-browser_en-US/Browser/TorBrowser/Data/fontconfig/fonts.conf

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 #13313, and I'm pretty sure I tested them back then.

comment:17 in reply to:  16 Changed 4 years ago by dcf

Replying to dcf:

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 #13313, 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.

$ FC_DEBUG=1024 ./start-tor-browser
Launching Tor Browser for Linux in /home/david/4.0-alpha-3-fonts-1/tor-browser_en-US/Browser...

(process:29279): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
FC_DEBUG=1024
        Loading config file /home/david/4.0-alpha-3-fonts-1/tor-browser_en-US/Browser/TorBrowser/Data/fontconfig/fonts.conf
        Scanning config dir /home/david/4.0-alpha-3-fonts-1/tor-browser_en-US/Browser/TorBrowser/Data/fontconfig/conf.d
        Loading config file /home/david/4.0-alpha-3-fonts-1/tor-browser_en-US/Browser/TorBrowser/Data/fontconfig/conf.d/65-0-lohit-marathi.conf
        Loading config file /home/david/4.0-alpha-3-fonts-1/tor-browser_en-US/Browser/TorBrowser/Data/fontconfig/conf.d/65-0-lohit-nepali.conf
        Loading config file /home/david/4.0-alpha-3-fonts-1/tor-browser_en-US/Browser/TorBrowser/Data/fontconfig/conf.d/65-droid.conf
        Loading config file /home/david/4.0-alpha-3-fonts-1/tor-browser_en-US/Browser/TorBrowser/Data/fontconfig/conf.d/65-lohit.conf
        Loading config file /home/david/4.0-alpha-3-fonts-1/tor-browser_en-US/Browser/TorBrowser/Data/fontconfig/conf.d/66-lohit-assamese.conf
        Loading config file /home/david/4.0-alpha-3-fonts-1/tor-browser_en-US/Browser/TorBrowser/Data/fontconfig/conf.d/66-lohit-bengali.conf
        Loading config file /home/david/4.0-alpha-3-fonts-1/tor-browser_en-US/Browser/TorBrowser/Data/fontconfig/conf.d/66-lohit-devanagari.conf
        Loading config file /home/david/4.0-alpha-3-fonts-1/tor-browser_en-US/Browser/TorBrowser/Data/fontconfig/conf.d/66-lohit-gujarati.conf
        Loading config file /home/david/4.0-alpha-3-fonts-1/tor-browser_en-US/Browser/TorBrowser/Data/fontconfig/conf.d/66-lohit-kannada.conf
        Loading config file /home/david/4.0-alpha-3-fonts-1/tor-browser_en-US/Browser/TorBrowser/Data/fontconfig/conf.d/66-lohit-oriya.conf
        Loading config file /home/david/4.0-alpha-3-fonts-1/tor-browser_en-US/Browser/TorBrowser/Data/fontconfig/conf.d/66-lohit-punjabi.conf
        Loading config file /home/david/4.0-alpha-3-fonts-1/tor-browser_en-US/Browser/TorBrowser/Data/fontconfig/conf.d/66-lohit-tamil-classical.conf
        Loading config file /home/david/4.0-alpha-3-fonts-1/tor-browser_en-US/Browser/TorBrowser/Data/fontconfig/conf.d/66-lohit-tamil.conf
        Loading config file /home/david/4.0-alpha-3-fonts-1/tor-browser_en-US/Browser/TorBrowser/Data/fontconfig/conf.d/66-lohit-telugu.conf
        Loading config file /home/david/4.0-alpha-3-fonts-1/tor-browser_en-US/Browser/TorBrowser/Data/fontconfig/conf.d/67-lohit-malayalam.conf

Screenshot using comment:1:ticket:13313 (https://people.torproject.org/~dcf/pt-bundle/4.0-alpha-3-fonts-1/).

comment:18 Changed 4 years ago by mrphs

Cc: mrphs added

comment:19 Changed 4 years ago by arthuredelstein

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.

https://github.com/arthuredelstein/tor-browser/commits/16672+3

And here are builds for this patch for testing:

https://people.torproject.org/~arthuredelstein/downloads/16672-3-builds/

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.

comment:20 Changed 4 years ago by mikeperry

Keywords: TorBrowserTeam201509R added; TorBrowserTeam201508R removed

Transfer review tickets to Sept.

comment:21 Changed 4 years ago by mikeperry

comment:22 Changed 4 years ago by gk

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 #16707. Maybe that made you think we merged 16672+4?

comment:23 Changed 4 years ago by mikeperry

Ok, yes. That was my mistake. However, for this ticket, does that mean that both https://github.com/arthuredelstein/tor-browser/commits/16672+3 and https://github.com/arthuredelstein/tor-browser/commits/16672+4 should be considered, or just one or the other?

comment:24 in reply to:  23 Changed 4 years ago by arthuredelstein

Replying to mikeperry:

Ok, yes. That was my mistake. However, for this ticket, does that mean that both https://github.com/arthuredelstein/tor-browser/commits/16672+3 and https://github.com/arthuredelstein/tor-browser/commits/16672+4 should be considered, or just one or the other?

Please only use 16672+3 and disregard 16672+4. Sorry for the confusion. Also note that 16672+3 has two patches.

comment:25 Changed 4 years ago by mcs

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.

comment:26 Changed 4 years ago by gk

Owner: changed from tbb-team to arthuredelstein
Status: needs_reviewassigned

Okay this is now on the tor-browser-38.3.0esr-5.5-1 branch (commit 9878431b2531415aad76c717c68b5b08dec4ffc4 + 93da48890a7887775e72aadd2ee7123048387d0a).

comment:27 Changed 4 years ago by gk

Keywords: TorBrowserTeam201509 added; TorBrowserTeam201509R removed

comment:28 Changed 4 years ago by gk

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.

Changed 4 years ago by gk

Attachment: Linux55a2.png added

Changed 4 years ago by gk

Attachment: Linux55a3.png added

comment:29 in reply to:  28 Changed 4 years ago by cypherpunks

Replying to gk:

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.

comment:30 Changed 4 years ago by nicoo

Cc: nicoo added

comment:31 Changed 4 years ago by gk

Keywords: TorBrowserTeam201510 added; TorBrowserTeam201509 removed

Moving Tor Browser tickets to October 2015.

comment:32 Changed 4 years ago by gk

Keywords: TorBrowserTeam201511 added; TorBrowserTeam201510 removed

comment:33 Changed 4 years ago by mikeperry

Keywords: TorBrowserTeam201512 added; TorBrowserTeam201511 removed

comment:34 Changed 4 years ago by gk

Severity: Normal

Keeping this open for some data points with respect to our font fingerprinting defense we have in 5.5a5/5.5a6.

comment:35 Changed 4 years ago by gk

Keywords: tbb-5.5 added; tbb-5.0 removed

comment:36 Changed 4 years ago by gk

Keywords: TorBrowserTeam201601 added; TorBrowserTeam201512 removed

Tickets for Jan 2016.

comment:37 Changed 4 years ago by arthuredelstein

Parent ID: #18097

comment:38 Changed 4 years ago by arthuredelstein

Summary: Text rendering allows fingerprintingText rendering allows font fingerprinting

comment:39 Changed 4 years ago by bugzilla

To not forget:
FF 44b: To support unicode-range descriptor for webfonts, font matching under Linux now uses the same font matching code as other platforms

It is not rendering, but matching influences the result too as you compare pages visually.

comment:40 Changed 4 years ago by cypherpunks

Why to make fonts.conf if browser already using bundled fonts and every OS version/installation still unique, while UX "badly broken" (personally got headache after several hours usage, am I so unique? unlikely, but browser yet)?

comment:41 Changed 4 years ago by banaba

Tor Browser. Fonts are ugly.

Fix:
Subpixel rendering

Most monitors manufactured today use the Red, Green, Blue (RGB) specification. Fontconfig will need to know your monitor type to be able to display your fonts correctly. Monitors are either: RGB (most common), BGR, V-RGB (vertical), or V-BGR.

Change value of rgba from none to one of values: rgb, bgr, vrgb, vbgr.

Example for RGB:
INSTALL/Browser/TorBrowser/Data/fontconfig/fonts.conf

<edit name="rgba" mode="assign"><const>rgb</const></edit>
Last edited 4 years ago by banaba (previous) (diff)

comment:42 Changed 4 years ago by cypherpunks

@banaba:

Enabling sub-pixel rendering is a bad idea. Not all monitors have the same sub-pixel layout. On those that don't have the 'rgb' layout Tor browser will be unusable.

comment:43 Changed 4 years ago by cypherpunks

TBB should bundle freetype and probably harfbuzz as well in Linux. I'm getting different checksums for different Linux versions on https://people.torproject.org/~dcf/fonttest.html.

comment:44 Changed 4 years ago by gk

Keywords: TorBrowserTeam201602 added; TorBrowserTeam201601 removed

Putting stuff on the radar for February.

comment:45 Changed 4 years ago by gk

Keywords: TorBrowserTeam201603 added; TorBrowserTeam201602 removed

comment:46 Changed 23 months ago by cypherpunks

The situation with the current TBB (7.0.10) looks improved, the ~dcf/fonttest.html has the same fingerprint for me. However, per:
browserleaks.com/fonts

in the "JS Fonts (classic)" test, the fallback metrics/fonts are different between different test systems.

comment:47 Changed 21 months ago by gacar

Cc: gacar@… added
Note: See TracTickets for help on using tickets.