Koji Ishii | 29 May 16:16 2015
Picon

glyph_func expected behavior for variationSelector?

Sorry if this was asked before, I'm new to this list (and to harfbuzz
too), please accept my apologies if so.

When a variation selector is in the source, such as:
  U+0030 U+FE0E
glyph_func receives U+FE0E as variationSelector argument.

What is the expected behavior for the glyph_func if it cannot find the
variant glyph?

From my observation, if glyph_func returns false, harfbuzz returns 2
glyphs for the above string. So I'm guessing that when the specified
variant does not exist, glyph_func should fallback to the base glyph
and returns true if the base glyph exists.

Could someone confirm whether my understanding above is correct or not?

/koji
_______________________________________________
HarfBuzz mailing list
HarfBuzz <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Eduardo Castineyra | 20 May 15:30 2015
Picon

Visual Studio 9.0 SP1 Warnings

Hi,

There are a couple of warnings I would like to know how to get rid of:

http://pastebin.com/TYfNEtBu

There are a couple of defines not related with HB such as /DPLUGIN, but 
I think they make no difference. Could they or is everyone else getting 
the same warnings?

Thanks!

PS: The first two are mine, please ignore them.

_______________________________________________
HarfBuzz mailing list
HarfBuzz <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Behdad Esfahbod | 21 May 23:01 2015

harfbuzz: Branch 'master'

 src/hb-ot-font.cc |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit f1b44303df0712b433e35e1e1e75115c353b279e
Author: Behdad Esfahbod <behdad <at> behdad.org>
Date:   Thu May 21 14:00:15 2015 -0700

    Fix unary minus operator applied to unsigned int

    Applying unary minus operator to unsigned int causes the following
    warning on MSVS:

      warning C4146: unary minus operator applied to unsigned type, result still unsigned

    Based on patch from Koji Ishi.

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

diff --git a/src/hb-ot-font.cc b/src/hb-ot-font.cc
index 30dcdd4..3656a45 100644
--- a/src/hb-ot-font.cc
+++ b/src/hb-ot-font.cc
 <at>  <at>  -220,7 +220,7  <at>  <at>  hb_ot_get_glyph_v_advance (hb_font_t *font HB_UNUSED,
 			   void *user_data HB_UNUSED)
 {
   const hb_ot_font_t *ot_font = (const hb_ot_font_t *) font_data;
-  return font->em_scale_y (-ot_font->v_metrics.get_advance (glyph));
+  return font->em_scale_y (-(int) ot_font->v_metrics.get_advance (glyph));
 }
(Continue reading)

Behdad Esfahbod | 20 May 02:44 2015

harfbuzz: Branch 'master'

 src/hb-gobject-structs.cc |    1 -
 src/hb-gobject-structs.h  |    8 --------
 2 files changed, 9 deletions(-)

New commits:
commit 1ae6cdb365c15405500d4f50ec98016dde23a26b
Author: Behdad Esfahbod <behdad <at> behdad.org>
Date:   Tue May 19 17:42:30 2015 -0700

    [gobject] Remove hb_language_t workarounds for g-i shortcomings

    Using latest gobject-introspection, I don't seem to be having this
    problem anymore:

      https://bugzilla.gnome.org/show_bug.cgi?id=707656

    Removing that kludge makes language_t behave more like the way I expect it
    in Python.

    Also fixes:
    https://github.com/behdad/harfbuzz/issues/91

diff --git a/src/hb-gobject-structs.cc b/src/hb-gobject-structs.cc
index 1289c4b..6bd6336 100644
--- a/src/hb-gobject-structs.cc
+++ b/src/hb-gobject-structs.cc
 <at>  <at>  -78,4 +78,3  <at>  <at>  HB_DEFINE_VALUE_TYPE (glyph_info)
 HB_DEFINE_VALUE_TYPE (glyph_position)
 HB_DEFINE_VALUE_TYPE (segment_properties)
 HB_DEFINE_VALUE_TYPE (user_data_key)
(Continue reading)

Behdad Esfahbod | 20 May 02:21 2015

harfbuzz: Branch 'master'

 src/hb-gobject-structs.cc |   73 ++++++++++------------------------------------
 1 file changed, 17 insertions(+), 56 deletions(-)

