[HarfBuzz] HEH GOAL WITH HAMZA ABOVE(0x06C2) error in arabic

[datao zhang]

Hi Behdad:
When i try to draw the text "U+0628,U+06C2,U+06C2,U+0020" with harfbuzz, i find 
it is rendered differently  in windows 7. please see attachment file. After 
checking the hb-ot-shape-complex-arabic-table.hh, I found U+06C2 joining type 
was JOINING_TYPE_D (double joining).  I don’t know why Unicode specifies it 
double joining, it really does not make any sense. At least, when render the 
text, it should be treated as single joining type.
 
Br,
Dean
   





 
  <><>___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] List of languages supported by harfbuzz

[Andrew Cunningham]

On 5 July 2012 05:08, Adam Twardoch (List)  wrote:

> It also supports "languages" -- the OpenType component supports both the
> script tags and the language tags:
> http://www.microsoft.com/typography/otspec/scripttags.htm
> http://www.microsoft.com/typography/otspec/languagetags.htm
>

Looking at these docs, it would appear they haven't been updated for
some of the new script and language system tags supported in Windows
8.

> For script and language tags, HarfBuzz uses the ISO tags and then
> converts them into OpenType tags internally:
> http://cgit.freedesktop.org/harfbuzz/tree/src/hb-common.h
> http://cgit.freedesktop.org/harfbuzz/tree/src/hb-common.cc
> http://cgit.freedesktop.org/harfbuzz/tree/src/hb-ot-tag.h
> http://cgit.freedesktop.org/harfbuzz/tree/src/hb-ot-tag.cc
>

I find the entries with description " /* I couldn't find the language
id for these */ " quite entertaining. Some of the "Languages" listed
there that I am familiar with are actually considered to be groups of
languages with each one having its own language code.

But then i suppose that is the nature of the 1-1, many-1, 1-many, and
many-many relationship between language tags and OpenType language
systems

Andrew
-- 
Andrew Cunningham
Senior Project Manager, Research and Development
Vicnet
State Library of Victoria
Australia

andr...@vicnet.net.au
lang.supp...@gmail.com
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] How to perform full precision shaping (with no scaling and grid fitting)

[Behdad Esfahbod]

Hi,

I think I addressed the kerning issue.  There are hinting issues outstanding
that I need to address later.

behdad

On 04/20/2012 09:16 AM, Petr Filipský wrote:
> Hi,
> I am trying to perform a shaping which is independent on a resulting device,
> so no scaling, no grid-fitting is desired.
> 
> In order to disable the grid-fitting and get as high precision as possible I
> thought it was sufficient to work in the font design precision - to scale the
> font to some very high value (like the /UpEm/ value), i.e. using the following
> code:
> 
> /  hb_face_t* const face( hb_ft_face_create( ft_face, NULL ) );/
> /  hb_font_t* font = hb_font_create( face );/
> /  unsigned int const upem( hb_face_get_upem (face) );/
> /  hb_font_set_scale( font, upem, upem );/
>   /hb_ft_font_set_funcs( font );/
> 
> But unfortunately it is not enough. The /hb_ft_get_glyph_h_kerning()/ function
> calls the /FT_Get_Kerning/ with kerning mode set to /FT_KERNING_DEFAULT/, and
> for example for /Arial font/ and /'T'/ and /'a'/ character pair (55 and 68
> glyph indices) it returns value -256 (instead of correct value -227). It if
> the scaling seems correct the function still performs some fitting. If i try
> to change the kerning mode to FT_KERNING_UNSCALED then I get the correct value
> (-227) but that is probably not a proper fix but just a hack.
> 
> Is there an elegant and efficient way to disable both scaling and fitting and
> perform a device independent full precision shaping?
> 
> Thank you very much.
> 
> Kind regards,
> Petr
> 
> 
> 
> 
> ___
> HarfBuzz mailing list
> HarfBuzz@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/harfbuzz
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

[HarfBuzz] harfbuzz-ng: Branch 'master' - 2 commits

