James Clark | 12 Nov 02:46 2014

Re: Thai text render issue in Android L

กระฎุมพี is in the Royal Institute dictionary and is actually used (e.g. http://th.wikipedia.org/wiki/%E0%B8%8A%E0%B8%99%E0%B8%8A%E0%B8%B1%E0%B9%89%E0%B8%99%E0%B8%81%E0%B8%A3%E0%B8%B0%E0%B8%8E%E0%B8%B8%E0%B8%A1%E0%B8%9E%E0%B8%B5). So if a font doesn't handle SARA U and SARA UU (and PHINTHU) beneath consonants DO CHADA and TO PATAK, I would say that is a font bug.

James

On Tue, Nov 11, 2014 at 11:59 PM, Ed Trager <ed.trager-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Hi,

To the best of my knowledge, it seems extremely unlikely that U+0E0E THAI CHARACTER DO CHADA would have U+0E39 THAI CHARACTER SARA UU ( or U+0E38 THAI CHARACTER SARA U for that matter ) appear below it.

I can't think of any Central Thai words that would have that kind of spelling; and it seems even more unlikely that any of the minority languages would use DO CHADA at all.

Therefore, it seems very likely that the font designers did not specify an anchoring position point for SARA U or SARA UU appearing below consonants such as DO CHADA or U+0E0F THAI CHARACTER TO PATAK.

- Ed


On Mon, Nov 10, 2014 at 10:16 PM, Nguyễn Đức An <annd1985-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Dear Harfbuzz developers,
We have an issue with Thai text render in Android L. When input U+0E0E and U+0E39, it displays wrong (please see the attach screen).
I checked Thai Noto font (Google font) and Samsung Thai (Samsung font), issue happens with both of them.
As i read the source of Harfbuzz, Thai reshaping only does separate SARA AM to NIKHAHIT & SARAA. So maybe the problem is not came from Harfbuzz.
Any help is welcome.
Thank you.


_______________________________________________
HarfBuzz mailing list
HarfBuzz <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz



_______________________________________________
HarfBuzz mailing list
HarfBuzz-PD4FTy7X32lNgt0PjOBp9w@public.gmane.orgp.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz


_______________________________________________
HarfBuzz mailing list
HarfBuzz <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Roozbeh Pournader | 11 Nov 20:00 2014
Picon

Re: Thai text render issue in Android L

With the latest HarfBuzz and Noto Sans Thai, I'm seeing the result I'm attaching, which appears correct to me (and the same as Android Kitkat result you've attached).

But I see the same as what you are seeing on Android Lollipop. So this appears to be a bug somewhere in Android rather than HarfBuzz or Noto Sans.

Please file a bug at https://source.android.com/source/report-bugs.html and send us a link to it. Thanks.

On Tue, Nov 11, 2014 at 8:59 AM, Ed Trager <ed.trager-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Hi,

To the best of my knowledge, it seems extremely unlikely that U+0E0E THAI CHARACTER DO CHADA would have U+0E39 THAI CHARACTER SARA UU ( or U+0E38 THAI CHARACTER SARA U for that matter ) appear below it.

I can't think of any Central Thai words that would have that kind of spelling; and it seems even more unlikely that any of the minority languages would use DO CHADA at all.

Therefore, it seems very likely that the font designers did not specify an anchoring position point for SARA U or SARA UU appearing below consonants such as DO CHADA or U+0E0F THAI CHARACTER TO PATAK.

- Ed


On Mon, Nov 10, 2014 at 10:16 PM, Nguyễn Đức An <annd1985-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Dear Harfbuzz developers,
We have an issue with Thai text render in Android L. When input U+0E0E and U+0E39, it displays wrong (please see the attach screen).
I checked Thai Noto font (Google font) and Samsung Thai (Samsung font), issue happens with both of them.
As i read the source of Harfbuzz, Thai reshaping only does separate SARA AM to NIKHAHIT & SARAA. So maybe the problem is not came from Harfbuzz.
Any help is welcome.
Thank you.


_______________________________________________
HarfBuzz mailing list
HarfBuzz <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz



_______________________________________________
HarfBuzz mailing list
HarfBuzz-PD4FTy7X32lNgt0PjOBp9w@public.gmane.orgp.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz


_______________________________________________
HarfBuzz mailing list
HarfBuzz <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Nguyễn Đức An | 11 Nov 04:16 2014
Picon

Thai text render issue in Android L

Dear Harfbuzz developers,
We have an issue with Thai text render in Android L. When input U+0E0E and U+0E39, it displays wrong (please see the attach screen).
I checked Thai Noto font (Google font) and Samsung Thai (Samsung font), issue happens with both of them.
As i read the source of Harfbuzz, Thai reshaping only does separate SARA AM to NIKHAHIT & SARAA. So maybe the problem is not came from Harfbuzz.
Any help is welcome.
Thank you.

_______________________________________________
HarfBuzz mailing list
HarfBuzz <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Behdad Esfahbod | 10 Nov 00:36 2014

Slides from IUC

These are slides from the talk Roozbeh and I did at Internationalization &
Unicode Conference last week in Santa Clara, called: "Unicode, OpenType, and
Fonts: Closing the Circle".  The slides were not designed for reading, and
unfortunately IUC does not record talks :(.  We hope to do a recorded version
later this year.

  http://goo.gl/FSIQuC

Cheers,
--

-- 
behdad
http://behdad.org/
_______________________________________________
HarfBuzz mailing list
HarfBuzz <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Konstantin Ritt | 4 Nov 08:18 2014
Picon

Re: HB-NG and Qt

The issue appears on Windows indeed. The problematic font was "Tahoma".
See more details at https://bugreports.qt-project.org/browse/QTBUG-41931 (not that many, though).
The proposed `fontEngine->doKerning(..)` is used either in the HB-old path in case the shaper item's `kerning_applied` flag appears to be unset after shaping, though there is no similar thing in HB-NG, so I don't think applying additional kerning blindly is a good solution in general.
All `doKerning()` method does is loads the kerning pairs from the font's ('k', 'e', 'r', 'n') table and applies kerning metrics. I believe it is quite the same HB does.
 
Regards,
Konstantin

2014-11-04 10:51 GMT+04:00 Behdad Esfahbod <behdad-muU0i0fqO+Mdnm+yROfE0A@public.gmane.org>:
Hi Konstantin?

Which font exactly?

The rule in HarfBuzz-ng is, if the font has *any* GPOS, then the old-style
kern table is not applied.  This is not exactly what OpenType recommends, but
is a cleaner approach than applying old-style kern if the GPOS table has no
'kern' feature.

At any rate, we need to see what font exactly this is happening with, and what
Uniscribe does.

IIRC, some fonts shipped with Windows XP or 7 could hit this problem, but
hardly any other font we know about.

Cheers,
behdad

PS.  If you write to the list, others can chime in.  Specifically, Jonathan
knows a lot about these as they highly care about Windows experience.

On 14-11-03 10:43 PM, Konstantin Ritt wrote:
> Hi Behdad,
>
>
> As you may know, we've switched to HB-NG as of Qt 5.4 alpha, which is a good
> news, of course.
> However we didn't drop the HB-old path and it is possible to switch to it,
> which is very handy for comparing the shaping/rendering results between HB-NG
> and HB-old, BTW.
>
> Now, here is a bug report https://bugreports.qt-project.org/browse/QTBUG-41931
> about kerning issue with some fonts.
> I was proposing a quick possible solution w/o expecting it to help... but it
> helped, so I'm in doubts:
>  ~2 years ago you answered that NG supports both old and new style kerning
> just fine (even better than HB-old) by enabling the kern feature, so my code
> currently is:
> {code}
> const hb_feature_t features[1] = {
>     { HB_TAG('k','e','r','n'), !!kerningEnabled, 0, uint(-1) }
> };
> const int num_features = 1;
> shapedOk = hb_shape_full(hb_font, buffer, features, num_features, 0);
> {code}
> but then, I don't understand why applying the old-style kerning manually on
> top of HB's results solves the raised issue. Am I missing something?
>
> Best regards,
> Konstantin

--
behdad
http://behdad.org/

_______________________________________________
HarfBuzz mailing list
HarfBuzz <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
ff.feng | 30 Oct 03:50 2014
Picon

How many unicode make up a glyph?

Hi !

I'm developing a font engine with harfbuzz & freetype for Cambodia.
I can get the correct glyph index array and position array by harfbuzz.
That's sweet.

Now I got a problem : I'm wondering how many unicode(UTF16) form a glyph?
(If I specify a item in the glyph index array from hb_buffer_get_glyph_infos)

thanks a lot & sorry for my poor English.


Best regards,

**********************************************************************

The preceding e-mail message (including any attachments) may contain confidential information intended for a specific individual and purpose.If you are not an intended recipient of this message, please notify the sender by replying to this message and then delete it from your system.Use,dissemination, distribution, or reproduction of this message by unintended recipients is not authorized and may be unlawful.

**********************************************************************

 

_______________________________________________
HarfBuzz mailing list
HarfBuzz <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Behdad Esfahbod | 29 Oct 19:24 2014

harfbuzz: Branch 'master'

 src/hb-ot-layout-gsubgpos-private.hh |   17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

New commits:
commit fde3e4a423871463c883cb969e99c29cb6f69f6b
Author: Behdad Esfahbod <behdad <at> behdad.org>
Date:   Wed Oct 29 11:23:08 2014 -0700

    In hb_ot_collect_glyphs(), don't recurse to a lookup more than once

    Otherwise, we might process a lookup thousands of times, with no
    benefit.  This pathological case was hit by Noto Nastaliq Urdu Draft
    in Firefox's code to determine whether space glyph is involved in
    any GSUB/GPOS rules.  A test page is at http://behdad.org/urdu

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

diff --git a/src/hb-ot-layout-gsubgpos-private.hh b/src/hb-ot-layout-gsubgpos-private.hh
index 546ff4b..7106870 100644
--- a/src/hb-ot-layout-gsubgpos-private.hh
+++ b/src/hb-ot-layout-gsubgpos-private.hh
 <at>  <at>  -168,6 +168,10  <at>  <at>  struct hb_collect_glyphs_context_t
     if (output == hb_set_get_empty ())
       return HB_VOID;

+    /* Return if new lookup was recursed to before. */
+    if (recursed_lookups.has (lookup_index))
+      return HB_VOID;
+
     hb_set_t *old_before = before;
     hb_set_t *old_input  = input;
     hb_set_t *old_after  = after;
 <at>  <at>  -181,6 +185,8  <at>  <at>  struct hb_collect_glyphs_context_t
     input  = old_input;
     after  = old_after;

+    recursed_lookups.add (lookup_index);
+
     return HB_VOID;
   }

 <at>  <at>  -190,6 +196,7  <at>  <at>  struct hb_collect_glyphs_context_t
   hb_set_t *after;
   hb_set_t *output;
   recurse_func_t recurse_func;
+  hb_set_t recursed_lookups;
   unsigned int nesting_level_left;
   unsigned int debug_depth;

 <at>  <at>  -205,8 +212,16  <at>  <at>  struct hb_collect_glyphs_context_t
 			      after  (glyphs_after  ? glyphs_after  : hb_set_get_empty ()),
 			      output (glyphs_output ? glyphs_output : hb_set_get_empty ()),
 			      recurse_func (NULL),
+			      recursed_lookups (),
 			      nesting_level_left (nesting_level_left_),
-			      debug_depth (0) {}
+			      debug_depth (0)
+  {
+    recursed_lookups.init ();
+  }
+  ~hb_collect_glyphs_context_t (void)
+  {
+    recursed_lookups.fini ();
+  }

   void set_recurse_func (recurse_func_t func) { recurse_func = func; }
 };
_______________________________________________
HarfBuzz mailing list
HarfBuzz <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Behdad Esfahbod | 15 Oct 06:26 2014

harfbuzz: Branch 'master' - 2 commits

 src/hb-open-type-private.hh |   75 +++++++++++++++++++++++++++++++++++---------
 src/hb-private.hh           |   41 ------------------------
 src/hb-uniscribe.cc         |    6 +++
 3 files changed, 66 insertions(+), 56 deletions(-)

New commits:
commit 5a5640d8506ccfc99fd119e89e829170d1fea421
Author: Behdad Esfahbod <behdad@...>
Date:   Tue Oct 14 21:26:13 2014 -0700

    Move code around

diff --git a/src/hb-open-type-private.hh b/src/hb-open-type-private.hh
index 9807569..a58e790 100644
--- a/src/hb-open-type-private.hh
+++ b/src/hb-open-type-private.hh
 <at>  <at>  -552,57 +552,57  <at>  <at>  struct BEInt<Type, 2>
   private: uint8_t v[2];
 };
 template <typename Type>