New commits:
commit ece434fa0fec6754e5164d881c1e967376729eca
Author: Behdad Esfahbod <behdad <at> behdad.org>
Date:   Tue May 19 17:20:58 2015 -0700

    [gobject] Macroize value types

    Fixes user_data_t

diff --git a/src/hb-gobject-structs.cc b/src/hb-gobject-structs.cc
index 2451b66..1289c4b 100644
--- a/src/hb-gobject-structs.cc
+++ b/src/hb-gobject-structs.cc
 <at>  <at>  -54,6 +54,17  <at>  <at>  hb_gobject_##name##_get_type (void) \
 #define HB_DEFINE_OBJECT_TYPE(name) \
 	HB_DEFINE_BOXED_TYPE (name, hb_##name##_reference, hb_##name##_destroy);

+#define HB_DEFINE_VALUE_TYPE(name) \
+	static hb_##name##_t *_hb_##name##_reference (const hb_##name##_t *l) \
+	{ \
+	  hb_##name##_t *c = (hb_##name##_t *) calloc (1, sizeof (hb_##name##_t)); \
+	  if (unlikely (!c)) return NULL; \
+	  *c = *l; \
+	  return c; \
+	} \
+	static void _hb_##name##_destroy (hb_##name##_t *l) { free (l); } \
+	HB_DEFINE_BOXED_TYPE (name, _hb_##name##_reference, _hb_##name##_destroy);
(Continue reading)

Behdad Esfahbod | 19 May 03:38 2015

harfbuzz: Branch 'master' - 2 commits

 src/hb-ft.cc       |   16 ++++++++++------
 util/ansi-print.cc |   26 +++++++++++++-------------
 2 files changed, 23 insertions(+), 19 deletions(-)

New commits:
commit 9df099b4837df722e738675af318efcc9ac39a78
Author: Behdad Esfahbod <behdad@...>
Date:   Mon May 18 18:37:06 2015 -0700

    [ft] Don't set *glyph in get_glyph() if glyph not found

diff --git a/src/hb-ft.cc b/src/hb-ft.cc
index 322f93a..3d5cd63 100644
--- a/src/hb-ft.cc
+++ b/src/hb-ft.cc
 <at>  <at>  -75,15 +75,19  <at>  <at>  hb_ft_get_glyph (hb_font_t *font HB_UNUSED,
 		 void *user_data HB_UNUSED)

 {
+  unsigned int g;
   FT_Face ft_face = (FT_Face) font_data;

-  if (unlikely (variation_selector)) {
-    *glyph = FT_Face_GetCharVariantIndex (ft_face, unicode, variation_selector);
-    return *glyph != 0;
-  }
+  if (likely (!variation_selector))
+    g = FT_Get_Char_Index (ft_face, unicode);
+  else
+    g = FT_Face_GetCharVariantIndex (ft_face, unicode, variation_selector);
(Continue reading)

Martin Hosken | 18 May 14:50 2015
Picon

Loading Graphite dynamically

Dear All,

A number of people have asked me for a mechanism by which graphite may be dynamically loaded only when a
Graphite font is used. I've struggled with the notion of this, but I think I understand it now. I hope that
this can help everyone to have what they want for minimal cost.

I've submitted a pull request on github for a patch that does the above.

This patch adds dynamic loading of graphite support for graphite fonts in harfbuzz. The three way
configure option is now: --with-graphite2=no means no graphite support. --with-graphite2=yes means
to build and link against an existing graphite library. --with-graphite2=auto means to build
independently of any graphite library but to attempt to dynamically load graphite when a graphite font is encountered.

This patch has been built and tested on linux only at the moment.

Yours,
Martin
_______________________________________________
HarfBuzz mailing list
HarfBuzz <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Louis Semprini | 11 May 09:56 2015
Picon

how to detect missing glyphs e.g. for font substitition

What is the most reliable and non-font-dependent way to detect whether a string being shaped by hb_shape() has led to any missing glyphs, and to identify where those glyphs occur?

When I use the word "missing glyph" here I mean a glyph that is not what the user intended for that code point in that context, whether that be a little tofu box, a magical hex box, a space glyph (with or without zero advance), a diamond, or anything else that has substituted for the glyph that the user really wanted.

In particular, after calling hb_shape(),

- can we be guaranteed that a hb_glyph_info_t.codepoint (which is actually a glyph index despite the name) of 0 always means "missing glyph" ?

- can we be guaranteed that hb_glyph_info_t.codepoint==0 is the only possible value that means "missing glyph" and that no glyph index values OTHER THAN 0 also mean "missing glyph"?

If not, is there a better way to detect missing glyphs using the output of hb_shape(), or some other Harfbuzz call?

If the answer is "yes, except the following cases used with the following shapers," that might still be useful, so please elaborate.

Or, must Harfbuzz callers first do a complete, separate pass where they run all code points of the input through some kind of mapping routine that uses the fonts' 'cmap' and other tables?  The latter would be a shame because it would require the Harfbuzz caller to duplicate a vast amount of the complexity that is nicely hidden in Harfbuzz in their own code.  It's also a shame because in most cases, no font substitution would be needed and so it would be inefficient in the average case.

As to the question of what a Harfbuzz caller would/could do after knowing that a missing glyph existed, in order to fix the problem, that totally depends on the particular application for which Harfbuzz is being used.  If the set of possible input code points and the set of possible fonts used to render them were totally unconstrained, of course that requires a full general-purpose font substitution scheme like that built into major OSes and is a massive project that may well depend on a deep knowledge of OpenType tables such as the unicode range flags in the 'OS/2' table and others.  But there are plenty of other useful cases where a Harfbuzz caller could make use of the 'missing glyph' information to institute a quick and effective solution.  For example, any app which displays data whose total set of code points is known (either static content or dynamic content where the set of code points that need to be supported is limited by the market where the app is sold) can reliably choose (at code authoring time) a particular fallback font to use if the user's choice of font leads to missing glyphs. 

For such situations it would be nice to hang that font substitution decision off of a "there were missing glyphs" result from hb_shape() since it would be by far the rare case, and the common case of OK glyphs would therefore be faster.  So that's why I am asking if there is any such way.

Thanks again all for your helpful answers in this forum.

_______________________________________________
HarfBuzz mailing list
HarfBuzz <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Behdad Esfahbod | 7 May 19:46 2015

harfbuzz: Branch 'master' - 2 commits

 .travis.yml |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit fbecde3d5c5c6d5af315140e4966dc850388ad63
Merge: 5801521 74139f9
Author: Behdad Esfahbod <behdad <at> behdad.org>
Date:   Thu May 7 10:46:42 2015 -0700

    Merge pull request #105 from ebraminio/master

    Fix Travis CI config to pass again

commit 74139f9839f69ea3e7a1d17627f52fea6c06d58a
Author: Ebrahim Byagowi <ebrahim <at> gnu.org>
Date:   Thu May 7 13:09:32 2015 +0000

    Fix Travis CI config to pass again

diff --git a/.travis.yml b/.travis.yml
index c491189..894b613 100644
--- a/.travis.yml
+++ b/.travis.yml
 <at>  <at>  -15,7 +15,7  <at>  <at>  install:
   - sudo apt-get install libcairo2-dev # for utils
   - sudo apt-get install libicu-dev # for extra unicode functions
   - sudo apt-get install libgraphite2-dev # for extra shapers
-  - : #sudo apt-get install libgirepository1.0-dev # for gobject-introspection
+  - #sudo apt-get install libgirepository1.0-dev # for gobject-introspection
   - sudo pip install cpp-coveralls # for coveralls.io code coverage tracking
 script:
   - NOCONFIGURE=1 ./autogen.sh
_______________________________________________
HarfBuzz mailing list
HarfBuzz <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Adam Twardoch (List | 7 May 00:33 2015

Choosing "dev2" vs "deva" OT script for shaping

If a font includes both a "dev2" and a "deva" implementation for Devanagari OT shaping, is there an
API-compliant way to choose one over the other? 

A.

Sent from my mobile phone.
_______________________________________________
HarfBuzz mailing list
HarfBuzz <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Louis Semprini | 6 May 13:21 2015
Picon

How to use 'locl' feature of Noto Sans CJK with Harfbuzz?

What is the specific Harfbuzz API call and arguments to use in order to select the Simplified Chinese, Traditional Chinese, Japanese, or Korean varants in Google's Noto Sans CJK font, which uses the 'locl' feature as explained here:

https://www.google.com/get/noto/cjk.html

in particular, what exact arguments to I need to choose Simplified Chinese vs. Traditional Chinese ?

Apparently, not all variant glyphs were given unique code points during Han unification, so sometimes I need to hint the shaper which glyph to choose.

Thanks!

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

Gmane