Seems to be working now.

Part of https://github.com/behdad/harfbuzz/pull/10

I had tried to expand to fill the blocks, but that sounds wrong in
retrospect.

Now default shaper is truly no-op.

No shaper has more than one behavior re this, so no need for a callback.

Not exhaustively tested, but I think I got the intended logic
right.

The logic can perhaps be simplified.  Maybe we should disabled
normalization with this shaper.  Then again, for now focusing on
correctness.

When seeing U+2044 FRACTION SLASH in the text, find decimal
digits (Unicode General Category Decimal_Number) around it,
and mark the pre-slash digits with 'numr' feature, the post-slash
digits with 'dnom' feature, and the whole sequence with 'frac'
feature.

This beautifully renders fractions with major Windows fonts,
and any other font that implements those features (numr/dnom is
enough for most fonts.)

Not the fastest way to do this, but good enough for a start.

We were throwing away the rtlm feature mask set during
mirroring...

Work around broken automake-1.13 changes.

Fix tests build.

https://bugs.freedesktop.org/show_bug.cgi?id=71353

https://bugzilla.mozilla.org/show_bug.cgi?id=941470

Will fix by removing shape_plan->face completely.

CoreText does automatic font fallback (AKA "cascading") for  characters
not supported by the requested font, and provides no way to turn it off,
so detect if the returned run uses a font other than the requested one
and fill in the buffer with .notdef glyphs instead of random indices
glyph from a different font.

The spec and Uniscribe don't allow these, but UTN#11
specifically says the sequence U+104B,U+1038 is valid.
As such, allow all "P V" sequences.  There's about
eight sequences that match that structure, but Roozbeh
thinks it's fine to allow all of them.

Test case: U+104B, U+1038

https://bugs.freedesktop.org/show_bug.cgi?id=71947