-struct BEInt<Type, 4>
+struct BEInt<Type, 3>
 {
   public:
   inline void set (Type V)
   {
-    v[0] = (V >> 24) & 0xFF;
-    v[1] = (V >> 16) & 0xFF;
-    v[2] = (V >>  8) & 0xFF;
-    v[3] = (V      ) & 0xFF;
+    v[0] = (V >> 16) & 0xFF;
+    v[1] = (V >>  8) & 0xFF;
+    v[2] = (V      ) & 0xFF;
   }
   inline operator Type (void) const
   {
-    return (v[0] << 24)
-         + (v[1] << 16)
-         + (v[2] <<  8)
-         + (v[3]      );
+    return (v[0] << 16)
+         + (v[1] <<  8)
+         + (v[2]      );
   }
-  inline bool operator == (const BEInt<Type, 4>& o) const
+  inline bool operator == (const BEInt<Type, 3>& o) const
   {
     return v[0] == o.v[0]
         && v[1] == o.v[1]
-        && v[2] == o.v[2]
-        && v[3] == o.v[3];
+        && v[2] == o.v[2];
   }
-  inline bool operator != (const BEInt<Type, 4>& o) const { return !(*this == o); }
-  private: uint8_t v[4];
+  inline bool operator != (const BEInt<Type, 3>& o) const { return !(*this == o); }
+  private: uint8_t v[3];
 };
 template <typename Type>
