[HarfBuzz] Skipping Control for Attaching Marks using OpenType

[Richard Wordingham]

On Thu, 13 Jun 2013 17:17:49 -0400
Behdad Esfahbod <behdad at behdad.org> wrote:

> On 13-06-09 07:36 AM, Richard Wordingham wrote:

> Looks to me like a HarfBuzz bug.  Can you send me a test font and test
> sequence?  Can you test the attached patch?

I'm sending an untrimmed test font off-list as I assume most people
don't want it.

I've tested the patch and found that it removes the deviation from the
specification of the lookup.  FWIW, the patch causes no problems known
to me. Unfortunately, my font doesn't seem to trigger any feature use in
Microsoft products, and Firefox 19.0.2 on Windows seems to use
HarfBuzz, so my attempts to compare with Uniscribe have failed.

As a test, I have tried three methods of moving the glyph for TAI THAM
SIGN MAI KANG LAI from immediately following one base consonant to
immediately following the next.  In each method, there are three
contexts to consider - mai kang lai and the next consonant separated by
nothing, by one preposed character (a vowel or MEDIAL RA), or by two
preposed characters (a vowel and MEDIAL RA).  The scheme works by:

(a) Deleting the original mai kang lai by a ligature lookup merging it
with the following glyph, and

(b) Creating a new mai kang lai by a multiple lookup acting on the
following base consonant.

My test font contains the three schemes as lookups 21, 22 and 23.  The
one used should be the first lookup in the abvs feature.  The font I am
submitting uses Scheme B - font name 'Da Lekh B'.  The font is by no
means complete - there are still many missing basic glyphs.  

The results before and after are attached as files a/b/c_pre/post.png.
The test sequence, which consists of two Tai Tham words starting with
the Tai Tham letter HIGH SA, is ᩈᩘᨥᩈᩘᨥᩮᩣ <U+1A48 TAI THAM LETTER HIGH
SA, U+1A58 TAI THAM SIGN MAI KANG LAI, U+1A25 TAI THAM LETTER LOW KHA,
U+1A48, U+1A58, U+1A25, U+1A6E TAI THAM VOWEL SIGN E, U+1A63 TAI THAM
VOWEL SIGN AA> (Thai transliteration สังฆะสังโฆ).  The patch does not
correct the rendering of the first word.  Only the files c_pre.png and
c_post.png show the correct rendering of both words.

Before the patch, Scheme A works with HarfBuzz 0.9.18 for the second
word, but the sequence indices do not accord with the specification.
Scheme B accords with the specification, but does not work with the
specification.  The patch switches success and failure.  Failure is
manifested by the disappearance of mai kang lai.

The failure with word 1 results from the HarfBuzz constraint on
sequence index.  One ends up with zero or two mai kang lais in the
word.  Using the old input character positions, i.e.

     | mkl_mkl mkl_cons |
       0 mkl_vanish_1
       1 mkl_append

('Scheme D') fails on word 1 both before and after the patch.

My notation for the three schemes and three contexts are:

Scheme A: (lookup 21)

lookup shift_mkl_pt1a
     | mkl_mkl mkl_cons |
       1 mkl_append
       0 mkl_vanish_1
     | mkl_mkl mkl_pre mkl_cons |
       0 mkl_vanish_1
       2 mkl_append
     | mkl_mkl mkl_pre mkl_pre mkl_cons |
       0 mkl_vanish_1
       3 mkl_append
end lookup

Scheme B: (lookup 22)

lookup shift_mkl_pt1b
     | mkl_mkl mkl_cons |
       0 mkl_vanish_1
       0 mkl_append
     | mkl_mkl mkl_pre mkl_cons |
       0 mkl_vanish_1
       1 mkl_append
     | mkl_mkl mkl_pre mkl_pre mkl_cons |
       0 mkl_vanish_1
       2 mkl_append -- Input #3 has become #2
end lookup

Scheme C: (lookup 23)
lookup shift_mkl_pt1c
    | mkl_mkl mkl_cons |
      0 condemn
      1 mkl_append
    | mkl_mkl mkl_pre mkl_cons |
      0 condemn
      2 mkl_append
    | mkl_mkl mkl_pre mkl_pre mkl_cons |
      0 condemn
      3 mkl_append
end lookup

Lookup mkl_append converts a consonant to consonant plus mai kang lai,
while lookup mkl_vanish_1 merges mai kang lai with the following glyph.
Lookup condemn converts mai kang lai to a special glyph, which is then
merged with the following glyph by a subsequent lookup.  Scheme C uses
only this two-lookup process, and works both with and without the patch.

Richard.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a_post.png
Type: image/png
Size: 2772 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/harfbuzz/attachments/20130616/0dfef831/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a_pre.png
Type: image/png
Size: 2818 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/harfbuzz/attachments/20130616/0dfef831/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: b_post.png
Type: image/png
Size: 2762 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/harfbuzz/attachments/20130616/0dfef831/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: b_pre.png
Type: image/png
Size: 2486 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/harfbuzz/attachments/20130616/0dfef831/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: c_post.png
Type: image/png
Size: 2823 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/harfbuzz/attachments/20130616/0dfef831/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: c_pre.png
Type: image/png
Size: 2823 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/harfbuzz/attachments/20130616/0dfef831/attachment-0005.png>