That seems to be what Windows is doing, and makes more sense.

Back in the old days, we used to apply 'calt' and 'cswh' in Arabic shaper,
with a pause in between.  Then we disabled the 'cswh' because Microsoft
disabled it, but forgot to remove the unnecessary pause.  Do that now.

This has the benefit that it fixes shaping with monbaiti from Windows 10.
In that version of that font, the lookups from 'calt' are duplicated in
'rclt', and Mongolian was changed to go through Universal Shaping Engine.
We still use the Arabic shaper for Mongolian.  With a pause after 'calt',
we were applying the duplicate lookups from 'calt' and 'rclt' twice.  It
happened to be the case that these lookups were NOT idempotent.  So we
were getting wrong shaping.  See thread "Windows 10 monbaiti.ttf upgrade
(5.01 -> 5.51) caused loss of diacritical marks when shaped with harfbuz"
on the mailing list.  This fixes that.

This aims to make Syriac Abbr Mark sizing more accurate when repeating segments are used, by adding an extra repeat and tightening up the spacing slightly rather than leaving a shortfall corresponding to a partial repeat-width.

Visual Studio does not like declaring a enum variable within a for
statement, so fix the build by declaring the enum before doing the for
loop.

Err on the side of being too short, than too wide.  Reduces chance
of overlaps with neighboring glyphs.

Addresses
https://github.com/behdad/harfbuzz/commit/6e6f82b6f3dde0fc6c3c7d991d9ec6cfff57823d#commitcomment-14248516

The feature is enabled for any character in the Arabic shaper.
We should experiment with using it for Arabic subtending marks.
Though, that has a directionality problem as well, since those
are used with digits...

Fixes https://github.com/behdad/harfbuzz/issues/141

Unused currently.  To be used for Syriac stretch implementation.

https://github.com/behdad/harfbuzz/issues/141

And add check to FLAG()

Was broken in 615d00ea.

Fixes https://github.com/behdad/harfbuzz/pull/48

Micro-test added.

Previously, we expected users to provide BOT/EOT flags when the
text *segment* was at paragraph boundaries.  This meant that for
clients that provide full paragraph to HarfBuzz (eg. Pango), they
had code like this:

  hb_buffer_set_flags (hb_buffer,
                       (item_offset == 0 ? HB_BUFFER_FLAG_BOT : 0) |
                       (item_offset + item_length == paragraph_length ?
                        HB_BUFFER_FLAG_EOT : 0));

  hb_buffer_add_utf8 (hb_buffer,
                      paragraph_text, paragraph_length,
                      item_offset, item_length);

After this change such clients can simply say:

  hb_buffer_set_flags (hb_buffer,
                       HB_BUFFER_FLAG_BOT | HB_BUFFER_FLAG_EOT);

  hb_buffer_add_utf8 (hb_buffer,
                      paragraph_text, paragraph_length,
                      item_offset, item_length);

Ie, HarfBuzz itself checks whether the segment is at the beginning/end
of the paragraph.  Clients that only pass item-at-a-time to HarfBuzz
continue not setting any flags whatsoever.

Another way to put it is: if there's pre-context text in the buffer,
HarfBuzz ignores the BOT flag.  If there's post-context, it ignores
EOT flag.

Ouch!

Follows the order of the Arabic/Syriac specs.  Also don't stop
between rlig and calt in non-Arabic scripts.

Micro-tests for Arabic and Mongolian added for the latter.

This reverts bf029281 and fixes it properly.  That commit
was not enough as it was only inheriting the shaping_action
for prev_action, but not curr_action.

Micro-test added.

https://code.google.com/p/chromium/issues/detail?id=393896

Old table was from 6.2.  Remove hard-coded Mongolian and Phags-pa data.
This completes support for new scripts Manichian and Psaltar Pahlavi.

No functional change.

I believe Windows 8 disables it, and spec update dated
Jan 2014 also clearly says it's disabled by default:

  http://www.microsoft.com/typography/OpenTypeDev/arabic/intro.htm#features

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

This reverts commit d5bd0590.

The reasoning behind that logic was flawed and made under
a misunderstanding of the original problem, and caused
regressions as reported by Jonathan Kew in thread titled
"tibetan marks" in Oct 2013.  Apparently I have had fixed
the original problem with this commit:

  7e08f125

So, revert the faulty commit and everything seems to be in good
shape.

See:
http://lists.freedesktop.org/archives/harfbuzz/2013-April/003101.html

Unicode 6.2.0 Section 16.2 / Figure 16.3 says:

"For backward compatibility, between Arabic characters a ZWJ acts just
like the sequence <ZWJ, ZWNJ, ZWJ>, preventing a ligature from forming
instead of requesting the use of a ligature that would not normally be
used. As a result, there is no plain text mechanism for requesting the
use of a ligature in Arabic text."

As such, we flip internal zwj to zwnj flags for GSUB matching, which
means it will block ligation in all features, unless the font
explicitly matches U+200D glyph.  This doesn't affect joining behavior.

Windows 8 doesn't, and the spec will be fixed.

Mozilla Bug 873902 - Display Arabic text with diacritics is bad
https://bugzilla.mozilla.org/show_bug.cgi?id=873902

Testing shows that this is closer to what Uniscribe does.

Reported by Khaled Hosny:

"""
commit 56800027
...
This commit is causing a regression with Amiri, the string “هَٰذ” with
Uniscribe and HarfBuzz before this commit, gives:

	[uni0630.fina=3+965|uni0670.medi=0+600|uni064E=0@-256,0+0|uni0647.init=0+926]

But now it gives:

	[uni0630.fina=3+965|uni0670.medi=0+0|uni064E=0@-256,0+0|uni0647.init=0+926]

i.e. uni0670.medi is zeroed though it has a base glyph GDEF class.
"""

The test case is U+0647,U+064E,U+0670,U+0630 with Amiri.

This is the first character in Unicode to have Arabic left-joining
behavior.  Update the machine to recognize that.

Test case: U+A840,U+A872,U+A840.

Code cleanup.  No (intended) functional change.

Before, we were zeroing advance width of attached marks for
non-Indic scripts, and not doing it for Indic.

We have now three different behaviors, which seem to better
reflect what Uniscribe is doing:

  - For Indic, no explicit zeroing happens whatsoever, which
    is the same as before,

  - For Myanmar, zero advance width of glyphs marked as marks
    *in GDEF*, and do that *before* applying GPOS.  This seems
    to be what the new Win8 Myanmar shaper does,

  - For everything else, zero advance width of glyphs that are
    from General_Category=Mn Unicode characters, and do so
    before applying GPOS.  This seems to be what Uniscribe does
    for Latin at least.

With these changes, positioning of all tests matches for Myanmar,
except for the glitch in Uniscribe not applying 'mark'.  See preivous
commit.

Ouch!

New API:

	hb_buffer_flags_t

	HB_BUFFER_FLAGS_DEFAULT
	HB_BUFFER_FLAG_BOT
	HB_BUFFER_FLAG_EOT
	HB_BUFFER_FLAG_PRESERVE_DEFAULT_IGNORABLES

	hb_buffer_set_flags()
	hb_buffer_get_flags()

We use the BOT flag to decide whether to insert dottedcircle if the
first char in the buffer is a combining mark.

The PRESERVE_DEFAULT_IGNORABLES flag prevents removal of characters like
ZWNJ/ZWJ/...

Had to do some refactoring to make this happen...

Under uniscribe bug compatibility mode, we still plit them
Uniscrie-style, but Jonathan and I convinced ourselves that there is no
harm doing this the Unicode way.  This change makes that happen, and
unbreaks free Sinhala fonts.