-struct BEInt<Type, 3>
+struct BEInt<Type, 4>
 {
   public:
   inline void set (Type V)
   {
-    v[0] = (V >> 16) & 0xFF;
-    v[1] = (V >>  8) & 0xFF;
-    v[2] = (V      ) & 0xFF;
+    v[0] = (V >> 24) & 0xFF;
+    v[1] = (V >> 16) & 0xFF;
+    v[2] = (V >>  8) & 0xFF;
+    v[3] = (V      ) & 0xFF;
   }
   inline operator Type (void) const
   {
-    return (v[0] << 16)
-         + (v[1] <<  8)
-         + (v[2]      );
+    return (v[0] << 24)
+         + (v[1] << 16)
+         + (v[2] <<  8)
+         + (v[3]      );
   }
-  inline bool operator == (const BEInt<Type, 3>& o) const
+  inline bool operator == (const BEInt<Type, 4>& o) const
   {
     return v[0] == o.v[0]
         && v[1] == o.v[1]
-        && v[2] == o.v[2];
+        && v[2] == o.v[2]
+        && v[3] == o.v[3];
   }
-  inline bool operator != (const BEInt<Type, 3>& o) const { return !(*this == o); }
-  private: uint8_t v[3];
+  inline bool operator != (const BEInt<Type, 4>& o) const { return !(*this == o); }
+  private: uint8_t v[4];
 };

 /* Integer types in big-endian order and no alignment requirement */
