[HarfBuzz] output font OT features (cli tool?)
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?
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
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
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?)
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?
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
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
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
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