[HarfBuzz] harfbuzz-ng: Branch 'master' - 2 commits
src/hb-ot-shape-complex-indic.cc |6 +++---
src/test-would-substitute.cc |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
New commits:
commit 8ba8042821e4581fe4e87419e58c823520441205
Author: Behdad Esfahbod
Date: Fri Aug 3 18:54:54 2012 -0700
[Indic] Fix consonant position font lookup logic
Oops. I broken this badly and the test suite did not notice. That
worries me. Have to investigate.
diff --git a/src/hb-ot-shape-complex-indic.cc b/src/hb-ot-shape-complex-indic.cc
index 7dde77d..ccc4a9d 100644
--- a/src/hb-ot-shape-complex-indic.cc
+++ b/src/hb-ot-shape-complex-indic.cc
@@ -340,9 +340,9 @@ consonant_position_from_face (const indic_shape_plan_t
*indic_plan,
hb_codepoint_t *glyphs, unsigned int glyphs_len,
hb_face_t *face)
{
- if (indic_plan->pref.would_substitute (glyphs, ARRAY_LENGTH (glyphs), face))
return POS_BELOW_C;
- if (indic_plan->blwf.would_substitute (glyphs, ARRAY_LENGTH (glyphs), face))
return POS_BELOW_C;
- if (indic_plan->pstf.would_substitute (glyphs, ARRAY_LENGTH (glyphs), face))
return POS_POST_C;
+ if (indic_plan->pref.would_substitute (glyphs, glyphs_len, face)) return
POS_BELOW_C;
+ if (indic_plan->blwf.would_substitute (glyphs, glyphs_len, face)) return
POS_BELOW_C;
+ if (indic_plan->pstf.would_substitute (glyphs, glyphs_len, face)) return
POS_POST_C;
return POS_BASE_C;
}
commit abd0c05f1f7f0546593bb2f1c4d59db12cb32e46
Author: Behdad Esfahbod
Date: Fri Aug 3 18:45:05 2012 -0700
Minor
diff --git a/src/test-would-substitute.cc b/src/test-would-substitute.cc
index 2a2c3ef..bf64a29 100644
--- a/src/test-would-substitute.cc
+++ b/src/test-would-substitute.cc
@@ -47,7 +47,7 @@ main (int argc, char **argv)
hb_blob_t *blob = NULL;
if (argc != 4 && argc != 5) {
-fprintf (stderr, "usage: %s lookup-index first-glyph [second-glyph]\n",
argv[0]);
+fprintf (stderr, "usage: %s font-file lookup-index first-glyph
[second-glyph]\n", argv[0]);
exit (1);
}
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] glyph advance difference between coretext and ot backend
Has anyone been looking into this? behdad On 07/31/2012 12:22 PM, Jonathan Kew wrote: > On 31/7/12 19:29, Behdad Esfahbod wrote: >> Interesting. I'll take a look. > > It might be worth calling CTFontGetUnitsPerEm to see what Core Text considers > the em-square of the font to be. ISTR that I've seen cases where Core > Graphics, at least, "normalizes" the em-units of certain fonts that aren't > using a "typical" size; I'm not sure if that carries through to Core Text > metrics as well, but it might be a factor here... > > JK > >> >> On 07/31/2012 01:49 PM, Rolf Langenhuijzen wrote: >>> I did a similar test with 2 fonts and it was different between the two.. >>> could it be some internal font thing that is causing this? >>> >>> OSX: >>> hb-shape --shapers=coretext "/dev/fonts/MaiolaPro-Regular.otf" ABC >>> [A=0+670|B=1+565|C=2+640] >>> >>> hb-shape --shapers=ot "/dev/fonts/MaiolaPro-Regular.otf" ABC >>> [A=0+660|B=1+555|C=2+630] >>> >>> hb-shape --shapers=ot "/dev/Whitney-Book-Pro.otf" ABC >>> [A=0+691|B=1+547|C=2+638] >>> >>> hb-shape --shapers=coretext "/dev/Whitney-Book-Pro.otf" ABC >>> [A=0+691|B=1+547|C=2+638] >>> >>> I tried on Ubuntu: >>> hb-shape --shapers=ot "MaiolaPro-Regular.otf" ABC >>> [A=0+660|B=1+555|C=2+630] >>> >>> So the same as on OSX, not the same as with coretext as you are getting… >>> >>> Regards, >>> Rolf >>> >>> On Jul 31, 2012, at 12:42 PM, Dohyun Kim wrote: >>> Hi, I have compiled harfbuzz-ng on Mac OS X Lion. While testing some fonts, I encounterd a strange mismatch between coretext and ot backends: $ ./hb-shape --shapers=coretext /System/Library/Fonts/AppleGothic.ttf ABC [gid41=0+726|gid42=1+644|gid43=2+685] $ ./hb-shape --shapers=ot /System/Library/Fonts/AppleGothic.ttf ABC [gid41=0+743|gid42=1+659|gid43=2+701] The Units Per Em of AppleGothic is 1000. However, ot backend under Mac seems to consider upem as 1024 and increase glyph widths in proportion, resulting in incorrect glyph positions. BTW, ot backend on ubuntu machine gives the same result as coretext under Mac. Best, -- Dohyun Kim College of Law, Dongguk University Seoul, Republic of Korea ___ 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 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 mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Memory leak when destroying hb-ft-fonts after shaping
On 08/01/2012 12:10 PM, moritz blanckenburg wrote: > Here's a short program that recreates the bug: > https://gist.github.com/3229809 > > Some notes: > - The leak disappears when shaping is done without extra features. > (This might suggest that the bug is related to the new shape-plan stuff.) > - The leak probably doesn't depend on the font. Fixed. > Can you recommend me a revision of HarfBuzz that's been proven stable > enough for daily use? I'm probably not the right person to ask. AFAIC, latest master is always the best to use! More seriously, it's back to being fairly stable now. I'll make a snapshot after fixing the graphite backend. behdad ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz-ng: Branch 'master' - 2 commits
src/hb-ot-shape.cc |7 ++-
src/hb-shape-plan.cc |2 ++
2 files changed, 4 insertions(+), 5 deletions(-)
New commits:
commit 46ee108ef80f5d4675899862698a8c34d8fcfab5
Author: Behdad Esfahbod
Date: Fri Aug 3 18:21:13 2012 -0700
Fix leak
diff --git a/src/hb-shape-plan.cc b/src/hb-shape-plan.cc
index 974c370..ddfb501 100644
--- a/src/hb-shape-plan.cc
+++ b/src/hb-shape-plan.cc
@@ -148,6 +148,8 @@ hb_shape_plan_destroy (hb_shape_plan_t *shape_plan)
#include "hb-shaper-list.hh"
#undef HB_SHAPER_IMPLEMENT
+ hb_face_destroy (shape_plan->face);
+
free (shape_plan);
}
commit 71baea0062da4d7f143d62da38492a0813814e49
Author: Behdad Esfahbod
Date: Fri Aug 3 17:40:07 2012 -0700
[OT] Use general-category, not GDEF class, to decide to zero mark advances
At this point, the GDEF glyph synthesis looks pointless. Not that I
have many fonts without GDEF lying around.
As for mark advance zeroing when GPOS not available, that also is being
replaced by proper fallback mark positioning soon.
diff --git a/src/hb-ot-shape.cc b/src/hb-ot-shape.cc
index 28bb1f9..08457be 100644
--- a/src/hb-ot-shape.cc
+++ b/src/hb-ot-shape.cc
@@ -347,10 +347,7 @@ hb_synthesize_glyph_classes (hb_ot_shape_context_t *c)
{
unsigned int count = c->buffer->len;
for (unsigned int i = 0; i < count; i++)
-c->buffer->info[i].glyph_props() = FLAG
(_hb_glyph_info_get_general_category (&c->buffer->info[i])) &
- (FLAG
(HB_UNICODE_GENERAL_CATEGORY_SPACING_MARK) |
- FLAG
(HB_UNICODE_GENERAL_CATEGORY_ENCLOSING_MARK) |
- FLAG
(HB_UNICODE_GENERAL_CATEGORY_NON_SPACING_MARK)) ?
+c->buffer->info[i].glyph_props() = _hb_glyph_info_get_general_category
(&c->buffer->info[i]) == HB_UNICODE_GENERAL_CATEGORY_NON_SPACING_MARK ?
HB_OT_LAYOUT_GLYPH_CLASS_MARK :
HB_OT_LAYOUT_GLYPH_CLASS_BASE_GLYPH;
}
@@ -398,7 +395,7 @@ hb_zero_mark_advances (hb_ot_shape_context_t *c)
{
unsigned int count = c->buffer->len;
for (unsigned int i = 0; i < count; i++)
-if (c->buffer->info[i].glyph_props() & HB_OT_LAYOUT_GLYPH_CLASS_MARK)
+if (_hb_glyph_info_get_general_category (&c->buffer->info[i]) ==
HB_UNICODE_GENERAL_CATEGORY_NON_SPACING_MARK)
{
c->buffer->pos[i].x_advance = 0;
c->buffer->pos[i].y_advance = 0;
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz-ng: Branch 'master'
src/hb-glib.cc |4 ++--
src/hb-icu.cc |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
New commits:
commit 3a7e137a68ec8f723dc3afa89c918ca2df7ff6bf
Author: Behdad Esfahbod
Date: Fri Aug 3 17:23:40 2012 -0700
Dn't use gint
diff --git a/src/hb-glib.cc b/src/hb-glib.cc
index fe2368a..7af92cc 100644
--- a/src/hb-glib.cc
+++ b/src/hb-glib.cc
@@ -255,7 +255,7 @@ hb_glib_unicode_compose (hb_unicode_funcs_t *ufuncs
HB_UNUSED,
gchar utf8[12];
gchar *normalized;
- gint len;
+ int len;
hb_bool_t ret;
len = g_unichar_to_utf8 (a, utf8);
@@ -292,7 +292,7 @@ hb_glib_unicode_decompose (hb_unicode_funcs_t *ufuncs
HB_UNUSED,
gchar utf8[6];
gchar *normalized;
- gint len;
+ int len;
hb_bool_t ret;
len = g_unichar_to_utf8 (ab, utf8);
diff --git a/src/hb-icu.cc b/src/hb-icu.cc
index 4694e31..d7fd185 100644
--- a/src/hb-icu.cc
+++ b/src/hb-icu.cc
@@ -278,7 +278,7 @@ hb_icu_unicode_decompose_compatibility (hb_unicode_funcs_t
*ufuncs HB_UNUSED,
void *user_data HB_UNUSED)
{
UChar utf16[2], normalized[2 * HB_UNICODE_MAX_DECOMPOSITION_LEN + 1];
- gint len;
+ int len;
int32_t utf32_len;
hb_bool_t err;
UErrorCode icu_err;
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