commit 666b42f73bd1f516657b206ef738108825bf239f
Author: Behdad Esfahbod <behdad@...>
Date:   Tue Oct 14 21:24:59 2014 -0700

    Move macros around

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

diff --git a/src/hb-open-type-private.hh b/src/hb-open-type-private.hh
index 475187b..9807569 100644
--- a/src/hb-open-type-private.hh
+++ b/src/hb-open-type-private.hh
 <at>  <at>  -533,9 +533,21  <at>  <at>  template <typename Type>
 struct BEInt<Type, 2>
 {
   public:
-  inline void set (Type i) { hb_be_uint16_put (v,i); }
-  inline operator Type (void) const { return hb_be_uint16_get (v); }
-  inline bool operator == (const BEInt<Type, 2>& o) const { return hb_be_uint16_eq (v, o.v); }
+  inline void set (Type V)
+  {
+    v[0] = (V >>  8) & 0xFF;
+    v[1] = (V      ) & 0xFF;
+  }
+  inline operator Type (void) const
+  {
+    return (v[0] <<  8)
+         + (v[1]      );
+  }
+  inline bool operator == (const BEInt<Type, 2>& o) const
+  {
+    return v[0] == o.v[0]
+        && v[1] == o.v[1];
+  }
   inline bool operator != (const BEInt<Type, 2>& o) const { return !(*this == o); }
   private: uint8_t v[2];
 };
 <at>  <at>  -543,9 +555,27  <at>  <at>  template <typename Type>
 struct BEInt<Type, 4>
 {
   public:
-  inline void set (Type i) { hb_be_uint32_put (v,i); }
-  inline operator Type (void) const { return hb_be_uint32_get (v); }
-  inline bool operator == (const BEInt<Type, 4>& o) const { return hb_be_uint32_eq (v, o.v); }
+  inline void set (Type V)
+  {
+    v[0] = (V >> 24) & 0xFF;
+    v[1] = (V >> 16) & 0xFF;
+    v[2] = (V >>  8) & 0xFF;
+    v[3] = (V      ) & 0xFF;
+  }
+  inline operator Type (void) const
+  {
+    return (v[0] << 24)
+         + (v[1] << 16)
+         + (v[2] <<  8)
+         + (v[3]      );
+  }
+  inline bool operator == (const BEInt<Type, 4>& o) const
+  {
+    return v[0] == o.v[0]
+        && v[1] == o.v[1]
+        && v[2] == o.v[2]
+        && v[3] == o.v[3];
+  }
   inline bool operator != (const BEInt<Type, 4>& o) const { return !(*this == o); }
   private: uint8_t v[4];
 };
 <at>  <at>  -553,9 +583,24  <at>  <at>  template <typename Type>
 struct BEInt<Type, 3>
 {
   public:
-  inline void set (Type i) { hb_be_uint24_put (v,i); }
-  inline operator Type (void) const { return hb_be_uint24_get (v); }
-  inline bool operator == (const BEInt<Type, 3>& o) const { return hb_be_uint24_eq (v, o.v); }
+  inline void set (Type V)
+  {
+    v[0] = (V >> 16) & 0xFF;
+    v[1] = (V >>  8) & 0xFF;
+    v[2] = (V      ) & 0xFF;
+  }
+  inline operator Type (void) const
+  {
+    return (v[0] << 16)
+         + (v[1] <<  8)
+         + (v[2]      );
+  }
+  inline bool operator == (const BEInt<Type, 3>& o) const
+  {
+    return v[0] == o.v[0]
+        && v[1] == o.v[1]
+        && v[2] == o.v[2];
+  }
   inline bool operator != (const BEInt<Type, 3>& o) const { return !(*this == o); }
   private: uint8_t v[3];
 };
