Commit Graph

22 Commits

Author SHA1 Message Date
Ebrahim Byagowi 6f76c325e5
[test] Update 10.15 results
Turned out only SFNS, which wasn't available in 10.14 anyway, needed an update
See https://crbug.com/1005969#c37 also
2019-12-10 21:43:11 +03:30
Ebrahim Byagowi 2241a676ba
[test] Add macOS 10.15 related fonts
breaks the test and 10.15 bot, will add the fix in next commit, also adds a broken test for f47cbade1
2019-12-10 19:50:34 +03:30
Ebrahim Byagowi d59d89b281
[test] Rebase 10.14 trak related test 2019-08-20 13:07:17 +04:30
Ebrahim Byagowi 37de38adea
Merge branch 'master' into remove-coretext-96dpi-assumption 2019-08-20 12:59:33 +04:30
Ebrahim Byagowi 8b6eb6cf46
Add a macOS 10.14.3 fonts tests (#1608) 2019-03-08 01:33:41 +03:30
Behdad Esfahbod a9321cb5f8 Fix mac test 2019-01-25 16:11:45 +01:00
Behdad Esfahbod 06358ae974 [AAT] Add test for recent Ligature stack fix, using Zapfino on Mac 2019-01-25 15:11:47 +01:00
Behdad Esfahbod 5034f8f2ab Fix macos tests with previous commit 2019-01-24 12:50:38 +01:00
Tor Arne Vestbø f401f85a5a Remove assumption about Core Text working in 96 DPI
Core Text doesn't actually have a concept of DPI internally, as it
doesn't rasterize anything by itself, it just generates vector paths
that get passed along to Core Graphics.

In practice this means Core Text operates in the classical macOS
logical DPI of 72, with one typographic point corresponding to one
point in the Core Graphics coordinate system, which for a normal
bitmap context then corresponds to one pixel -- or two pixels for
a "retina" context with a 2x scale transform.

Scaling the font point sizes given to HarfBuzz to an assumed DPI
of 96 is problematic with this in mind, as fonts with optical
features such as 'trak' tables for tracking, or color glyphs,
will then base the metrics off of the wrong point size compared
to what the client asked for.

This in turn causes mismatches between the metrics of the shaped
text and the actual rasterization, which doesn't include the 72
to 96 DPI scaling.

If a 96 DPI is needed, such as on the Web, the scaling should be
done outside of HarfBuzz, allowing the client to keep the DPI of
the shaping in sync with the rasterization.

The recommended way to do that is by scaling the font point size,
not by applying a transform to the target Core Graphics context,
to let Core Text choose the right optical features of the target
point size, as described in WWDC 2015 session 804:

  https://developer.apple.com/videos/play/wwdc2015/804/
2019-01-15 13:26:35 +01:00
Ebrahim Byagowi bf738ba3ba
[test][aat] Remove extra --shaper ot
As run-tests.py already adds it
2018-11-30 00:06:40 +03:30
Ebrahim Byagowi e0307de818
[test][aat.kern] More (#1427) 2018-11-29 11:36:05 +03:30
Ebrahim Byagowi 7b78d2233d
[test][aat] Update expectency
It is not visually noticeable but apparently affected by kern format2 correct implementation.
I should've checked CoreText result which can't as CircleCI outage.
2018-11-29 00:55:05 +03:30
Ebrahim Byagowi 19863c8059
[test][aat] Add a test and make macOS runners faster (#1422) 2018-11-28 20:28:42 +03:30
Ebrahim Byagowi 97eaedca5d
[test][aat] Enable Tamil MN test (#1414) 2018-11-26 16:58:58 +03:30
Ebrahim Byagowi 0e3a48e542
[test][aat] fix 10.13.6 Helvetica expectation 2018-11-25 13:37:23 +03:30
Ebrahim Byagowi cbc541b426
[aat] Add m grave test (#1412) 2018-11-25 12:50:30 +03:30
Ebrahim Byagowi fa26ad0f48
[aat] Fix macos expectation 2018-11-25 11:25:17 +03:30
Ebrahim Byagowi 825ea5a460 [test] Merge 10.12.6 and 10.13.6 tests, update to Apple Chancery fix 2018-11-25 02:14:41 +03:30
Ebrahim Byagowi b518e5af9f
Add 10.13.6 aat fonts tests and bot (#1409) 2018-11-25 01:39:00 +03:30
Behdad Esfahbod b7f7950e8f [aat] Add test for recent regression 2018-11-24 15:56:17 -05:00
Behdad Esfahbod 5020affc38 [tests] Minor 2018-11-24 15:42:11 -05:00
Behdad Esfahbod ed900ee9af [tests] Rename 2018-11-24 15:22:09 -05:00