Re: [HarfBuzz] Font fallback strategies
On 12-10-22 05:42 PM, Grigori Goronzy wrote: Hi, I'm currently investigating how to do better font fallbacks for my project. At the moment, fallback selection is nondeterministic (for a given codepoint) and doesn't make much effort to select a single font per same-script text run. You need to tell us more about the context (system, etc) I think. You can use Fontconfig. Note that fallback order should be per-language, not per-script. Are there any general recommendations for fallback selection and splitting runs? The OpenType specification doesn't say anything about this (or I didn't look hard enough). CSS recommends trying to choose fallback font for entire grapheme clusters at a time, but I don't know any implementation that does that. Moreover, I wonder how to accurately determine what codepoints are supported by a given font. Is it safe to assume a codepoint or a sequences of codepoints as supported under all possible GSUB substitutions if they appear in the cmap? Yes, cmap is what everyone uses essentially. Now, given the normalization support in HarfBuzz, cmap would not be sufficient, but we have not added API to HarfBuzz yet to help clients do better font selection. behdad 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 12-10-22 03:40 AM, Samiullah Khawaja wrote: What are the semantics of the x_offset and y_offset values. 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) They have nothing to do with bearings. Think about it this way: normally, with simple Latin text set, both x_offset and y_offset are zero. When they are nonzero, they shift that particular glyph (and just that one. These offsets don't accumulate.) in the x/y direction. Are these values 16.16 fractional values or 26.6 fractional values? Depends on what you set in hb_font_set_scale(). Whatever value you set there will represent on em-square. Up to you to interpret what the number means. behdad Thanks, Sami ___ 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] x_offset and y_offset
On 12-10-25 12:47 PM, Behdad Esfahbod wrote: Are these values 16.16 fractional values or 26.6 fractional values? Depends on what you set in hb_font_set_scale(). Whatever value you set there will represent on em-square. Up to you to interpret what the number means. Though, for hb-ft, they mean 26.6 indeed. behdad ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] x_offset and y_offset
Figured it out, Previously i was confused with the x_offset and y_offset always zero. But then found that it is something that is added after the bearings (Had to get this info by debugging the harfbuzz code all the way down to the position formats and x_offset and y_offset calculation). My text rendering is good now. But for some fonts the NSM are not detected and their advance is not zero. For example the Traditional Arabic font in Windows. Another thing that I have a font that has GDEF table missing (I found this after debugging through harfbuzz code), due to this harfbuzz does not do substition, any hints? On Fri, Oct 26, 2012 at 12:47 AM, Behdad Esfahbod beh...@behdad.org wrote: On 12-10-25 12:47 PM, Behdad Esfahbod wrote: Are these values 16.16 fractional values or 26.6 fractional values? Depends on what you set in hb_font_set_scale(). Whatever value you set there will represent on em-square. Up to you to interpret what the number means. Though, for hb-ft, they mean 26.6 indeed. behdad -- Samiullah Khawaja Software Engineer email: sami.khaw...@gmail.com voice: +(92) 0321-4184324 ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] x_offset and y_offset
Do you have Unicode callbacks set up properly? What version are you using? On 12-10-25 02:44 PM, Samiullah Khawaja wrote: Figured it out, Previously i was confused with the x_offset and y_offset always zero. But then found that it is something that is added after the bearings (Had to get this info by debugging the harfbuzz code all the way down to the position formats and x_offset and y_offset calculation). My text rendering is good now. But for some fonts the NSM are not detected and their advance is not zero. For example the Traditional Arabic font in Windows. Another thing that I have a font that has GDEF table missing (I found this after debugging through harfbuzz code), due to this harfbuzz does not do substition, any hints? On Fri, Oct 26, 2012 at 12:47 AM, Behdad Esfahbod beh...@behdad.org mailto:beh...@behdad.org wrote: On 12-10-25 12:47 PM, Behdad Esfahbod wrote: Are these values 16.16 fractional values or 26.6 fractional values? Depends on what you set in hb_font_set_scale(). Whatever value you set there will represent on em-square. Up to you to interpret what the number means. Though, for hb-ft, they mean 26.6 indeed. behdad -- Samiullah Khawaja Software Engineer email: sami.khaw...@gmail.com mailto:sami.khaw...@gmail.com voice: +(92) 0321-4184324 ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] x_offset and y_offset
Yes the unicode callback are all set and good. Not sure about the version. Its the one you released in early september. I think 10 september. On Fri, Oct 26, 2012 at 2:57 AM, Behdad Esfahbod beh...@behdad.org wrote: Do you have Unicode callbacks set up properly? What version are you using? On 12-10-25 02:44 PM, Samiullah Khawaja wrote: Figured it out, Previously i was confused with the x_offset and y_offset always zero. But then found that it is something that is added after the bearings (Had to get this info by debugging the harfbuzz code all the way down to the position formats and x_offset and y_offset calculation). My text rendering is good now. But for some fonts the NSM are not detected and their advance is not zero. For example the Traditional Arabic font in Windows. Another thing that I have a font that has GDEF table missing (I found this after debugging through harfbuzz code), due to this harfbuzz does not do substition, any hints? On Fri, Oct 26, 2012 at 12:47 AM, Behdad Esfahbod beh...@behdad.org mailto:beh...@behdad.org wrote: On 12-10-25 12:47 PM, Behdad Esfahbod wrote: Are these values 16.16 fractional values or 26.6 fractional values? Depends on what you set in hb_font_set_scale(). Whatever value you set there will represent on em-square. Up to you to interpret what the number means. Though, for hb-ft, they mean 26.6 indeed. behdad -- Samiullah Khawaja Software Engineer email: sami.khaw...@gmail.com mailto:sami.khaw...@gmail.com voice: +(92) 0321-4184324 -- Samiullah Khawaja Software Engineer email: sami.khaw...@gmail.com voice: +(92) 0321-4184324 ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] x_offset and y_offset
On 12-10-25 03:36 PM, Samiullah Khawaja wrote: Yes the unicode callback are all set and good. Not sure about the version. Its the one you released in early september. I think 10 september. Then I need to see the font and text to be of any help. Do try with 0.9.5 that I released a few days ago if you can. behdad On Fri, Oct 26, 2012 at 2:57 AM, Behdad Esfahbod beh...@behdad.org mailto:beh...@behdad.org wrote: Do you have Unicode callbacks set up properly? What version are you using? On 12-10-25 02:44 PM, Samiullah Khawaja wrote: Figured it out, Previously i was confused with the x_offset and y_offset always zero. But then found that it is something that is added after the bearings (Had to get this info by debugging the harfbuzz code all the way down to the position formats and x_offset and y_offset calculation). My text rendering is good now. But for some fonts the NSM are not detected and their advance is not zero. For example the Traditional Arabic font in Windows. Another thing that I have a font that has GDEF table missing (I found this after debugging through harfbuzz code), due to this harfbuzz does not do substition, any hints? On Fri, Oct 26, 2012 at 12:47 AM, Behdad Esfahbod beh...@behdad.org mailto:beh...@behdad.org mailto:beh...@behdad.org mailto:beh...@behdad.org wrote: On 12-10-25 12:47 PM, Behdad Esfahbod wrote: Are these values 16.16 fractional values or 26.6 fractional values? Depends on what you set in hb_font_set_scale(). Whatever value you set there will represent on em-square. Up to you to interpret what the number means. Though, for hb-ft, they mean 26.6 indeed. behdad -- Samiullah Khawaja Software Engineer email: sami.khaw...@gmail.com mailto:sami.khaw...@gmail.com mailto:sami.khaw...@gmail.com mailto:sami.khaw...@gmail.com voice: +(92) 0321-4184324 tel:%2B%2892%29%200321-4184324 -- Samiullah Khawaja Software Engineer email: sami.khaw...@gmail.com mailto:sami.khaw...@gmail.com voice: +(92) 0321-4184324 ___ 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
[HarfBuzz] harfbuzz: Branch 'master' - 2 commits
TODO | 14 +--
src/hb-fallback-shape.cc |2 -
src/hb-ot-shape-private.hh |4 +-
src/hb-ot-shape.cc |2 -
src/hb-unicode-private.hh | 90 +
5 files changed, 72 insertions(+), 40 deletions(-)
New commits:
commit cf3afd8979b1db76d437f428cbd51cb363e0d18e
Author: Behdad Esfahbod beh...@behdad.org
Date: Thu Oct 25 16:32:54 2012 -0700
Rename and revamp is_zero_width() to be is_default_ignorable()
That's really the logic desired. Except that MONGOLIAN VOWEL SEPARATOR
is not default_ignorable but it really should be. Reported to Unicode.
Based on suggestion from Konstantin Ritt.
diff --git a/src/hb-fallback-shape.cc b/src/hb-fallback-shape.cc
index d7bde09..3f9024f 100644
--- a/src/hb-fallback-shape.cc
+++ b/src/hb-fallback-shape.cc
@@ -105,7 +105,7 @@ _hb_fallback_shape (hb_shape_plan_t*shape_plan,
for (unsigned int i = 0; i count; i++)
{
-if (buffer-unicode-is_zero_width (buffer-info[i].codepoint)) {
+if (buffer-unicode-is_default_ignorable (buffer-info[i].codepoint)) {
buffer-info[i].codepoint = space;
buffer-pos[i].x_advance = 0;
buffer-pos[i].y_advance = 0;
diff --git a/src/hb-ot-shape-private.hh b/src/hb-ot-shape-private.hh
index c4c368d..ae01215 100644
--- a/src/hb-ot-shape-private.hh
+++ b/src/hb-ot-shape-private.hh
@@ -85,7 +85,7 @@ inline void
_hb_glyph_info_set_unicode_props (hb_glyph_info_t *info, hb_unicode_funcs_t
*unicode)
{
info-unicode_props0() = ((unsigned int) unicode-general_category
(info-codepoint)) |
- (unicode-is_zero_width (info-codepoint) ? 0x80 :
0);
+ (unicode-is_default_ignorable (info-codepoint) ?
0x80 : 0);
info-unicode_props1() = unicode-modified_combining_class (info-codepoint);
}
@@ -108,7 +108,7 @@ _hb_glyph_info_get_modified_combining_class (const
hb_glyph_info_t *info)
}
inline hb_bool_t
-_hb_glyph_info_is_zero_width (const hb_glyph_info_t *info)
+_hb_glyph_info_is_default_ignorable (const hb_glyph_info_t *info)
{
return !!(info-unicode_props0() 0x80);
}
diff --git a/src/hb-ot-shape.cc b/src/hb-ot-shape.cc
index 313766a..9a6260a 100644
--- a/src/hb-ot-shape.cc
+++ b/src/hb-ot-shape.cc
@@ -519,7 +519,7 @@ hb_ot_hide_zerowidth (hb_ot_shape_context_t *c)
unsigned int count = c-buffer-len;
for (unsigned int i = 0; i count; i++)
if (unlikely (!is_a_ligature (c-buffer-info[i])
- _hb_glyph_info_is_zero_width (c-buffer-info[i])))
+ _hb_glyph_info_is_default_ignorable (c-buffer-info[i])))
{
if (!space) {
/* We assume that the space glyph is not gid0. */
diff --git a/src/hb-unicode-private.hh b/src/hb-unicode-private.hh
index 9f24a9f..7be4b04 100644
--- a/src/hb-unicode-private.hh
+++ b/src/hb-unicode-private.hh
@@ -119,47 +119,73 @@ HB_UNICODE_FUNCS_IMPLEMENT_CALLBACKS_SIMPLE
0xE0100, 0xE01EF)); /*
VARIATION SELECTOR-17..256 */
}
- /* Zero-Width invisible characters:
+ /* Default_Ignorable codepoints:
*
- * 00AD SOFT HYPHEN
- * 034F COMBINING GRAPHEME JOINER
+ * Note that as of Oct 2012 (Unicode 6.2), U+180E MONGOLIAN VOWEL SEPARATOR
+ * is NOT Default_Ignorable, but it really behaves in a way that it should
+ * be. That has been reported to the Unicode Technical Committee for
+ * consideration. As such, we include it here, since Uniscribe removes it.
*
- * 180E MONGOLIAN VOWEL SEPARATOR
+ * Gathered from:
+ *
http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[:DI:]abb=onucd=onesc=on
*
- * 200B ZERO WIDTH SPACE
- * 200C ZERO WIDTH NON-JOINER
- * 200D ZERO WIDTH JOINER
- * 200E LEFT-TO-RIGHT MARK
- * 200F RIGHT-TO-LEFT MARK
+ * Last updated to the page with the following versions:
+ * Version 3.6; ICU version: 50.0.1.0; Unicode version: 6.1.0.0
*
- * 2028 LINE SEPARATOR
+ * 4,167 Code Points
*
- * 202A LEFT-TO-RIGHT EMBEDDING
- * 202B RIGHT-TO-LEFT EMBEDDING
- * 202C POP DIRECTIONAL FORMATTING
- * 202D LEFT-TO-RIGHT OVERRIDE
- * 202E RIGHT-TO-LEFT OVERRIDE
+ *
[\u00AD\u034F\u115F\u1160\u17B4\u17B5\u180B-\u180D\u200B-\u200F\u202A-\u202E\u2060-\u206F\u3164\uFE00-\uFE0F\uFEFF\uFFA0\uFFF0-\uFFF8\U0001D173-\U0001D17A\U000E-\U000E0FFF]
*
- * 2060 WORD JOINER
- * 2061 FUNCTION APPLICATION
- * 2062 INVISIBLE TIMES
- * 2063 INVISIBLE SEPARATOR
- *
- * FEFF ZERO WIDTH NO-BREAK SPACE
+ * 00AD ;SOFT HYPHEN
+ * 034F ;COMBINING GRAPHEME JOINER
+ * 115F ;HANGUL CHOSEONG FILLER
+ * 1160 ;HANGUL JUNGSEONG FILLER
+ * 17B4 ;KHMER VOWEL INHERENT AQ
+ * 17B5 ;KHMER VOWEL INHERENT AA
+ * 180B..180D ;MONGOLIAN FREE VARIATION SELECTOR THREE
+ * 200B..200F ;RIGHT-TO-LEFT MARK
+ * 202A..202E ;RIGHT-TO-LEFT OVERRIDE
+ * 2060..206F ;NOMINAL DIGIT SHAPES
+ * 3164 ;HANGUL FILLER
+ * FE00..FE0F
Re: [HarfBuzz] x_offset and y_offset
Ok I will try it. And any comments about the non-zero advance for Non spacing markers with the Traditional Arabic Font that comes with Windows? I think I also noticed the same behavior in nafees nastaleeq font developed at CRULP for URDU. On Fri, Oct 26, 2012 at 4:21 AM, Behdad Esfahbod beh...@behdad.org wrote: On 12-10-25 03:36 PM, Samiullah Khawaja wrote: Yes the unicode callback are all set and good. Not sure about the version. Its the one you released in early september. I think 10 september. Then I need to see the font and text to be of any help. Do try with 0.9.5 that I released a few days ago if you can. behdad On Fri, Oct 26, 2012 at 2:57 AM, Behdad Esfahbod beh...@behdad.org mailto:beh...@behdad.org wrote: Do you have Unicode callbacks set up properly? What version are you using? On 12-10-25 02:44 PM, Samiullah Khawaja wrote: Figured it out, Previously i was confused with the x_offset and y_offset always zero. But then found that it is something that is added after the bearings (Had to get this info by debugging the harfbuzz code all the way down to the position formats and x_offset and y_offset calculation). My text rendering is good now. But for some fonts the NSM are not detected and their advance is not zero. For example the Traditional Arabic font in Windows. Another thing that I have a font that has GDEF table missing (I found this after debugging through harfbuzz code), due to this harfbuzz does not do substition, any hints? On Fri, Oct 26, 2012 at 12:47 AM, Behdad Esfahbod beh...@behdad.org mailto:beh...@behdad.org mailto:beh...@behdad.org mailto:beh...@behdad.org wrote: On 12-10-25 12:47 PM, Behdad Esfahbod wrote: Are these values 16.16 fractional values or 26.6 fractional values? Depends on what you set in hb_font_set_scale(). Whatever value you set there will represent on em-square. Up to you to interpret what the number means. Though, for hb-ft, they mean 26.6 indeed. behdad -- Samiullah Khawaja Software Engineer email: sami.khaw...@gmail.com mailto:sami.khaw...@gmail.com mailto:sami.khaw...@gmail.com mailto:sami.khaw...@gmail.com voice: +(92) 0321-4184324 tel:%2B%2892%29%200321-4184324 -- Samiullah Khawaja Software Engineer email: sami.khaw...@gmail.com mailto:sami.khaw...@gmail.com voice: +(92) 0321-4184324 -- Samiullah Khawaja Software Engineer email: sami.khaw...@gmail.com voice: +(92) 0321-4184324 ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] x_offset and y_offset
Same thing. If Unicode callbacks are set up correctly, it should all work. On 12-10-25 04:52 PM, Samiullah Khawaja wrote: Ok I will try it. And any comments about the non-zero advance for Non spacing markers with the Traditional Arabic Font that comes with Windows? I think I also noticed the same behavior in nafees nastaleeq font developed at CRULP for URDU. On Fri, Oct 26, 2012 at 4:21 AM, Behdad Esfahbod beh...@behdad.org mailto:beh...@behdad.org wrote: On 12-10-25 03:36 PM, Samiullah Khawaja wrote: Yes the unicode callback are all set and good. Not sure about the version. Its the one you released in early september. I think 10 september. Then I need to see the font and text to be of any help. Do try with 0.9.5 that I released a few days ago if you can. behdad On Fri, Oct 26, 2012 at 2:57 AM, Behdad Esfahbod beh...@behdad.org mailto:beh...@behdad.org mailto:beh...@behdad.org mailto:beh...@behdad.org wrote: Do you have Unicode callbacks set up properly? What version are you using? On 12-10-25 02:44 PM, Samiullah Khawaja wrote: Figured it out, Previously i was confused with the x_offset and y_offset always zero. But then found that it is something that is added after the bearings (Had to get this info by debugging the harfbuzz code all the way down to the position formats and x_offset and y_offset calculation). My text rendering is good now. But for some fonts the NSM are not detected and their advance is not zero. For example the Traditional Arabic font in Windows. Another thing that I have a font that has GDEF table missing (I found this after debugging through harfbuzz code), due to this harfbuzz does not do substition, any hints? On Fri, Oct 26, 2012 at 12:47 AM, Behdad Esfahbod beh...@behdad.org mailto:beh...@behdad.org mailto:beh...@behdad.org mailto:beh...@behdad.org mailto:beh...@behdad.org mailto:beh...@behdad.org mailto:beh...@behdad.org mailto:beh...@behdad.org wrote: On 12-10-25 12:47 PM, Behdad Esfahbod wrote: Are these values 16.16 fractional values or 26.6 fractional values? Depends on what you set in hb_font_set_scale(). Whatever value you set there will represent on em-square. Up to you to interpret what the number means. Though, for hb-ft, they mean 26.6 indeed. behdad -- Samiullah Khawaja Software Engineer email: sami.khaw...@gmail.com mailto:sami.khaw...@gmail.com mailto:sami.khaw...@gmail.com mailto:sami.khaw...@gmail.com mailto:sami.khaw...@gmail.com mailto:sami.khaw...@gmail.com mailto:sami.khaw...@gmail.com mailto:sami.khaw...@gmail.com voice: +(92) 0321-4184324 tel:%2B%2892%29%200321-4184324 tel:%2B%2892%29%200321-4184324 -- Samiullah Khawaja Software Engineer email: sami.khaw...@gmail.com mailto:sami.khaw...@gmail.com mailto:sami.khaw...@gmail.com mailto:sami.khaw...@gmail.com voice: +(92) 0321-4184324 tel:%2B%2892%29%200321-4184324 -- Samiullah Khawaja Software Engineer email: sami.khaw...@gmail.com mailto:sami.khaw...@gmail.com voice: +(92) 0321-4184324 ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Font fallback strategies
Ok, looks like what you want is very close to what Pango does... In short: - Choose a language: Given the script, choose a language that makes sense for the script. Pango does this using a few env vars, and tables. See pango-language.c. - Given the language, get a fontset from FcFontSort() and cache it. Use the charsets from the pattern for fast cmap checking. - You can cache many many other things to make things fast. Indeed, pangofc does a lot of that. Check pangofc-fontmap.c. behdad On 12-10-25 04:22 PM, Grigori Goronzy wrote: 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