[Behdad Esfahbod]

 src/hb-ft.cc |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

New commits:
commit 2023e2b54d91924dddfd228ffdbb46021135b068
Author: Behdad Esfahbod 
Date:   Wed Jul 11 19:00:30 2012 -0400

[ft] Disable ppem setting

The calculations were wrong.

FreeType makes it really hard to set size and ppem independently.
For now, disable it.  Need to come up with a fix later.

diff --git a/src/hb-ft.cc b/src/hb-ft.cc
index 17c68df..90937ca 100644
--- a/src/hb-ft.cc
+++ b/src/hb-ft.cc
@@ -466,8 +466,11 @@ hb_ft_font_set_funcs (hb_font_t *font)
 
   FT_Set_Char_Size (ft_face,
font->x_scale, font->y_scale,
+   0, 0);
+#if 0
font->x_ppem * 72 * 64 / font->x_scale,
font->y_ppem * 72 * 64 / font->y_scale);
+#endif
 
   ft_face->generic.data = blob;
   ft_face->generic.finalizer = (FT_Generic_Finalizer) _release_blob;
commit cdf7444505a7ae49d20f9ba6776dea92c1fde2a6
Author: Behdad Esfahbod 
Date:   Wed Jul 11 18:52:39 2012 -0400

[ft] Use unfitted kerning if x_ppem is zero

diff --git a/src/hb-ft.cc b/src/hb-ft.cc
index 0589c9e..17c68df 100644
--- a/src/hb-ft.cc
+++ b/src/hb-ft.cc
@@ -158,7 +158,7 @@ hb_ft_get_glyph_v_origin (hb_font_t *font HB_UNUSED,
 }
 
 static hb_position_t
-hb_ft_get_glyph_h_kerning (hb_font_t *font HB_UNUSED,
+hb_ft_get_glyph_h_kerning (hb_font_t *font,
   void *font_data,
   hb_codepoint_t left_glyph,
   hb_codepoint_t right_glyph,
@@ -167,7 +167,8 @@ hb_ft_get_glyph_h_kerning (hb_font_t *font HB_UNUSED,
   FT_Face ft_face = (FT_Face) font_data;
   FT_Vector kerningv;
 
-  if (FT_Get_Kerning (ft_face, left_glyph, right_glyph, FT_KERNING_DEFAULT, 
&kerningv))
+  FT_Kerning_Mode mode = font->x_ppem ? FT_KERNING_DEFAULT : 
FT_KERNING_UNFITTED;
+  if (FT_Get_Kerning (ft_face, left_glyph, right_glyph, mode, &kerningv))
 return 0;
 
   return kerningv.x;
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

[HarfBuzz] harfbuzz-ng: Branch 'master'

[Behdad Esfahbod]

 src/hb-ot-layout-gpos-table.hh   |   16 ++--
 src/hb-ot-layout-gsub-table.hh   |   24 ++--
 src/hb-ot-layout-gsubgpos-private.hh |   33 ++---
 3 files changed, 18 insertions(+), 55 deletions(-)

New commits:
commit 6d08c7f1b3601095f9a12630045331dd0fe75380
Author: Behdad Esfahbod 
Date:   Wed Jul 11 18:01:27 2012 -0400

Revert "Towards templatizing common Lookup types"

This reverts commit 727135f3a9938c1ebd5b9f5015a46c7ccc8573c5.

This is work-in-progress.  Didn't mean to push it out just yet.

diff --git a/src/hb-ot-layout-gpos-table.hh b/src/hb-ot-layout-gpos-table.hh
index fa22934..c8020d8 100644
--- a/src/hb-ot-layout-gpos-table.hh
+++ b/src/hb-ot-layout-gpos-table.hh
@@ -1268,7 +1268,7 @@ struct ChainContextPos : ChainContext
 };
 
 
-struct ExtensionPos : Extension
+struct ExtensionPos : Extension
 {
   friend struct PosLookupSubTable;
 
@@ -1382,10 +1382,8 @@ struct PosLookupSubTable
 
 struct PosLookup : Lookup
 {
-  typedef struct PosLookupSubTable SubTable;
-
-  inline const SubTable& get_subtable (unsigned int i) const
-  { return this+CastR > (subTable)[i]; }
+  inline const PosLookupSubTable& get_subtable (unsigned int i) const
+  { return this+CastR > (subTable)[i]; }
 
   inline bool apply_once (hb_apply_context_t *c) const
   {
@@ -1426,7 +1424,7 @@ struct PosLookup : Lookup
   inline bool sanitize (hb_sanitize_context_t *c) {
 TRACE_SANITIZE ();
 if (unlikely (!Lookup::sanitize (c))) return TRACE_RETURN (false);
-OffsetArrayOf &list = CastR > (subTable);
+OffsetArrayOf &list = 
CastR > (subTable);
 return TRACE_RETURN (list.sanitize (c, this, get_type ()));
   }
 };
@@ -1439,8 +1437,6 @@ typedef OffsetListOf PosLookupList;
 
 struct GPOS : GSUBGPOS
 {
-  typedef struct PosLookup Lookup;
-
   static const hb_tag_t Tag= HB_OT_TAG_GPOS;
 
   inline const PosLookup& get_lookup (unsigned int i) const
@@ -1549,10 +1545,10 @@ inline bool ExtensionPos::apply (hb_apply_context_t *c) 
const
 inline bool ExtensionPos::sanitize (hb_sanitize_context_t *c)
 {
   TRACE_SANITIZE ();
-  if (unlikely (!Extension::sanitize (c))) return TRACE_RETURN (false);
+  if (unlikely (!Extension::sanitize (c))) return TRACE_RETURN (false);
   unsigned int offset = get_offset ();
   if (unlikely (!offset)) return TRACE_RETURN (true);
-  return TRACE_RETURN (StructAtOffset (this, 
offset).sanitize (c, get_type ()));
+  return TRACE_RETURN (StructAtOffset (this, 
offset).sanitize (c, get_type ()));
 }
 
 static inline bool position_lookup (hb_apply_context_t *c, unsigned int 
lookup_index)
diff --git a/src/hb-ot-layout-gsub-table.hh b/src/hb-ot-layout-gsub-table.hh
index 06a8488..f5f38cc 100644
--- a/src/hb-ot-layout-gsub-table.hh
+++ b/src/hb-ot-layout-gsub-table.hh
@@ -750,7 +750,7 @@ struct ChainContextSubst : ChainContext
 };
 
 
-struct ExtensionSubst : Extension
+struct ExtensionSubst : Extension
 {
   friend struct SubstLookupSubTable;
   friend struct SubstLookup;
@@ -1037,18 +1037,16 @@ struct SubstLookupSubTable
 
 struct SubstLookup : Lookup
 {
-  typedef struct SubstLookupSubTable SubTable;
-
-  inline const SubTable& get_subtable (unsigned int i) const
-  { return this+CastR > (subTable)[i]; }
+  inline const SubstLookupSubTable& get_subtable (unsigned int i) const
+  { return this+CastR > (subTable)[i]; }
 
   inline static bool lookup_type_is_reverse (unsigned int lookup_type)
-  { return lookup_type == SubTable::ReverseChainSingle; }
+  { return lookup_type == SubstLookupSubTable::ReverseChainSingle; }
 
   inline bool is_reverse (void) const
   {
 unsigned int type = get_type ();
-if (unlikely (type == SubTable::Extension))
+if (unlikely (type == SubstLookupSubTable::Extension))
   return CastR (get_subtable(0)).is_reverse ();
 return lookup_type_is_reverse (type);
   }
@@ -1089,7 +1087,7 @@ struct SubstLookup : Lookup
 
 /* TODO: For the most common case this can move out of the main
  * loop, but it's not a big deal for now. */
-if (unlikely (lookup_type == SubTable::Extension))
+if (unlikely (lookup_type == SubstLookupSubTable::Extension))
 {
   /* The spec says all subtables should have the same type.
* This is specially important if one has a reverse type!
@@ -1157,7 +1155,7 @@ struct SubstLookup : Lookup
   inline bool sanitize (hb_sanitize_context_t *c) {
 TRACE_SANITIZE ();
 if (unlikely (!Lookup::sanitize (c))) return TRACE_RETURN (false);
-OffsetArrayOf &list = CastR > (subTable);
+OffsetArrayOf &list = 
CastR > (subTable);
 return TRACE_RETURN (list.sanitize (c, this, get_type ()));
   }
 };
@@ -1170,8 +1168,6 @@ typedef OffsetListOf SubstLookupList;
 
 struct GSUB : GSUBGPOS
 {
-  typedef struct SubstLookup Lookup;
-
   static const hb_tag_t Tag= HB_OT_TAG_GSUB;
 
   inline const SubstLookup& get_lookup (unsigned int i) const
@@ -1242,16 +1238,16 @@ inline bool ExtensionSubst::apply (hb_apply_context_t 
*c) 

[HarfBuzz] harfbuzz-ng: Branch 'master' - 7 commits

[Behdad Esfahbod]

 TODO | 
   2 
 git.mk   | 
  58 ++
 src/hb-ot-layout-gpos-table.hh   | 
  16 +-
 src/hb-ot-layout-gsub-table.hh   | 
  24 ++--
 src/hb-ot-layout-gsubgpos-private.hh | 
  33 +
 src/hb-unicode-private.hh| 
   1 
 src/hb-uniscribe.cc  | 
   2 
 src/hb-uniscribe.h   | 
   2 
 test/shaping/texts/in-tree/shaper-indic/indic/script-malayalam/misc/misc.txt | 
   1 
 test/shaping/texts/in-tree/shaper-thai/MANIFEST  | 
   2 
 test/shaping/texts/in-tree/shaper-thai/misc/MANIFEST | 
   1 
 test/shaping/texts/in-tree/shaper-thai/misc/misc.txt | 
   6 -
 test/shaping/texts/in-tree/shaper-thai/script-thai/MANIFEST  | 
   1 
 test/shaping/texts/in-tree/shaper-thai/script-thai/misc/MANIFEST | 
   1 
 test/shaping/texts/in-tree/shaper-thai/script-thai/misc/sara-am.txt  | 
   4 
 15 files changed, 106 insertions(+), 48 deletions(-)

New commits:
commit 552bf3a9f9651311084b7979805dbdc18c0335ca
Author: Behdad Esfahbod 
Date:   Wed Jul 11 16:44:51 2012 -0400

Bump WINNT version requested from 500 to 600

Since we use the OpenType versions of Uniscribe functions, we are
relying on that version of the WINNT API.  Otherwise, usp10.h will hide
those symbols.

diff --git a/src/hb-uniscribe.cc b/src/hb-uniscribe.cc
index b71b00a..e5b98a8 100644
--- a/src/hb-uniscribe.cc
+++ b/src/hb-uniscribe.cc
@@ -24,7 +24,7 @@
  * Google Author(s): Behdad Esfahbod
  */
 
-#define _WIN32_WINNT 0x0500
+#define _WIN32_WINNT 0x0600
 
 #include "hb-private.hh"
 
diff --git a/src/hb-uniscribe.h b/src/hb-uniscribe.h
index 216610e..bb99f39 100644
--- a/src/hb-uniscribe.h
+++ b/src/hb-uniscribe.h
@@ -29,7 +29,7 @@
 
 #include "hb.h"
 
-#define _WIN32_WINNT 0x0500
+#define _WIN32_WINNT 0x0600
 #include 
 
 HB_BEGIN_DECLS
commit 9a5b421a64db1bb23d5c6ebbc3bf3f3a5513dc36
Author: Behdad Esfahbod 
Date:   Wed Jul 11 16:35:04 2012 -0400

Fix build with no Unicode funcs implementations provided

diff --git a/src/hb-unicode-private.hh b/src/hb-unicode-private.hh
index eaf151a..c781035 100644
--- a/src/hb-unicode-private.hh
+++ b/src/hb-unicode-private.hh
@@ -99,6 +99,7 @@ extern HB_INTERNAL const hb_unicode_funcs_t 
_hb_icu_unicode_funcs;
 #define _hb_unicode_funcs_default _hb_icu_unicode_funcs
 #else
 #define HB_UNICODE_FUNCS_NIL 1
+extern HB_INTERNAL const hb_unicode_funcs_t _hb_unicode_funcs_nil;
 #define _hb_unicode_funcs_default _hb_unicode_funcs_nil
 #endif
 
commit 6efe1eca660135096f05987ac0ef9b635de6cdfd
Author: Behdad Esfahbod 
Date:   Wed Jul 11 15:30:08 2012 -0400

Update git.mk to upstream

diff --git a/git.mk b/git.mk
index ff5c0c3..4da8fe2 100644
--- a/git.mk
+++ b/git.mk
@@ -5,7 +5,7 @@
 # Written by Behdad Esfahbod
 #
 # Copying and distribution of this file, with or without modification,
-# are permitted in any medium without royalty provided the copyright
+# is permitted in any medium without royalty provided the copyright
 # notice and this notice are preserved.
 #
 # The canonical source for this file is https://github.com/behdad/git.mk.
@@ -42,8 +42,14 @@
 # build dir.
 #
 # This file knows how to handle autoconf, automake, libtool, gtk-doc,
-# gnome-doc-utils, yelp.m4, mallard, intltool, gsettings.
+# gnome-doc-utils, yelp.m4, mallard, intltool, gsettings, dejagnu.
 #
+# This makefile provides the following targets:
+#
+# - all: "make all" will build all gitignore files.
+# - gitignore: makes all gitignore files in the current dir and subdirs.
+# - .gitignore: make gitignore file for the current dir.
+# - gitignore-recurse: makes all gitignore files in the subdirs.
 #
 # KNOWN ISSUES:
 #
@@ -97,25 +103,31 @@ $(srcdir)/.gitignore: Makefile.am $(top_srcdir)/git.mk
; do echo /$$x; done; \
fi; \
if test "x$(DOC_MODULE)$(DOC_ID)" = x -o "x$(DOC_LINGUAS)" = x; 
then :; else \
+   for lc in $(DOC_LINGUAS); do \
+   for x in \
+   $(if $(DOC_MODULE),$(DOC_MODULE).xml) \
+   $(DOC_PAGES) \
+   $(DOC_INCLUDES) \
+   ; do echo /$$lc/$$x; done; \
+   done; \
for x in \
-   $(_DOC_C_DOCS) \
-   $(_DOC_LC_DOCS) \
$(_DOC_OMF_ALL) \
$(_DOC_DSK_ALL) \
$(_DOC_H

Re: [HarfBuzz] Create glyph overview based on a specific font feature

[Behdad Esfahbod]

Hi Rolf,

HarfBuzz has the basic support to construct something like what you describe.
 So if you use C/C++, it's easy to do that.  See hb-ot.h and hb-ot-layout.h.
There's also a command-line tool that comes close, but is not exactly what you
want: hb-ot-shape-closure.

behdad

On 06/17/2012 11:01 AM, Rolf Langenhuijzen wrote:
> I'm looking into ways of creating an overview of glyphs that fall into a 
> specific OT feature of a font.
> Eg. an image with all swsh related glyphs, or only ligatures.
> 
> I'm not programming in C/C++, so I'm probably limited into what I can use 
> form Harfbuzz initially to get the needed data of a font.
> I was hoping that was a tool out there that would export glyph ids for 
> example based on some OT feature in a font that I could use to feed into 
> hb-view.
> 
> Any thoughts?
> 
> Kind regards,
> Rolf
> ___
> HarfBuzz mailing list
> HarfBuzz@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/harfbuzz
> 
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Fixes for harfbuzz-ng on Windows MSVC2010

[Behdad Esfahbod]

Hi Koji,

Thanks for the message.  Comments below:

On 07/07/2012 11:37 PM, Koji Ishii wrote:
> Hi,
> 
> I tried to build harfbuzz-ng on Windows MSVC2010 and got a few errors.
> I'm not sure how many people needs this but I'm sharing the patches
> here for who is interested in.
> 
> hb-atomic-private.hh fix is for x86 only. The current code builds fine
> for x64 but not for x86.

I don't understand why this is needed.  According to:

  http://msdn.microsoft.com/en-us/library/1b4s3xf5%28v=vs.80%29.aspx

_InterlockedCompareExchangePointer is available on both x86 and x64.

> hb-unicode-private.hh fix is probably not related with Windows nor
> MSVC, but when neither GLIB nor ICU is available.

Applied.

> hb-uniscribe.cc fix is required for me, maybe Windows SDK was changed?
> I'm using VC2010 SP1, but the fix should be safe for prior compilers I
> believe.

I see.  I just bumped our _WIN32_WINNT version, since we use the OpenType
version of the Uniscribe functions.  Let me know if that addresses your problem.

Cheers,

behdad



> 
> Regards,
> Koji
> 
> commit c5174b35c59ee80ed8e81989ddeb73baabbfe9ed
> Author: Koji Ishii 
> Date:   Sat Jul 7 23:45:23 2012 +0900
> 
> msvc10 fixes
> 
> diff --git a/src/hb-atomic-private.hh b/src/hb-atomic-private.hh
> index 918852d..967b6c0 100644
> --- a/src/hb-atomic-private.hh
> +++ b/src/hb-atomic-private.hh
> @@ -45,7 +45,15 @@
>  #elif !defined(HB_NO_MT) && defined(_MSC_VER) && _MSC_VER >= 1600
> 
>  #include 
> +#if defined(_M_IX86)
> +#define _InterlockedCompareExchangePointer(_Target, _Exchange,
> _Comparand) reinterpret_cast(static_cast<__w64
> long>(_InterlockedCompareExchange( \
> +static_cast(reinterpret_cast<__w64 long volatile
> *>(static_cast(_Target))), \
> +static_cast(reinterpret_cast<__w64 long>(static_cast *>(_Exchange))), \
> +static_cast(reinterpret_cast<__w64 long>(static_cast *>(_Comparand))
> +#pragma intrinsic(_InterlockedExchangeAdd)
> +#else
>  #pragma intrinsic(_InterlockedExchangeAdd, 
> _InterlockedCompareExchangePointer)
> +#endif
> 
>  typedef long hb_atomic_int_t;
>  #define hb_atomic_int_add(AI, V) _InterlockedExchangeAdd (&(AI), (V))
> diff --git a/src/hb-unicode-private.hh b/src/hb-unicode-private.hh
> index eaf151a..c781035 100644
> --- a/src/hb-unicode-private.hh
> +++ b/src/hb-unicode-private.hh
> @@ -99,6 +99,7 @@ extern HB_INTERNAL const hb_unicode_funcs_t
> _hb_icu_unicode_funcs;
>  #define _hb_unicode_funcs_default _hb_icu_unicode_funcs
>  #else
>  #define HB_UNICODE_FUNCS_NIL 1
> +extern HB_INTERNAL const hb_unicode_funcs_t _hb_unicode_funcs_nil;
>  #define _hb_unicode_funcs_default _hb_unicode_funcs_nil
>  #endif
> 
> diff --git a/src/hb-uniscribe.cc b/src/hb-uniscribe.cc
> index b71b00a..3bedc7d 100644
> --- a/src/hb-uniscribe.cc
> +++ b/src/hb-uniscribe.cc
> @@ -29,6 +29,10 @@
>  #include "hb-private.hh"
> 
>  #include 
> +// usp10.h defines UNISCRIBE_OPENTYPE only if _WIN32_WINNT >= 0x0600
> +#if !defined(UNISCRIBE_OPENTYPE) && (_WIN32_WINNT < 0x0600)
> +#define UNISCRIBE_OPENTYPE 0x0100
> +#endif
>  #include 
> 
>  typedef ULONG WIN_ULONG;
> ___
> HarfBuzz mailing list
> HarfBuzz@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/harfbuzz
> 
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] List of languages supported by harfbuzz

[Behdad Esfahbod]

On 07/11/2012 12:10 PM, Samiullah Khawaja wrote:
> Hi,
> 
> I am trying to render Arabic text using harfbuzz. The problem is that when i
> glue the glyphs using the x_advance most of the glyphs are glued correctly.
> but in some cases there is 1 or 2 pixel distance between glyphs.
> 
> I debugged through the harfbuzz code and was able to confirm that the GPOS
> table is present in the font face. But the GPOS data doesn't seem to be
> applied to the buffer. That is why when i get glyph positions only x_advance
> values are there but the x_offset and y_offset values are always 0.
> 
> Am I missing something here? Please help.

Easiest if you post sample code and output.  I don't think anyone can help you
based on the description of the problem.

behdad

> Thanks,
> Sami
> 
> On Thu, Jul 5, 2012 at 7:43 PM, Samiullah Khawaja  > wrote:
> 
> Thanks guys.
> 
> I am trying to link ICU with harfbuzz... will update you guys with it.
> 
> Regards,
> Sami
> 
> 
> On Thu, Jul 5, 2012 at 7:37 PM, Behdad Esfahbod  > wrote:
> 
> On 07/05/2012 08:51 AM, Tom Hacohen wrote:
> > As for the unicode functions: I think they are used in harfbuzz 
> only for
> > script detection, wide-characters and mirrored characters (probably
> more),
> 
> More. Fallback mark positioning, cluster formation, normalization.  If
> you are
> willing to give those all up, well, you may as well not use HarfBuzz
> to begin
> with :).   Not exactly that, but close.
> 
> behdad
> 
> 
> 
> 
> -- 
> Samiullah Khawaja
> Software Engineer
> email: sami.khaw...@gmail.com 
> voice: +(92) 0321-4184324 
> 
> 
> 
> 
> -- 
> Samiullah Khawaja
> Software Engineer
> email: sami.khaw...@gmail.com 
> voice: +(92) 0321-4184324
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] List of languages supported by harfbuzz

[Samiullah Khawaja]

Hi,

I am trying to render Arabic text using harfbuzz. The problem is that when
i glue the glyphs using the x_advance most of the glyphs are glued
correctly. but in some cases there is 1 or 2 pixel distance between glyphs.

I debugged through the harfbuzz code and was able to confirm that the GPOS
table is present in the font face. But the GPOS data doesn't seem to be
applied to the buffer. That is why when i get glyph positions only
x_advance values are there but the x_offset and y_offset values are always
0.

Am I missing something here? Please help.

Thanks,
Sami

On Thu, Jul 5, 2012 at 7:43 PM, Samiullah Khawaja wrote:

> Thanks guys.
>
> I am trying to link ICU with harfbuzz... will update you guys with it.
>
> Regards,
> Sami
>
>
> On Thu, Jul 5, 2012 at 7:37 PM, Behdad Esfahbod  wrote:
>
>> On 07/05/2012 08:51 AM, Tom Hacohen wrote:
>> > As for the unicode functions: I think they are used in harfbuzz only for
>> > script detection, wide-characters and mirrored characters (probably
>> more),
>>
>> More. Fallback mark positioning, cluster formation, normalization.  If
>> you are
>> willing to give those all up, well, you may as well not use HarfBuzz to
>> begin
>> with :).   Not exactly that, but close.
>>
>> behdad
>>
>
>
>
> --
> Samiullah Khawaja
> Software Engineer
> email: sami.khaw...@gmail.com
> voice: +(92) 0321-4184324
>



-- 
Samiullah Khawaja
Software Engineer
email: sami.khaw...@gmail.com
voice: +(92) 0321-4184324
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz