fonts: unicode glyph measurments #156
Comments
I'm not sure on the defaults, but there might be more worth testing here, like |
|
Hmmm, I need to think more about these styles |
From the paper
That doesn't explain "none", only that they're not setting a named font. "none" Edit: also paper is from 2015 and Unicode version was 7.0.0
|
Thorin-Oakenpants
changed the title
|
https://web-platform-tests.org/writing-tests/ahem.html just an idea for when I get around to textmetrics - besides 1/128ths and combining widths etc we could detect textmetric BS by measuring known results (zoom etc may not make this stable) or using these for the combining (because you never know what fonts and chars will do) We can create a special font like Ahem and blob it (like the woff2 test) |
|
some notes looping char then font-family is faster than font-family then char (about a 25% perf hit AFAICT), anyway, I now collect the detail data and group it by font-family (and for now hash it for easy compare) This shows me that some font-families don't make a difference: depending on your default proportional font and/or if system-ui is enabled (I removed at least I think it's default proportional (which can vary based on language) that it's falling back to let styles = ["cursive","fantasy","monospace","sans-serif","serif","system-ui"]
// some styles match: we should detect those and remove redundant
// we do not need style 'none' as it == default proportional (serif for me using en-US)
// e.g. if fantasy matches sans-serif (for me using en-US)
// e.g. if system-ui is not enabled it matches default proportional (serif for me using en-US)in our character-then-style loop, like font measurements, what takes time is asking for measurements, not settings things. And like font sizes, adding additional methods doesn't really add anything: e.g. asking for textmetrics + clientrect as well as offset is negligible So what speeds up pref is reducing measurements: either remove styles or reduce chars tested here's myFF nightly: to show we have redundancy that eats perf
so we could run a mini test of sorts to eliminate what is redundant - maybe an offsetWidth/Height test? |
|
actually, I wasn't hashing correctly, they are all different e.g.fantasy vs sans-serif diffs well, fuck, that's suck for improving perf |
|
ok, we definitely do not need For example, for the char So anything in I can confirm that the sizes shown in What this does perhaps add is entropy on what the default font-family is for some scripts, but I doubt this is worth it (per OS) and likely not changed Still working out if fantasy is worth it some diff outputs / char info
|
|
By grouping by char then size, I am able to see if any styles are unique, and except for fantasy, they all offer a lot of unique sizes I wonder what makes Note: OT: I don't believe the chars used for textmetrics (excluding width) are all that great, but it adds minimal perf since we're looping thru and doing offset and clientrect anyway. If we ran a separate test with a different list of fntCodes, we'd be repeating all that perf unique per char
|
|
fantasy unique on chrome |
|
note: 13 of the 43 chars are tofu on my windows FF (no RFP), and 21 with RFP (font vis level 1) So two things
|
|
more notes: enabled dom.textMetrics.baselines.enabled, dom.textMetrics.emHeight.enabled, dom.textMetrics.fontBoundingBox.enabled FF
Edit: this seems to be the same for chrome, except fantasy is not the same as sans-serif |
|
i tweaked the local test: so what does each style bring in terms of new unique sizes PER CHAR, per measure method e.g. in clientrect/offset 42 out of 43 chars have a measurement that the other styles do not match. In monospace this is 25, in serif it is 25, etc
what is interesting here is that sans-serif seems to do very little - except for that one char (and 13 are tofu so it may be more), it adds nothing, as the measurements are already recorded elsewhere |
|
and if we add none, it cancels out sans-serif
|
|
Ahh, right, the penny drops: because fantasy + sans-serif share a lot, so we need one of them. Fantasy + no sans-serif added 29 unique measurements, sans-serif + no fantasy added 25 - IDK what that means. When both used, they both still had some unique measurements : fantasy 3 and sans-serif 1 so they seem to cancel each other out and we only need one, but which one, and it may change based on fonts used (and char support e.g. my 13 tofus), and if the font has a serif vs non-serif (such as Tor Browser added a heap of noto + noto sans fonts) I'm intrigued as to why fantasy only affects a couple of chars
|
|
https://en.wikipedia.org/wiki/Specials_(Unicode_block)#Unicode_chart |
|
FYI: I thought height might not add much entropy.. but for example: go to https://browserleaks.com/fonts - run twice due to lazy font fallback loading heres FF nightly (sorted by sans-serif width)
|
|
PS: so a little like fantasy: a couple more data points per method (eating a lot of perf) and entropy added in this test is unknown. We can also grab some fangsong entropy in https://arkenfox.github.io/TZP/tests/lineheight.html |
Perf
Why do we measure six styles when we only need five
we already know the default body style, which is always sans-serif, serif or monospace (I think) and there can't be any other styles other than these five above.
@abrahamjuliot .. am I missing something here?
Improve glyphs list
glyphs list
For each unicode version, get one new assigned code point per script since, say 2006. I suspect the glyphs David ended up with were recently assigned - they're certainly spread over scripts and probably unicode versions - but I have not checked
I plan to create a unicode version PoC - similar to https://arkenfox.github.io/TZP/tests/fontscripts.html, but only deal with additions since say 2005 (large and new script block additions I'll only use a small subset - we'll see how we go) and grouped by unicode version (then script)
I'll include recent emoji additions, I just don't want the test to get too massive
emojis
I also plan to create an emoji test PoC by version. I think it's 3.3k code points. I want to do this as a separate FP and data test for Tor Browser
The text was updated successfully, but these errors were encountered: