[HarfBuzz] output font OT features (cli tool?)

2012-05-27 Thread Rolf Langenhuijzen
Hello,

Is there a command line tool available (from 
http://cgit.freedesktop.org/harfbuzz/) or anything similar to output 
supported/implemented opentype features of a font?

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


Re: [HarfBuzz] hb-view cuts of part of text/character?

2012-05-27 Thread Behdad Esfahbod
On 05/27/2012 08:51 AM, Rolf Langenhuijzen wrote:
 I was able to get hb-view working on my local machine (mac) so that is cool.
 When outputting some text and character tests to a png I noticed it cuts of 
 part of the glyphs mainly when you apply a font feature like swsh or some 
 aalt.
 
 Can this be prevented so that everything always is inside the outputted image 
 somehow?

Right now the image box is the logical text size plus margins.  What you are
asking for is the ink extents, which I have not implemented yet.  In the mean
time you can use the --margin option to work around that.

behdad


 Regards,
 Rolf
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz


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

2012-05-27 Thread Behdad Esfahbod
 src/hb-ot-shape-complex-indic-machine.rl |2 +-
 src/hb-ot-shape-complex-indic.cc |2 +-
 src/hb-set-private.hh|   31 ---
 src/hb-set.cc|   14 ++
 src/hb-set.h |   13 +
 util/hb-ot-shape-closure.cc  |8 +---
 util/helper-cairo.cc |2 +-
 util/options.cc  |6 +-
 8 files changed, 68 insertions(+), 10 deletions(-)

New commits:
commit 8f8956a55fff95e5ad529d2f124c9528d1f4f81d
Author: Behdad Esfahbod beh...@behdad.org
Date:   Fri May 25 14:30:24 2012 -0400

[util] Add hidden --shaper that is equivalent of --shapers

diff --git a/util/helper-cairo.cc b/util/helper-cairo.cc
index de45fb3..77fd1a6 100644
--- a/util/helper-cairo.cc
+++ b/util/helper-cairo.cc
@@ -297,7 +297,7 @@ helper_cairo_create_context (double w, double h,
 
 
   unsigned int fr, fg, fb, fa, br, bg, bb, ba;
-  br = bg = bb = ba = 255;
+  br = bg = bb = 0; ba = 255;
   sscanf (view_opts-back + (*view_opts-back=='#'), %2x%2x%2x%2x, br, bg, 
bb, ba);
   fr = fg = fb = 0; fa = 255;
   sscanf (view_opts-fore + (*view_opts-fore=='#'), %2x%2x%2x%2x, fr, fg, 
fb, fa);
diff --git a/util/options.cc b/util/options.cc
index 363a150..463daee 100644
--- a/util/options.cc
+++ b/util/options.cc
@@ -1,5 +1,5 @@
 /*
- * Copyright © 2011  Google, Inc.
+ * Copyright © 2011,2012  Google, Inc.
  *
  *  This is part of HarfBuzz, a text shaping library.
  *
@@ -178,6 +178,7 @@ parse_shapers (const char *name G_GNUC_UNUSED,
   GError**error G_GNUC_UNUSED)
 {
   shape_options_t *shape_opts = (shape_options_t *) data;
+  g_free (shape_opts-shapers);
   shape_opts-shapers = g_strsplit (arg, ,, 0);
   return TRUE;
 }
@@ -330,6 +331,7 @@ parse_features (const char *name G_GNUC_UNUSED,
   char *p;
 
   shape_opts-num_features = 0;
+  g_free (shape_opts-features);
   shape_opts-features = NULL;
 
   if (!*s)
@@ -387,6 +389,8 @@ shape_options_t::add_options (option_parser_t *parser)
   {
 {list-shapers,   0, G_OPTION_FLAG_NO_ARG,
  G_OPTION_ARG_CALLBACK,(gpointer) 
list_shapers,   List available shapers and quit,  NULL},
+{shaper, 0, G_OPTION_FLAG_HIDDEN,
+ G_OPTION_ARG_CALLBACK,(gpointer) 
parse_shapers,  Hidden duplicate of --shapers,NULL},
 {shapers,0, 0, G_OPTION_ARG_CALLBACK,(gpointer) 
parse_shapers,  Comma-separated list of shapers to try,list},
 {direction,  0, 0, G_OPTION_ARG_STRING,  this-direction,   
Set text direction (default: auto),   ltr/rtl/ttb/btt},
 {language,   0, 0, G_OPTION_ARG_STRING,  this-language,
Set text language (default: $LANG),   langstr},
commit 29ce446d3161b7ea5874352e5f8eb33cd59338c3
Author: Behdad Esfahbod beh...@behdad.org
Date:   Fri May 25 14:17:54 2012 -0400

Add set iterator

diff --git a/src/hb-set-private.hh b/src/hb-set-private.hh
index df96b99..9d8ba4a 100644
--- a/src/hb-set-private.hh
+++ b/src/hb-set-private.hh
@@ -32,6 +32,7 @@
 #include hb-object-private.hh
 
 
+/* TODO Make this faster and memmory efficient. */
 
 struct _hb_set_t
 {
@@ -51,6 +52,7 @@ struct _hb_set_t
   }
   inline void add (hb_codepoint_t g)
   {
+if (unlikely (g == SENTINEL)) return;
 if (unlikely (g  MAX_G)) return;
 elt (g) |= mask (g);
   }
@@ -107,6 +109,23 @@ struct _hb_set_t
 for (unsigned int i = 0; i  ELTS; i++)
   elts[i] ^= other-elts[i];
   }
+  inline bool next (hb_codepoint_t *codepoint)
+  {
+if (unlikely (*codepoint == SENTINEL)) {
+  hb_codepoint_t i = get_min ();
+  if (i != SENTINEL) {
+*codepoint = i;
+   return true;
+  } else
+return false;
+}
+for (hb_codepoint_t i = *codepoint + 1; i  MAX_G + 1; i++)
+  if (has (i)) {
+*codepoint = i;
+   return true;
+  }
+return false;
+  }
   inline hb_codepoint_t get_min (void) const
   {
 for (unsigned int i = 0; i  ELTS; i++)
@@ -114,7 +133,7 @@ struct _hb_set_t
for (unsigned int j = 0; i  BITS; j++)
  if (elts[i]  (1  j))
return i * BITS + j;
-return 0;
+return SENTINEL;
   }
   inline hb_codepoint_t get_max (void) const
   {
@@ -123,15 +142,16 @@ struct _hb_set_t
for (unsigned int j = BITS; j; j--)
  if (elts[i - 1]  (1  (j - 1)))
return (i - 1) * BITS + (j - 1);
-return 0;
+return SENTINEL;
   }
 
   typedef uint32_t elt_t;
-  static const unsigned int MAX_G = 65536 - 1;
+  static const unsigned int MAX_G = 65536 - 1; /* XXX Fix this... */
   static const unsigned int SHIFT = 5;
   static const unsigned int BITS = (1  SHIFT);
   static const unsigned int MASK = BITS - 1;
   static const unsigned int ELTS = (MAX_G + 1 + (BITS - 1)) / BITS;
+  static  const hb_codepoint_t SENTINEL = (hb_codepoint_t) -1;
 
   elt_t elt 

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

2012-05-27 Thread Behdad Esfahbod
 src/hb-atomic-private.hh |6 +++---
 src/hb-cache-private.hh  |8 
 2 files changed, 7 insertions(+), 7 deletions(-)

New commits:
commit e4b6d503c5575ddbf49249e3fef693d75ae75170
Author: Behdad Esfahbod beh...@behdad.org
Date:   Sun May 27 10:11:13 2012 -0400

Don't use atomic ops in hb_cache_t

We don't care about linearizability, so unprotected int read/write
are enough, no need for expensive memory barriers.  It's a cache,
that's all.

diff --git a/src/hb-cache-private.hh b/src/hb-cache-private.hh
index 7394fbb..a0928a0 100644
--- a/src/hb-cache-private.hh
+++ b/src/hb-cache-private.hh
@@ -36,7 +36,7 @@ template unsigned int key_bits, unsigned int value_bits, 
unsigned int cache_bit
 struct hb_cache_t
 {
   ASSERT_STATIC (key_bits = cache_bits);
-  ASSERT_STATIC (key_bits + value_bits - cache_bits  8 * sizeof 
(hb_atomic_int_t));
+  ASSERT_STATIC (key_bits + value_bits - cache_bits  8 * sizeof (unsigned 
int));
 
   inline void clear (void)
   {
@@ -46,7 +46,7 @@ struct hb_cache_t
   inline bool get (unsigned int key, unsigned int *value)
   {
 unsigned int k = key  ((1cache_bits)-1);
-unsigned int v = hb_atomic_int_get (values[k]);
+unsigned int v = values[k];
 if ((v  value_bits) != (key  cache_bits))
   return false;
   }
@@ -57,12 +57,12 @@ struct hb_cache_t
   return false; /* Overflows */
 unsigned int k = key  ((1cache_bits)-1);
 unsigned int v = ((keycache_bits)value_bits) | value;
-hb_atomic_int_set (values[k], v);
+values[k] = v;
 return true;
   }
 
   private:
-  hb_atomic_int_t values[1cache_bits];
+  unsigned int values[1cache_bits];
 };
 
 typedef hb_cache_t21, 16, 8 hb_cmap_cache_t;
commit 819faa05307aa192015f4b43d8103a35e87d6cc7
Author: Behdad Esfahbod beh...@behdad.org
Date:   Sun May 27 10:09:18 2012 -0400

Minor

diff --git a/src/hb-atomic-private.hh b/src/hb-atomic-private.hh
index b587fde..ba52773 100644
--- a/src/hb-atomic-private.hh
+++ b/src/hb-atomic-private.hh
@@ -78,7 +78,7 @@ typedef volatile int hb_atomic_int_t;
 
 #define HB_ATOMIC_INT_NIL 1
 typedef volatile int hb_atomic_int_t;
-#define hb_atomic_int_add(AI, V)   ((AI) += (V), (AI) - (V))
+#define hb_atomic_int_add(AI, V)   (((AI) += (V)) - (V))
 #define hb_atomic_int_set(AI, V)   ((void) ((AI) = (V)))
 #define hb_atomic_int_get(AI)  (AI)
 
commit 303d5850ec0516e198db241456b0cfc4899ef9c0
Author: Behdad Esfahbod beh...@behdad.org
Date:   Sun May 27 10:01:13 2012 -0400

Fix Windows atomic get/set

According to:
http://msdn.microsoft.com/en-us/library/65tt87y8.aspx

MemoryBarrier() is the right macro to protect these, not _ReadBarrier()
and/or _WriteBarrier().

diff --git a/src/hb-atomic-private.hh b/src/hb-atomic-private.hh
index 684e856..b587fde 100644
--- a/src/hb-atomic-private.hh
+++ b/src/hb-atomic-private.hh
@@ -47,8 +47,8 @@
 #include intrin.h
 typedef long hb_atomic_int_t;
 #define hb_atomic_int_add(AI, V)   _InterlockedExchangeAdd ((AI), (V))
-#define hb_atomic_int_set(AI, V)   _InterlockedExchange ((AI), (V))
-#define hb_atomic_int_get(AI)  (_ReadBarrier (), (AI))
+#define hb_atomic_int_set(AI, V)   ((AI) = (V), MemoryBarrier ())
+#define hb_atomic_int_get(AI)  (MemoryBarrier (), (AI))
 
 
 #elif !defined(HB_NO_MT)  defined(__APPLE__)
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz


Re: [HarfBuzz] output font OT features (cli tool?)

2012-05-27 Thread Jonathan Kew

On 27/5/12 13:51, Behdad Esfahbod wrote:
 On 05/27/2012 08:49 AM, Rolf Langenhuijzen wrote:
 Hello,

 Is there a command line tool available (from 
http://cgit.freedesktop.org/harfbuzz/) or anything similar to output 
supported/implemented opentype features of a font?


 Right now there is one in the src directory, called main.  It uses HB
 internals and not the public API.  Eventually I'll add a hb-inspect or
 something under util/ to do that using the public API.

 behdad

 Rolf

An alternative would be to use otfinfo from Eddie Kohler's LCDF 
TypeTools package, which can report a variety of info about a font, 
including OT features that are present.


JK


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


Re: [HarfBuzz] hb-view cuts of part of text/character?

2012-05-27 Thread Behdad Esfahbod
On 05/27/2012 12:44 PM, Rolf Langenhuijzen wrote:
 I think ink extents as you call them (nice name btw) are implemented in 
 pango-view, correct? I mean should I be using that instead maybe?

I don't remember off the top of my head what pango-view does.  At any rate,
which one you need really depends on what functionality you want.  hb-view
only works for one font, one script, one language, one direction at a time.
pango-view does not have any of these limitations, but does not let you choose
font by file, only by font descriptions.

behdad


 I played with the margins, but sometimes with swashes you just don't know 
 where they end, so you keep changing margin values which is a bit cumbersome.
 
 But thanks!
 
 On May 27, 2012, at 3:14 PM, Behdad Esfahbod wrote:
 
 On 05/27/2012 08:51 AM, Rolf Langenhuijzen wrote:
 I was able to get hb-view working on my local machine (mac) so that is cool.
 When outputting some text and character tests to a png I noticed it cuts of 
 part of the glyphs mainly when you apply a font feature like swsh or some 
 aalt.

 Can this be prevented so that everything always is inside the outputted 
 image somehow?

 Right now the image box is the logical text size plus margins.  What you 
 are
 asking for is the ink extents, which I have not implemented yet.  In the mean
 time you can use the --margin option to work around that.

 behdad


 Regards,
 Rolf
 
 
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz


[HarfBuzz] Hackfest report

2012-05-27 Thread Behdad Esfahbod
Hello HarfBuzz lists,

I promised to write a short report about the hackfest earlier this month.
Here's it is.

Jonathan Kew (Mozilla) and I met at the Google Zurich offices on May 9..11 for
the HarfBuzz Massala Hackfest.  We got together for three days of 12+ hours
intense hacking on the new HarfBuzz Indic shaper, using Wikipedia word list as
test suite.

We started with the Devanagari script, testing against Uniscribe (Windows 7's
implementation).  Initially we were failing on 35% of the words in the list.
Three days, 86 commits, and dozens cups of coffee later, we got down to 0.08%.
 Out of the ~700,000 words, we disagree only on 560.  Of those 560, many are
invalid or meaningless Devanagari sequences, not character combinations that
ever occur in correctly-spelled words. In these cases we are less concerned to
precisely match Uniscribe's behavior.

We discovered a number of bugs or peculiarities in Uniscribe.  We can do
better in some of those cases (and we do).  But for testing purposes, we added
a uniscribe-bug-compatibility mode to the Indic shaper.  The numbers above
were in that mode.

We then tested Gujarati, a script very similar to Devanagari.  Failures were
at a surprisingly low 0.015%!

We then tested Bengali, a script slightly different.  Failures were at 20%,
which was expected since we were not implementing any features of Bengali not
present in Devanagari.  Two changes later and Bengali was just under 3%.

We then tested Malayalam, a script having many features not present in
Devanagari.  Failures were at 14%.

To summarize:

Last year I conjectured that if we have an extensive word list for each
script, we can test our shaper against Uniscribe, and use the number of
failures, and the failing cases themselves, to guide us perfecting our shaper.
 I asked the internationalization team at Google to create a word list per
language out of Wikipedia content, and I received those lists last month.  In
this hackfest we put the idea to test, and it worked out very well!  From now
on, we can take one script at a time, look at the failures, hammer the number
down to sub 0.1% and move to the next.

Note that the percentages here are number of words failing from the corpus.
When we get sub 0.1%, the remaining failures are mostly obscure and unusual
sequences of letters that are not expected to occur in normal text.

If we take into account the frequency of words, the failure percentage is well
below this.  I will calculate that number later, and set a goal of achieving
0.0001% failure rate for the frequency-adjusted data.  That would mean, one in
a million misrendering on real world text.


Perhaps even bigger achievement of the hackathon is: thanks to Jonathan's
help, I now understand how the Indic scripts work, know what the technical
terms mean, and can reason about them!

Good times.  We should do this again.  Tentatively planning for late July in
Toronto when Mozilla developers will be in town.


behdad

PS.  I'm leaning towards shutting down the harfbuzz-indic list and using the
main list for all communication.  Any objections?
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz


Re: [HarfBuzz] [Harfbuzz-indic] Hackfest report

2012-05-27 Thread Shriramana Sharma
On Mon, May 28, 2012 at 7:04 AM, Behdad Esfahbod beh...@behdad.org wrote:
 Perhaps even bigger achievement of the hackathon is: thanks to Jonathan's
 help, I now understand how the Indic scripts work, know what the technical
 terms mean, and can reason about them!

 Good times.  We should do this again.  Tentatively planning for late July in
 Toronto when Mozilla developers will be in town.

Great work and congratulations to both Behdad and Jonathan! We people
are always here in case you need something [and Behdad, you still owe
me a Skype call! ;-)]

 PS.  I'm leaning towards shutting down the harfbuzz-indic list and using the
 main list for all communication.  Any objections?

Um really? Even Unicode has a separate Indic list, and it might be
useful in the future, but seeing as there isn't too much traffic so
far I would not have any particular problem with this. If at all there
is future need for separating the lists, I suppose we could re-create
harfbuzz-indic again?

-- 
Shriramana Sharma
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz


Re: [HarfBuzz] [Harfbuzz-indic] Hackfest report

2012-05-27 Thread Behdad Esfahbod
On 05/27/2012 10:19 PM, Shriramana Sharma wrote:
 On Mon, May 28, 2012 at 7:04 AM, Behdad Esfahbod beh...@behdad.org wrote:
 Perhaps even bigger achievement of the hackathon is: thanks to Jonathan's
 help, I now understand how the Indic scripts work, know what the technical
 terms mean, and can reason about them!

 Good times.  We should do this again.  Tentatively planning for late July in
 Toronto when Mozilla developers will be in town.

 Great work and congratulations to both Behdad and Jonathan! We people
 are always here in case you need something [and Behdad, you still owe
 me a Skype call! ;-)]

Umm.  I have had totally forgotten that.  Lets reschedule for when I have some
more time for Indic.

 PS.  I'm leaning towards shutting down the harfbuzz-indic list and using the
 main list for all communication.  Any objections?
 
 Um really? Even Unicode has a separate Indic list, and it might be
 useful in the future, but seeing as there isn't too much traffic so
 far I would not have any particular problem with this. If at all there
 is future need for separating the lists, I suppose we could re-create
 harfbuzz-indic again?

Well, I myself forget to send Indic stuff to the indic list, and more often
than not such stuff has audience on the main devel list too, that's why I
suggested.

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