Re: [HarfBuzz] 'vert' substitutions in CJK fonts
On 02/05/2013 01:50 AM, suzuki toshiya wrote: Hi, Thank you for opening the interesting discussion. I think, the script names in OpenType spec are not identical with the block names in Unicode; kana does not specify the small group of katakana and hiragana, but also specify the group including katakana, hiragana, CJK ideographs, CJK punctuations, CJK symbols etc etc. They are not identical to Unicode, but kana indeed means just Katakana and Hiragana in OpenType, at least according to the specification: https://www.microsoft.com/typography/otspec/scripttags.htm The lack of detail in the OpenType specification is really bad... in this case it just says it's not always similar to Unicode but doesn't explain how it differs from it either. :( When I worked for poppler (PDF rendering library), I got similar problem; http://lists.freedesktop.org/archives/poppler/2012-March/008860.html I should note that the default language system strategy would not work well with (old versions of?) Batang font (a Korean font bundled to Microsoft Windows). Hmm, interesting... but lack of language-specific matching is not the problem here. when vertical text is requested without embedded font, how OpenType layout feature should be configured; I used the combinations CHN/hani for Chinese Simplified or Traditional, JAN/kana for Japanese, KOR/hang for Korean. But it was designed to fit the internal design of the poppler, more comprehensive consideration would be expected for real i18n software. So you use a fixed script for a given language? I don't know, but this seems to be quite hacky. Often you don't even know what language you're going to display. This might work in poppler's case, but in my case (render some line of Unicode text with arbitrary languages) it does not. Best regards Grigori ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Font fallback strategies
On 10/25/2012 09:44 PM, Behdad Esfahbod wrote: You need to tell us more about the context (system, etc) I think. You can use Fontconfig. It's realtime rendering subtitle rendering I'm doing, and the subtitles are possibly animated, so it must be fast. I'm using fontconfig, but I'm just doing greedy codepoint by codepoint font selection at the moment, i.e. text is processed in sequence from start to end, and every time a glyph isn't found in the current font's cmap, a new font is searched and selected. This kind of fallback selection doesn't cut it in some cases (run of same script/language text is split up irregularly when a codepoint is missing in current font) and fallback is expensive sometimes (needs to check a huge number of fonts for coverage). Before investing much time into testing various strategies, I thought it might be a good idea to ask here. Note that fallback order should be per-language, not per-script. What does that mean in practice? Scripts often support multiple languages, so how should I map the script of a codepoint to a language? CSS recommends trying to choose fallback font for entire grapheme clusters at a time, but I don't know any implementation that does that. I tried wading through Firefox source code (Firefox seems to be doing a very good job at fallback), but never really found the crucial part of the code or what the underlying algorithm is. :) Mozilla's codebase is very big and complex. As far as I can see, there are a few maxims for choosing fallbacks: the number of fonts used for a run of text should be minimal, every appearance of a specific character (or grapheme cluster) should always be rendered by the same font, and sequences of characters using the same font should be as long as possible. It doesn't seem to be possible to fulfill all these in an efficient manner, so what compromises work well in practice? What are common fallback implementations doing? Best regards Grigori ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] x_offset and y_offset
On 10/22/2012 12:40 PM, Samiullah Khawaja wrote: Is x_offset is like the left bearing difference of the glyph in freetype glyph_bitmap-left and the y_offset is like the top bearing of the glyph in freetype glyph_bitmap-top (upwards distance from baseline) In my understanding, the offsets shouldn't be interpreted like that. They move the glyph position, but do not influence its metrics or advance. Are these values 16.16 fractional values or 26.6 fractional values? The values are in 26.6 format. Best regards Grigori ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Questions about interacting with HarfBuzz
Hey Lorant, let me give a try to answer your questions. I'm not an expert on HarfBuzz or OpenType by any means, so YMMV. On 10/02/2012 10:51 PM, Lóránt Pintér wrote: * *How should I find out if a glyph returned by hb_shape() is a ligature?* I found some static functions in hb-ot-layout-private.hh like is_a_ligature(), but these are not C externs, so I cannot access them from JavaScript. Is there some other way supported by HarfBuzz, or shall I re-implement these functions in JS by inspecting the glyph_info_t struct? As far as I can see (in the OpenType specification) you should either check the glyph class or the ligature caret coverage table. The hb_ot_layout_get_ligature_carets() function does a check against the coverage table. It should return 0 if a glyph is not a ligature, and a value greater than zero otherwise. * *How can I find internal x_advance positions inside a ligature?* The GDEF table should contain information about this. Does HarfBuzz expose it in any way? A ligature is a single glyph. There is no such thing as an internal advance. * *How should I find out if a character was split into multiple glyphs?* I guess the cluster field of a glyph_info_t is about this, right? If I have a blown-up character, how can I find the caret positions that I should use? Yup, the cluster value basically specifies the index of the codepoint in the shaped text the glyph belongs to. Well, more or less, as far as I understand. There's a function for determining caret positions, hb_ot_layout_get_ligature_carets(). I haven't used it yet, but it looks easy to use. Just pass the glyph index and a small array, and it will be filled with caret positions. * *Can HarfBuzz handle the Apple kern, morx etc. tables?* If not, is it safe to use FontForge to convert these fonts to use OpenType's GPOS/GSUB etc.? This is not very encouraging: http://fontforge.org/gposgsub.html Both TrueType (fallback) and OpenType kerning are supported. The only caveat is that you can't disable TrueType kerning (yet), it is always enabled. * *Which features are turned on by default?* I can see that ligatures and kerning are turned on for my simple Latin text, and I can successfully turn them off by supplying features -kern and -liga, but I'm still curious what the defaults are. Well, reasonable defaults are used that work well with most scripts and fonts. See hb-ot-shape.cc. * *When kerning is applied, I get funny x_advances.* This might be an error on my side, but currently when a pair of glyphs is kerned, the first character get's an x_advance that seems to have something like 42949017 subtracted from it. Because ligature substitution works perfectly, I assume GSUB table parsing works fine, so I don't see why GPOS would fail. Any pointers here? No idea. I am using Freetype to implement the font callbacks, and advances are fine, both for TrueType and OpenType kerning. Fallback kerning calls into the font functions, I can imagine that it might break things if the callbacks aren't implemented correctly. Best regards Grigori ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Harfbuzz on Windows
On 07/25/2012 09:31 AM, Samiullah Khawaja wrote: Hi Behdad, I want to build harfbuzz for windows... What replacement of unicode functions should I use? Is there any native support in windows that I can use to provide the unicode functions. ICU is (more or less) the recommended choice. However, I actually had less trouble getting glib to work on Windows, but that might be fault of mingw. Unfortunately both ICU and glib are huge frameworks with their own set of dependencies. A stripped-down standalone library that provides a unicode character database and nothing more would be great to have. I implemented HarfBuzz support in libass, but projects like Aegisub or VLC still ship without HarfBuzz on Windows because the ICU/glib requirement is such a pain. :( Best regards Grigori ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] [PATCH] Build system fixes
On 10/15/2011 12:55 AM, Grigori Goronzy wrote: Please let me know what you think about these additions and fixes. Ping? ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] [PATCH] Build system fixes
Hi,
for some time I've been using various fixes for the build system in my
personal tree. See the attachments.
Patch 1 adds a proper Requires field to the .pc file to make static
linking work correctly.
Patch 2 and 3 fix icu building, especially without glib.
Patch 4 adds toggles for glib, icu and uniscribe support (uniscribe
disabled by default, because apparently it's mostly for testing purposes).
Patch 5 is not specific to the build system. This implements atomic
reference counting and mutexes with GCC's intrinsics, as a fallback if
there's no glib or win32 support for these operations.
Please let me know what you think about these additions and fixes.
Best regards,
Grigori
From e80e911e8af19f525a4ba7f47b4524518e14b1f6 Mon Sep 17 00:00:00 2001
From: Grigori Goronzy greg@blackbox
Date: Tue, 23 Aug 2011 14:25:35 +0200
Subject: [PATCH 5/5] Use GCC builtin atomics, if no library support
This uses GCC builtin atomics for reference counting and a simple mutex
implementation to make harfbuzz threadsafe without any support from
system libraries or glib. This codepath is only used as a fallback.
---
src/hb-mutex-private.hh | 10 ++
src/hb-object-private.hh |8
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/src/hb-mutex-private.hh b/src/hb-mutex-private.hh
index 9855a56..d841178 100644
--- a/src/hb-mutex-private.hh
+++ b/src/hb-mutex-private.hh
@@ -64,6 +64,16 @@ typedef CRITICAL_SECTION hb_mutex_impl_t;
#define hb_mutex_impl_free(M) DeleteCriticalSection (M)
+#elif defined(__GNUC__)
+
+typedef volatile int hb_mutex_impl_t;
+#define HB_MUTEX_IMPL_INIT 0
+#define hb_mutex_impl_init(M) __sync_lock_test_and_set((M), 0)
+#define hb_mutex_impl_lock(M) while (__sync_lock_test_and_set((M),
1));
+#define hb_mutex_impl_unlock(M)__sync_lock_release((M))
+#define hb_mutex_impl_free(M)
+
+
#else
#warning Could not find any system to define platform macros, library will
NOT be thread-safe
diff --git a/src/hb-object-private.hh b/src/hb-object-private.hh
index 72ed8ba..db5095f 100644
--- a/src/hb-object-private.hh
+++ b/src/hb-object-private.hh
@@ -73,6 +73,14 @@ typedef long hb_atomic_int_t;
#define hb_atomic_int_set(AI, V) ((void) _InterlockedExchange ((AI),
(V)))
+#elif defined(__GNUC__)
+
+typedef volatile int hb_atomic_int_t;
+#define hb_atomic_int_add(AI, V)__sync_fetch_and_add((AI), (V))
+#define hb_atomic_int_get(AI) (__sync_synchronize(), (AI))
+#define hb_atomic_int_set(AI, V)__sync_lock_test_and_set((AI),
(V))
+
+
#else
#warning Could not find any system to define atomic_int macros, library will
NOT be thread-safe
--
1.7.2.3
From f354be2b3a044ed21fe221c94c7164112d890ebe Mon Sep 17 00:00:00 2001
From: Grigori Goronzy greg@blackbox
Date: Thu, 13 Oct 2011 04:44:08 +0200
Subject: [PATCH 2/5] icu: fix pkg-config check, use the correct package name
---
configure.ac |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index 1b8a3ff..d3f46dd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -112,7 +112,7 @@ AM_CONDITIONAL(HAVE_CAIRO_FT, $have_cairo_ft)
dnl ==
-PKG_CHECK_MODULES(ICU, icu, have_icu=true, [
+PKG_CHECK_MODULES(ICU, icu-uc, have_icu=true, [
have_icu=true
AC_CHECK_HEADERS(unicode/uchar.h,, have_icu=false)
AC_MSG_CHECKING([for libicuuc])
--
1.7.2.3
From 141b8794c69a3a40617d4b871b3c41e20d9de94a Mon Sep 17 00:00:00 2001
From: Grigori Goronzy greg@blackbox
Date: Sat, 15 Oct 2011 00:06:56 +0200
Subject: [PATCH 3/5] icu: do not use glib types
---
src/hb-icu.cc |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/hb-icu.cc b/src/hb-icu.cc
index 0f5ed1c..cc551d3 100644
--- a/src/hb-icu.cc
+++ b/src/hb-icu.cc
@@ -175,7 +175,7 @@ hb_icu_unicode_compose (hb_unicode_funcs_t *ufuncs
HB_UNUSED,
return FALSE;
UChar utf16[4], normalized[5];
- gint len;
+ int len;
hb_bool_t ret, err;
UErrorCode icu_err;
@@ -209,7 +209,7 @@ hb_icu_unicode_decompose (hb_unicode_funcs_t *ufuncs
HB_UNUSED,
void *user_data HB_UNUSED)
{
UChar utf16[2], normalized[20];
- gint len;
+ int len;
hb_bool_t ret, err;
UErrorCode icu_err;
--
1.7.2.3
From 449fce8c9842cd81a8d7dfd680dfc60218075059 Mon Sep 17 00:00:00 2001
From: Grigori Goronzy greg@blackbox
Date: Thu, 13 Oct 2011 05:05:32 +0200
Subject: [PATCH 4/5] configure: add toggles for glib/ICU/uniscribe
---
configure.ac | 103 +++---
1 files changed, 62 insertions(+), 41 deletions(-)
diff --git a/configure.ac b/configure.ac
index d3f46dd..6b42cf2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -73,27 +73,40 @@ if test x$GCC = xyes; then
esac
fi
+AC_ARG_ENABLE([uniscribe], AS_HELP_STRING([--enable-uniscribe],
+[enable uniscribe backend
[HarfBuzz] Disable uniscribe backend
Hi, the Uniscribe backend doesn't work on Windows XP and unnecessarily bloats HarfBuzz on Windows. According to commit logs it only is for testing purposes anyway, so can we have an option to disable it at build time? Grigori PS: what happened to the 0.8 release and the promises of API stability? ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Disable uniscribe backend
Hi again, here's a patch that adds a simple configure switch to select Uniscribe. I disabled Uniscribe support by default. Similar switches for ICU and glib might be handy as well. Grigori From 7f0b6832cc17e76012d249c7ccb536da59aa35a3 Mon Sep 17 00:00:00 2001 From: Grigori Goronzy greg@blackbox Date: Sat, 20 Aug 2011 18:34:23 +0200 Subject: [PATCH 1/2] Add Uniscribe configure toggle, disabled by default --- configure.ac |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index f42fb3c..82b5df1 100644 --- a/configure.ac +++ b/configure.ac @@ -71,6 +71,9 @@ if test x$GCC = xyes; then esac fi +AC_ARG_ENABLE([uniscribe], AS_HELP_STRING([--enable-uniscribe], +[enable uniscribe backend @:@default=no@:@])) + dnl == PKG_CHECK_MODULES(GLIB, glib-2.0 = 2.16, have_glib=true, have_glib=false) @@ -157,7 +160,9 @@ AM_CONDITIONAL(HAVE_OT, $have_ot) dnl === -AC_CHECK_HEADERS(usp10.h windows.h, have_uniscribe=true, have_uniscribe=false) +if test x$enable_uniscribe = xyes; then +AC_CHECK_HEADERS(usp10.h windowsx.h, have_uniscribe=true, have_uniscribe=false) +fi if $have_uniscribe; then UNISCRIBE_CFLAGS= UNISCRIBE_LIBS=-lusp10 -lgdi32 -- 1.7.2.3 ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] harfbuzz-ng: Branch 'master' - 3 commits
On 07/31/2011 07:50 PM, Behdad Esfahbod wrote: New commits: commit 9da0487cd452d780673e24329ce03e174a4ef83b Author: Behdad Esfahbod beh...@behdad.org Date: Sun Jul 31 13:46:44 2011 -0400 [Indic] Support ZWJ/ZWNJ Brings test-shape-complex failures down from 52 to 10! I hereby declare harfbuzz-ng supporting Indic! Thanks for your work Behdad! I checked out some Devanagari and Kannada samples and all was fine (I don't really know the scripts, but rendering looks exactly like Pango with old HarfBuzz). By the way, when do you think will HarfBuzz be ready to ship as a standalone library in distributions? I'm working on the subtitle rendering library libass and extended it to use HarfBuzz-ng for shaping (this is a GSoC project). I definitely want to avoid including a HB copy in my repository. At the moment the API and its semantics still seem to be rather unstable, is this going to change any soon? Grigori ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] harfbuzz-ng: Branch 'master' - 3 commits
On 07/21/2011 06:01 PM, Behdad Esfahbod wrote: commit aa7264123a088936f2043b45d4d41ca7413fabe5 Author: Behdad Esfahbod beh...@behdad.org Date: Thu Jul 21 11:34:59 2011 -0400 Only form clusters if we are reversing This produces more accurate cluster mappings. Cluster mappings are minimal now. Combining marks get their own cluster value most of the time. Is this really desirable?! I need to handle logical characters and this was easily possible with the old mapping that put glyph and associated mark into a single cluster. This change pretty much completely breaks the way I layout text at the moment... Best regards, Grigori ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Arabic and diacritics: problems with Arial and Arial Unicode
On 07/12/2011 12:14 AM, Behdad Esfahbod wrote:
It's a bug in HarfBuzz. Jonathan has fixed that in Mozilla, but I haven't
adopted the fix upstream yet. It's a muddy area, there are many differently
buggy fonts, and we need to work around them all. I'll take a look tonight.
Here's the current version of the hack from Mozilla, adapted to work
with mainline HarfBuzz-ng, in case anyone is interested. They still use
an older version of HarfBuzz for some reason.
This might be hacky but it works well for me. Fixes Arial, Arial Unicode
MS and Times New Roman, but doesn't break other fonts like DejaVu Sans
Mono (this was reported on Mozilla Bugzilla, IIRC).
Best regards,
Grigori
From ad9eb27f801af59c432375ca79464d8fd66f9408 Mon Sep 17 00:00:00 2001
From: Grigori Goronzy greg@blackbox
Date: Tue, 12 Jul 2011 13:14:38 +0200
Subject: [PATCH] HACK: use zero advance for marks/diacritics
---
src/hb-ot-layout.cc | 21 -
src/hb-ot-layout.h |2 +-
src/hb-ot-shape.cc | 21 +++--
3 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/src/hb-ot-layout.cc b/src/hb-ot-layout.cc
index a49f339..9520255 100644
--- a/src/hb-ot-layout.cc
+++ b/src/hb-ot-layout.cc
@@ -35,6 +35,7 @@
#include hb-ot-layout-gpos-private.hh
#include hb-ot-head-private.hh
#include hb-ot-maxp-private.hh
+#include hb-ot-shape-private.hh
#include stdlib.h
@@ -489,8 +490,26 @@ hb_ot_layout_position_lookup (hb_font_t*font,
}
void
-hb_ot_layout_position_finish (hb_buffer_t *buffer)
+hb_ot_layout_position_finish (hb_face_t *face, hb_buffer_t *buffer)
{
+ /* force diacritics to have zero width */
+ unsigned int count = buffer-len;
+ if (hb_ot_layout_has_glyph_classes (face)) {
+const GDEF gdef = _get_gdef (face);
+for (unsigned int i = 1; i count; i++) {
+ if (gdef.get_glyph_class (buffer-info[i].codepoint) == GDEF::MarkGlyph) {
+buffer-pos[i].x_advance = 0;
+ }
+}
+ } else {
+/* no GDEF classes available, so use General Category as a fallback */
+for (unsigned int i = 1; i count; i++) {
+ if (buffer-info[i].general_category() == HB_UNICODE_GENERAL_CATEGORY_NON_SPACING_MARK) {
+buffer-pos[i].x_advance = 0;
+ }
+}
+ }
+
GPOS::position_finish (buffer);
}
diff --git a/src/hb-ot-layout.h b/src/hb-ot-layout.h
index 6320437..9666ba6 100644
--- a/src/hb-ot-layout.h
+++ b/src/hb-ot-layout.h
@@ -198,7 +198,7 @@ hb_ot_layout_position_lookup (hb_font_t*font,
/* Should be called after all the position_lookup's are done */
void
-hb_ot_layout_position_finish (hb_buffer_t *buffer);
+hb_ot_layout_position_finish (hb_face_t *face, hb_buffer_t *buffer);
HB_END_DECLS
diff --git a/src/hb-ot-shape.cc b/src/hb-ot-shape.cc
index 8378e81..bce119e 100644
--- a/src/hb-ot-shape.cc
+++ b/src/hb-ot-shape.cc
@@ -170,7 +170,7 @@ hb_ot_position_complex (hb_ot_shape_context_t *c)
c-buffer-pos[i].y_offset);
}
- hb_ot_layout_position_finish (c-buffer);
+ hb_ot_layout_position_finish (c-face, c-buffer);
c-applied_position_complex = TRUE;
return;
@@ -323,7 +323,24 @@ hb_position_default (hb_ot_shape_context_t *c)
static void
hb_position_complex_fallback (hb_ot_shape_context_t *c HB_UNUSED)
{
- /* TODO Mark pos */
+ unsigned int count = c-buffer-len;
+ if (c-buffer-props.direction == HB_DIRECTION_RTL) {
+for (unsigned int i = 1; i count; i++) {
+ unsigned int gen_cat = c-buffer-info[i].general_category();
+ if ((1gen_cat) ((1HB_UNICODE_GENERAL_CATEGORY_NON_SPACING_MARK)|(1HB_UNICODE_GENERAL_CATEGORY_ENCLOSING_MARK)|(1HB_UNICODE_GENERAL_CATEGORY_FORMAT))) {
+c-buffer-pos[i].x_advance = 0;
+ }
+}
+ } else {
+for (unsigned int i = 1; i count; i++) {
+ unsigned int gen_cat = c-buffer-info[i].general_category();
+ if ((1gen_cat) ((1HB_UNICODE_GENERAL_CATEGORY_NON_SPACING_MARK)|(1HB_UNICODE_GENERAL_CATEGORY_ENCLOSING_MARK)|(1HB_UNICODE_GENERAL_CATEGORY_FORMAT))) {
+hb_glyph_position_t pos = c-buffer-pos[i];
+pos.x_offset = -pos.x_advance;
+pos.x_advance = 0;
+ }
+}
+ }
}
static void
--
1.7.2.3
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] Arabic and diacritics: problems with Arial and Arial Unicode
Hi, I'm having some odd issues with Arial and Arial Unicode. When I use these fonts to render Arabic text with diacritics, there are gaps inside the words. The diacritics have non-zero advance, this seems to cause it. Are these fonts just buggy or am I doing something wrong? There are no such problems with other fonts, such as DejaVu Sans. What is the correct way to render all glyphs that belong to a certain cluster? I'm a bit at loss at the moment. Best regards, Grigori ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] GSUB for vertical layouts (CJK)
On 05/31/2011 03:08 PM, Grigori Goronzy wrote:
Opened font file /home/greg/.fonts/meiryo.ttc: 9533888 bytes long
TrueType Collection of OpenType fonts
0 font(s) found in file
I looked around a bit in the parser for TTC headers and there was a
stupid bug in it. ;) Fix attached.
Meiryo and Mincho work just fine now!
Best regards,
Grigori
From 58d0ddbac47b8dbc6c483608cb1dd3c17565b96c Mon Sep 17 00:00:00 2001
From: Grigori Goronzy greg@blackbox
Date: Tue, 31 May 2011 15:22:33 +0200
Subject: [PATCH] Fix TTC parsing
---
src/hb-open-file-private.hh |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/hb-open-file-private.hh b/src/hb-open-file-private.hh
index b65e83f..32b5a53 100644
--- a/src/hb-open-file-private.hh
+++ b/src/hb-open-file-private.hh
@@ -152,7 +152,7 @@ struct TTCHeader
inline unsigned int get_face_count (void) const
{
-switch (u.header.version) {
+switch (u.header.version 16) {
case 2: /* version 2 is compatible with version 1 */
case 1: return u.version1.get_face_count ();
default:return 0;
@@ -160,7 +160,7 @@ struct TTCHeader
}
inline const OpenTypeFontFace get_face (unsigned int i) const
{
-switch (u.header.version) {
+switch (u.header.version 16) {
case 2: /* version 2 is compatible with version 1 */
case 1: return u.version1.get_face (i);
default:return Null(OpenTypeFontFace);
--
1.7.2.3
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
