diff options
author | Martin Robinson <mrobinson@igalia.com> | 2024-04-05 12:22:36 +0200 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-04-05 10:22:36 +0000 |
commit | 77b2e88fb7a2d3e672b5d223ba2ae8f2d15de853 (patch) | |
tree | b7fb12562b4d0ae4dff4346d7537588570c3e6e9 /components/script/dom/htmlhtmlelement.rs | |
parent | 14bf1c5434cd4cd9412a601a556e6c757c466b92 (diff) | |
download | servo-77b2e88fb7a2d3e672b5d223ba2ae8f2d15de853.tar.gz servo-77b2e88fb7a2d3e672b5d223ba2ae8f2d15de853.zip |
gfx: Do not apply scale to `CoreText` font metrics (#31996)
Since the original version of the CoreText font code, it has scaled the
metrics from CoreText by an unusual scale:
```
let scale = px_to_pt(self.ctfont.pt_size()) / (ascent + descent);
```
It's unclear what this scale was trying to accomplish. Note that it's
passing the return value of `pt_size()` to `px_to_pt` which seems
backward. This scale seems bogus, but perhaps it's based on a
misconception about what its returned from CoreText. Unlike the return
values of `CGFont` methods, which are returned in font units, the ones
from `CTFont` are "scaled according to the point size and matrix of the
font reference."
Indeed, when just interpreting these values as pixel values, the results
more or less match Firefox and Chrome. This becomes much more obvious
now that we have support for `ex` units. Even when not using `ex`, you
can sometimes see the top parts of glyphs cut off due to this scaling.
This change removes the scaling and simply interpets the return values
of `CTFont` methods as pixels. It addresses all of the issues mentioned
above. Note that this path will eventually just be a fallback path and
metrics will come from sfnt tables in the future.
Diffstat (limited to 'components/script/dom/htmlhtmlelement.rs')
0 files changed, 0 insertions, 0 deletions