Bugzilla

Here's a testcase based on the upstream one, but now using a different character `U+10FFFE` which is more guaranteed to trigger a tofu-box.

(This testcase sort-of expects you to have Ahem installed, but it falls back to the wpt.live-hosted-version too, if you don't have it.)

In this testcase, I added another `@font-face` block with `unicode-range: U+0061;` which represents the `a` character, and I used the three-times-as-large `size-adjust: 3000%;` for that one, and I added an `a` character for good measure.

Despite that, we "only" use the ` size-adjust: 1000%` from the other font-face rule, which is associated with the space character (unicode-range: U+0020).

So it seems like we're treating the size-adjust of the space character specially as determining the size-adjust for tofu-boxes. jfkthame, do you know if that's intentional?  FWIW WebKit seems to be doing the same.

Here's a testcase based on the upstream one, but now using a different character `U+10FFFE` which is more guaranteed to trigger a tofu-box.

(This testcase sort-of expects you to have Ahem installed, but it falls back to the wpt.live-hosted-version too, if you don't have it.)

In this testcase, I added another `@font-face` block with `unicode-range: U+0061;` which represents the `a` character, and I used the three-times-as-large `size-adjust: 3000%;` for that one, and I added an `a` character for good measure.

Despite that, we "only" use the ` size-adjust: 1000%` from the other font-face rule, which is associated with the space character (`unicode-range: U+0020`).

So it seems like we're treating the size-adjust of the space character specially as determining the size-adjust for tofu-boxes. jfkthame, do you know if that's intentional?  FWIW WebKit seems to be doing the same.