diff --git a/src/hb-private.hh b/src/hb-private.hh
index 40d02ea..cd02e2b 100644
--- a/src/hb-private.hh
+++ b/src/hb-private.hh
 <at>  <at>  -539,47 +539,6  <at>  <at>  struct hb_lockable_set_t
 };

 
-
-
-/* Big-endian handling */
-
-static inline uint16_t hb_be_uint16 (const uint16_t v)
-{
-  const uint8_t *V = (const uint8_t *) &v;
-  return (V[0] << 8) | V[1];
-}
-
-static inline uint16_t hb_uint16_swap (const uint16_t v)
-{
-  return (v >> 8) | (v << 8);
-}
-
-static inline uint32_t hb_uint32_swap (const uint32_t v)
-{
-  return (hb_uint16_swap (v) << 16) | hb_uint16_swap (v >> 16);
-}
-
-/* Note, of the following macros, uint16_get is the one called many many times.
- * If there is any optimizations to be done, it's in that macro.  However, I
- * already confirmed that on my T400 ThinkPad at least, using bswap_16(), which
- * results in a single ror instruction, does NOT speed this up.  In fact, it
- * resulted in a minor slowdown.  At any rate, note that v may not be correctly
- * aligned, so I think the current implementation is optimal.
- */
-
-#define hb_be_uint16_put(v,V)	HB_STMT_START { v[0] = (V>>8); v[1] = (V); } HB_STMT_END
-#define hb_be_uint16_get(v)	(uint16_t) ((v[0] << 8) + v[1])
-#define hb_be_uint16_eq(a,b)	(a[0] == b[0] && a[1] == b[1])
-
-#define hb_be_uint32_put(v,V)	HB_STMT_START { v[0] = (V>>24); v[1] = (V>>16); v[2] = (V>>8); v[3] =
(V); } HB_STMT_END
-#define hb_be_uint32_get(v)	(uint32_t) ((v[0] << 24) + (v[1] << 16) + (v[2] << 8) + v[3])
-#define hb_be_uint32_eq(a,b)	(a[0] == b[0] && a[1] == b[1] && a[2] == b[2] && a[3] == b[3])
-
-#define hb_be_uint24_put(v,V)	HB_STMT_START { v[0] = (V>>16); v[1] = (V>>8); v[2] = (V); } HB_STMT_END
-#define hb_be_uint24_get(v)	(uint32_t) ((v[0] << 16) + (v[1] << 8) + v[2])
-#define hb_be_uint24_eq(a,b)	(a[0] == b[0] && a[1] == b[1] && a[2] == b[2])
-
-
 /* ASCII tag/character handling */

 static inline bool ISALPHA (unsigned char c)
diff --git a/src/hb-uniscribe.cc b/src/hb-uniscribe.cc
index 74ae3a3..e7bcad2 100644
--- a/src/hb-uniscribe.cc
+++ b/src/hb-uniscribe.cc
 <at>  <at>  -43,6 +43,12  <at>  <at> 
 #endif

 
+static inline uint16_t hb_uint16_swap (const uint16_t v)
+{ return (v >> 8) | (v << 8); }
+static inline uint32_t hb_uint32_swap (const uint32_t v)
+{ return (hb_uint16_swap (v) << 16) | hb_uint16_swap (v >> 16); }
+
+
 typedef HRESULT (WINAPI *SIOT) /*ScriptItemizeOpenType*/(
   const WCHAR *pwcInChars,
   int cInChars,
notifier | 15 Oct 05:11 2014

behdad/harfbuzz coverage decreased (-1.47%) on master

behdad/harfbuzz coverage decreased (-1.47%) for commit: Fix misc warnings Fixes https://github.com/behdad/harfbuzz/pull/51 by behdad
<div>
<a href="https://coveralls.io/builds/1336408"></a>
<a href="https://coveralls.io/repos/34061">behdad/harfbuzz</a>
<span class="negative">coverage decreased (-1.47%)</span>
for commit:
<span><a href="http://github.com/behdad/harfbuzz/commit/5c87120b8178566ddae99d9825edc24f9b87ea3d">Fix misc warnings

Fixes https://github.com/behdad/harfbuzz/pull/51</a></span>
by
<a href="https://github.com/behdad" class="committer">behdad</a>
</div>
Behdad Esfahbod | 15 Oct 05:07 2014

harfbuzz: Branch 'master'

 src/hb-buffer-deserialize-json.rl |    4 ++--
 src/hb-ot-layout-gsub-table.hh    |    2 +-
 src/hb-private.hh                 |    6 +++---
 3 files changed, 6 insertions(+), 6 deletions(-)

New commits:
commit 5c87120b8178566ddae99d9825edc24f9b87ea3d
Author: Behdad Esfahbod <behdad@...>
Date:   Tue Oct 14 20:07:31 2014 -0700

    Fix misc warnings

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

diff --git a/src/hb-buffer-deserialize-json.rl b/src/hb-buffer-deserialize-json.rl
index 7351b2a..91b350f 100644
--- a/src/hb-buffer-deserialize-json.rl
+++ b/src/hb-buffer-deserialize-json.rl
 <at>  <at>  -117,8 +117,8  <at>  <at>  _hb_buffer_deserialize_glyphs_json (hb_buffer_t *buffer,

   const char *tok = NULL;
   int cs;
-  hb_glyph_info_t info;
-  hb_glyph_position_t pos;
+  hb_glyph_info_t info = {0};
+  hb_glyph_position_t pos = {0};
   %%{
     write init;
     write exec;
diff --git a/src/hb-ot-layout-gsub-table.hh b/src/hb-ot-layout-gsub-table.hh
index 2b421a9..7d6a5a7 100644
--- a/src/hb-ot-layout-gsub-table.hh
+++ b/src/hb-ot-layout-gsub-table.hh
 <at>  <at>  -200,7 +200,7  <at>  <at>  struct SingleSubst
     TRACE_SERIALIZE (this);
     if (unlikely (!c->extend_min (u.format))) return TRACE_RETURN (false);
     unsigned int format = 2;
-    int delta;
+    int delta = 0;
     if (num_glyphs) {
       format = 1;
       /* TODO(serialize) check for wrap-around */
diff --git a/src/hb-private.hh b/src/hb-private.hh
index cac021a..40d02ea 100644
--- a/src/hb-private.hh
+++ b/src/hb-private.hh
 <at>  <at>  -951,12 +951,12  <at>  <at>  hb_codepoint_parse (const char *s, unsigned int len, int base, hb_codepoint_t *o

 struct hb_options_t
 {
-  int initialized : 1;
-  int uniscribe_bug_compatible : 1;
+  unsigned int initialized : 1;
+  unsigned int uniscribe_bug_compatible : 1;
 };

 union hb_options_union_t {
-  int i;
+  unsigned int i;
   hb_options_t opts;
 };
 ASSERT_STATIC (sizeof (int) == sizeof (hb_options_union_t));
Bob Hallissy | 14 Oct 00:01 2014

feature "execution" order

I apologize in advance if this information is already available -- please just point me to it if so. Or, if it is straightforward to deduce this from the source code, I'm happy to try that -- but I took a brief look and wasn't successful so I'll need some coaching.

As we are aware, Uniscribe makes multiple passes over the text, more-or-less one pass per feature. In the Arabic spec, for example, Microsoft says:
All OTL processing is divided into a set of predefined features(described and illustrated in the Features section of this document). Each feature is applied, one by one, to the appropriate glyphs in the syllable and OTLS processes them. Uniscribe makes as many calls to the OTL Services as there are features.
and:
Regardless of the model an application chooses for supporting layout of complex scripts, Uniscribe requires a fixed order for executing features within a run of text to consistently obtain the proper basic form. This is achieved by calling features one-by-one in the standard order listed below.
and finally the list of features, in order: ccmp, isol, fina, medi, init, rlig, calt, liga, dlig, cswh, mset, curs, kern, mark, and mkmk.

(This is, of course, not what the OT spec says should be done, but that is water under the bridge and we are stuck with Uniscribe compatibility)

What I'd like to know is what is the equivalent sequence for Harfbuzz?  Presumably Harfbuzz implements additional features (clig, locl, rtla, rtlm and salt come to mind) and it would be helpful to know where they fall in the sequence. Also, where do things like Stylistic Sets (ssxx) and Character Variants (cvxx) fall in this list?

(And while this post is about Arabic, presumably other scripts have similar needs).

Thanks for any help you can provide,

Bob



<div>
    I apologize in advance if this information is already available --
    please just point me to it if so. Or, if it is straightforward to
    deduce this from the source code, I'm happy to try that -- but I
    took a brief look and wasn't successful so I'll need some coaching.<br><br>
    As we are aware, Uniscribe makes multiple passes over the text,
    more-or-less one pass per feature. In the <a href="http://www.microsoft.com/typography/OpenTypeDev/arabic/intro.htm">Arabic
      spec</a>, for example, Microsoft says:<br><blockquote type="cite">
<span>All
        OTL processing is divided into a set of predefined<span class="Apple-converted-space">&nbsp;</span></span>features<span>(described and
        illustrated in the Features section of this document). Each
        feature is applied, one by one, to the appropriate glyphs in the
        syllable and OTLS processes them. Uniscribe makes as many calls
        to the OTL Services as there are features.</span>
</blockquote>
    and:<br><blockquote type="cite"><span>Regardless
        of the model an application chooses for supporting layout of
        complex scripts, Uniscribe requires a fixed order for executing
        features within a run of text to consistently obtain the proper
        basic form. This is achieved by calling features one-by-one in
        the standard order listed below.</span></blockquote>
    and finally the list of features, in order: ccmp, isol, fina, medi,
    init, rlig, calt, liga, dlig, cswh, mset, curs, kern, mark, and mkmk.<br><br>
    (This is, of course, not what the OT spec says should be done, but
    that is water under the bridge and we are stuck with Uniscribe
    compatibility)<br><br>
    What I'd like to know is what is the equivalent sequence for
    Harfbuzz?&nbsp; Presumably Harfbuzz implements additional features (clig,
    locl, rtla, rtlm and salt come to mind) and it would be helpful to
    know where they fall in the sequence. Also, where do things like
    Stylistic Sets (ssxx) and Character Variants (cvxx) fall in this
    list?<br><br>
    (And while this post is about Arabic, presumably other scripts have
    similar needs).<br><br>
    Thanks for any help you can provide,<br><br>
    Bob<br><br><br><br>
</div>

Gmane