[HarfBuzz] tool for 'get all alternates'?
Does anyone know of some command line tool that shows some useful info similar to Adobe's CS Glyph window where you can "show alternates for selection." Using the otfinfo tool I know things like how many stylistic sets there are in font, but sometimes there aren't any (or only a few) but there are many alternates inside the font. If I could somehow read an entire font to "index" the alternates per character that would be very handy. If you have any ideas I'd like to hear em ;) Best, Rolf ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] GObject Introspection Change & HarfBuzz version
On 08/10/2012 04:08 PM, Khaled Hosny wrote: > On Fri, Aug 10, 2012 at 03:49:12PM -0400, Behdad Esfahbod wrote: >> To be honest, Qt / Old HarfBuzz has such serious problems with RTL text and >> Arabic in general that Kashida should be no one's top issue considering a >> switch. > > I agree, and it is the main reason why I never use Qt applications > myself (or why I love GTK). I don't care about such simple minded > kashida justification myself (Word and OpenOffice have it and I’ve to > play tricks with them to never apply it because it just ruins my fonts), > I just want to see Qt switching to the new HarfBuzz so people stop > telling me how my fonts are broken there :) Jiang Jiang started a patch last year. Hopefully someone will pick it up from there? >> But we will eventually get to justification in HarfBuzz too... Eventually. >> In >> the mean time, feel free to play with adding JSTF tables to your fonts, if >> you >> figure out how it works or find an implementing client. > > I requested JSTF support from George Williams a while ago and he > (as usual) added to FontForge, but the lack of engine support killed all > the motivation to experiment with it. I should start playing with it > later this year (I have been collecting ideas for a while). Right. Give me a sample font and I'll see what I can do. Reading the spec itself, it's extremely inefficient and a pain to implement... But I can try. behdad > Regards, > Khaled > ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] GObject Introspection Change & HarfBuzz version
On Fri, Aug 10, 2012 at 03:49:12PM -0400, Behdad Esfahbod wrote: > On 08/10/2012 03:44 PM, Khaled Hosny wrote: > > On Fri, Aug 10, 2012 at 02:53:59PM -0400, Behdad Esfahbod wrote: > >> As of this week, I'm glad to say that I ran out of essential features > >> to implement for a 1.0 release, > > > > What about poor man's kashida justification à la Qt/HarfBuzz? I think it > > is something that would block Qt's adoption of the new HarfBuzz. > > Humm, interesting. New HarfBuzz doesn't have the line-breaking stuff that old > HarfBuzz did. Same re Kashida classification. AFAIK there was no actual > justification in old HarfBuzz, just simple Kashida classification which is > font independent and can remain in Qt like other Unicode segmentation > algorithms should. > > To be honest, Qt / Old HarfBuzz has such serious problems with RTL text and > Arabic in general that Kashida should be no one's top issue considering a > switch. I agree, and it is the main reason why I never use Qt applications myself (or why I love GTK). I don't care about such simple minded kashida justification myself (Word and OpenOffice have it and I’ve to play tricks with them to never apply it because it just ruins my fonts), I just want to see Qt switching to the new HarfBuzz so people stop telling me how my fonts are broken there :) > > But we will eventually get to justification in HarfBuzz too... Eventually. In > the mean time, feel free to play with adding JSTF tables to your fonts, if you > figure out how it works or find an implementing client. I requested JSTF support from George Williams a while ago and he (as usual) added to FontForge, but the lack of engine support killed all the motivation to experiment with it. I should start playing with it later this year (I have been collecting ideas for a while). Regards, Khaled ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] GObject Introspection Change & HarfBuzz version
On 08/10/2012 03:44 PM, Khaled Hosny wrote: > On Fri, Aug 10, 2012 at 02:53:59PM -0400, Behdad Esfahbod wrote: >> As of this week, I'm glad to say that I ran out of essential features >> to implement for a 1.0 release, > > What about poor man's kashida justification à la Qt/HarfBuzz? I think it > is something that would block Qt's adoption of the new HarfBuzz. Humm, interesting. New HarfBuzz doesn't have the line-breaking stuff that old HarfBuzz did. Same re Kashida classification. AFAIK there was no actual justification in old HarfBuzz, just simple Kashida classification which is font independent and can remain in Qt like other Unicode segmentation algorithms should. To be honest, Qt / Old HarfBuzz has such serious problems with RTL text and Arabic in general that Kashida should be no one's top issue considering a switch. But we will eventually get to justification in HarfBuzz too... Eventually. In the mean time, feel free to play with adding JSTF tables to your fonts, if you figure out how it works or find an implementing client. Cheers, behdad ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] GObject Introspection Change & HarfBuzz version
On Fri, Aug 10, 2012 at 02:53:59PM -0400, Behdad Esfahbod wrote: > As of this week, I'm glad to say that I ran out of essential features > to implement for a 1.0 release, What about poor man's kashida justification à la Qt/HarfBuzz? I think it is something that would block Qt's adoption of the new HarfBuzz. Regards, Khaled ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz-0.9.2 now available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, So, after (finally!) implementing synthetic GDEF and fallback mark positioning, I found myself running out of major features to implement this week. I can finally claim that new HarfBuzz is in par with or better than both Pango and old.HarfBuzz / Qt. The main outstanding issue that I know of is Indic support with Free fonts, which I hope to improve in the coming weeks. Testing and reports will be key to what I will end up working on. With features complete, and performance looking good, I'm shifting gears to release mode, starting with a 0.9.2 release today, and working my way towards a 1.0 release around the end of the month or in early September. This may be a good time for distributions to start putting a harfbuzz package together. A proper build system will be coming soon. I put a short checklist together to track 1.0 progress: http://goo.gl/4xnyw Feel free to comment (on the doc or on the list). In the mean time, enjoy the 0.9.2 release! http://www.freedesktop.org/software/harfbuzz/release/ As always, I like to specially thank Jonathan Kew, as well as everyone who helped with testing. Cheers, Behdad Esfahbod August 10, 2012 Overview of changes leading to 0.9.2 Friday, Aug 10, 2011 - - Over a thousand commits! This is the first major release of HarfBuzz. - - HarfBuzz is feature-complete now! It should be in par, or better, than both Pango's shapers and old HarfBuzz / Qt shapers. - - New Indic shaper, supporting main Indic scripts, Sinhala, and Khmer. - - Improved Arabic shaper, with fallback Arabic shaping, supporting Arabic, Sinhala, N'ko, Mongolian, and Mandaic. - - New Thai / Lao shaper. - - Tibetan / Hangul support in the generic shaper. - - Synthetic GDEF support for fonts without a GDEF table. - - Fallback mark positioning for fonts without a GPOS table. - - Unicode normalization shaping heuristic during glyph mapping. - - New experimental Graphite2 backend. - - New Uniscribe backend (primarily for testing). - - New CoreText backend (primarily for testing). - - Major optimization and speedup. - - Test suites and testing infrastructure (work in progress). - - Greatly improved hb-view cmdline tool. - - hb-shape cmdline tool. - - Unicode 6.1 support. Summary of API changes: o Changed API: - Users are expected to only include main header files now (ie. hb.h, hb-glib.h, hb-ft.h, ...) - All struct tag names had their initial underscore removed. Ie. "struct _hb_buffer_t" is "struct hb_buffer_t" now. - All set_user_data() functions now take a "replace" boolean parameter. - hb_buffer_create() takes zero arguments now. Use hb_buffer_pre_allocate() to pre-allocate. - hb_buffer_add_utf*() now accept -1 for length parameteres, meaning "nul-terminated". - hb_direction_t enum values changed. - All *_from_string() APIs now take a length parameter to allow for non-nul-terminated strings. A -1 length means "nul-terminated". - Typedef for hb_language_t changed. - hb_get_table_func_t renamed to hb_reference_table_func_t. - hb_ot_layout_table_choose_script() - Various renames in hb-unicode.h. o New API: - hb_buffer_guess_properties() Automatically called by hb_shape(). - hb_buffer_normalize_glyphs() - hb_tag_from_string() - hb-coretext.h - hb-uniscribe.h - hb_face_reference_blob() - hb_face_[sg]et_index() - hb_face_set_upem() - hb_font_get_glyph_name_func_t hb_font_get_glyph_from_name_func_t hb_font_funcs_set_glyph_name_func() hb_font_funcs_set_glyph_from_name_func() hb_font_get_glyph_name() hb_font_get_glyph_from_name() hb_font_glyph_to_string() hb_font_glyph_from_string() - hb_font_set_funcs_data() - hb_ft_font_set_funcs() - hb_ft_font_get_face() - hb-gobject.h (work in progress) - hb_ot_shape_glyphs_closure() hb_ot_layout_substitute_closure_lookup() - hb-set.h - hb_shape_full() - hb_unicode_combining_class_t - hb_unicode_compose_func_t hb_unicode_decompose_func_t hb_unicode_decompose_compatibility_func_t hb_unicode_funcs_set_compose_func() hb_unicode_funcs_set_decompose_func() hb_unicode_funcs_set_decompose_compatibility_func() hb_unicode_compose() hb_unicode_decompose() hb_unicode_decompose_compatibility() o Removed API: - hb_ft_get_font_funcs() - hb_ot_layout_substitute_start() hb_ot_layout_substitute_lookup() hb_ot_layout_substitute_finish() hb_ot_layout_position_start() hb_ot_layout_position_lookup() hb_ot_layout_position_finish() -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAlW/YACgkQn+4E5dNTERXQPwCePZGJN/mV/eNcgg0+SfOq2kFQ 0nQAoLYybPR6aSSsISywdHgFstxGm0w8 =8/5G -END PGP SIGNATURE- ___ HarfBuzz mailing list HarfBuzz@lists.fr
[HarfBuzz] harfbuzz-ng: Branch 'refs/tags/0.9.1' - 0 commits
Rebased ref, commits from common ancestor: ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] GObject Introspection Change & HarfBuzz version
Hi Dominik, Sorry for the late response. Comments below. On 07/23/2012 07:11 AM, Dominik Röttsches wrote: > Hi Behdad, > > I am working on incorporating HarfBuzz NG into EFL WebKit, and WebKit GTK as > well, if I have time. Interesting. Have you checked what bashi has been doing? It's under WebKit/Source/WebCore/platform/graphics/harfbuzz/ng. > Maybe you can give me some advise on what version / commit I should be using. > So far, I used the 0.9.0 tarball from here: > http://www.freedesktop.org/software/harfbuzz/release/harfbuzz-20120627.tar.bz2 > > What's the release cycle of harfbuzz, and which hash is a good stable release? Umm. We have not had any releases so far as we've been trying to get functionality done. As of this week, I'm glad to say that I ran out of essential features to implement for a 1.0 release, so my focus for the next few weeks will be getting 1.0 out of the door. I expect a few minor API changes while we get there, but nothing major. In the mean time, I just made a 0.9.2 release and uploaded here: http://www.freedesktop.org/software/harfbuzz/release/ > One more particular request I would have: > After commit 1bc1cb36 > several HarfBuzz type lost their prefix _ (underscore). > Since WebKit copies this typedef and different ports of WebKit use different > versions of HarfBuzz, can we have a bumped minor version for this so that I > could distinguish before and after this particular commit by minor version? > Would that make sense? Is the new release good enough? Sorry, I didn't know Webkit is addressing the types using their struct tags. Cheers, behdad > Thanks & regards, > > Dominik > ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz-ng: Changes to 'refs/tags/0.9.2'
Tag '0.9.2' created by Behdad Esfahbod at 2012-08-10 19:51 -0700 0.9.2 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAlAlWDkACgkQn+4E5dNTERV9cQCghzPJOf4jQY6etq9dmNuCirKX HrwAn2qlpvRsw2gFUFuILEcXMvBzm3+r =BlkV -END PGP SIGNATURE- Changes since 0.9.1: Behdad Esfahbod (1): Bump version to 0.9.2 --- AUTHORS |8 +++ COPYING |9 ++- Makefile.am | 13 ++--- NEWS | 136 +++ THANKS |7 +++ configure.ac |4 - 6 files changed, 165 insertions(+), 12 deletions(-) --- ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz-ng: Branch 'master'
AUTHORS |8 +++ COPYING |9 ++- Makefile.am | 13 ++--- NEWS | 136 +++ THANKS |7 +++ configure.ac |4 - 6 files changed, 165 insertions(+), 12 deletions(-) New commits: commit e297ee4acd6f9d950f8542fc6ad71fd580b69284 Author: Behdad Esfahbod Date: Fri Aug 10 14:49:37 2012 -0400 Bump version to 0.9.2 A *real* release this time, with NEWS, ChangeLog, etc. diff --git a/AUTHORS b/AUTHORS index e69de29..c611d7d 100644 --- a/AUTHORS +++ b/AUTHORS @@ -0,0 +1,8 @@ +Behdad Esfahbod +Simon Hausmann +Martin Hosken +Jonathan Kew +Lars Knoll +Werner Lemberg +Owen Taylor +David Turner diff --git a/COPYING b/COPYING index 4bb77a0..f6748da 100644 --- a/COPYING +++ b/COPYING @@ -1,11 +1,14 @@ HarfBuzz is licensed under the so-called "Old MIT" license. Details follow. -Copyright © 2011 Codethink Limited -Copyright © 2010,2011 Google, Inc. -Copyright © 2006 Behdad Esfahbod +Copyright © 2010,2011,2012 Google, Inc. +Copyright © 2012 Mozilla Foundation +Copyright © 2011 Codethink Limited +Copyright © 2008,2010 Nokia Corporation and/or its subsidiary(-ies) Copyright © 2009 Keith Stribley Copyright © 2009 Martin Hosken and SIL International Copyright © 2007 Chris Wilson +Copyright © 2006 Behdad Esfahbod +Copyright © 2005 David Turner Copyright © 2004,2007,2008,2009,2010 Red Hat, Inc. Copyright © 1998-2004 David Turner and Werner Lemberg diff --git a/Makefile.am b/Makefile.am index 8b69c2d..08f8a93 100644 --- a/Makefile.am +++ b/Makefile.am @@ -34,19 +34,18 @@ MAINTAINERCLEANFILES = \ # ChangeLog generation # CHANGELOG_RANGE = -ChangeLog: $(srcdir)/ChangeLog -$(srcdir)/ChangeLog: - $(AM_V_GEN) if test -d "$(srcdir)/.git"; then \ - (GIT_DIR=$(top_srcdir)/.git ./missing --run \ +ChangeLog: + $(AM_V_GEN) if test -d "$(top_srcdir)/.git"; then \ + (GIT_DIR=$(top_srcdir)/.git $(top_srcdir)/missing --run \ git log $(CHANGELOG_RANGE) --stat) | fmt --split-only > $@.tmp \ - && mv -f $@.tmp $@ \ + && mv -f $@.tmp "$(srcdir)/$@" \ || ($(RM) $@.tmp; \ echo Failed to generate ChangeLog, your ChangeLog may be outdated >&2; \ - (test -f $@ || echo git-log is required to generate this file >> $@)); \ + (test -f $@ || echo git-log is required to generate this file >> "$(srcdir)/$@")); \ else \ test -f $@ || \ (echo A git checkout and git-log is required to generate ChangeLog >&2 && \ - echo A git checkout and git-log is required to generate this file >> $@); \ + echo A git checkout and git-log is required to generate this file >> "$(srcdir)/$@"); \ fi .PHONY: $(srcdir)/ChangeLog diff --git a/NEWS b/NEWS index d31c548..5b0232c 100644 --- a/NEWS +++ b/NEWS @@ -1,3 +1,139 @@ +Overview of changes leading to 0.9.2 +Friday, Aug 10, 2011 + + +- Over a thousand commits! This is the first major release of HarfBuzz. + +- HarfBuzz is feature-complete now! It should be in par, or better, than + both Pango's shapers and old HarfBuzz / Qt shapers. + +- New Indic shaper, supporting main Indic scripts, Sinhala, and Khmer. + +- Improved Arabic shaper, with fallback Arabic shaping, supporting Arabic, + Sinhala, N'ko, Mongolian, and Mandaic. + +- New Thai / Lao shaper. + +- Tibetan / Hangul support in the generic shaper. + +- Synthetic GDEF support for fonts without a GDEF table. + +- Fallback mark positioning for fonts without a GPOS table. + +- Unicode normalization shaping heuristic during glyph mapping. + +- New experimental Graphite2 backend. + +- New Uniscribe backend (primarily for testing). + +- New CoreText backend (primarily for testing). + +- Major optimization and speedup. + +- Test suites and testing infrastructure (work in progress). + +- Greatly improved hb-view cmdline tool. + +- hb-shape cmdline tool. + +- Unicode 6.1 support. + +Summary of API changes: + +o Changed API: + + - Users are expected to only include main header files now (ie. hb.h, +hb-glib.h, hb-ft.h, ...) + + - All struct tag names had their initial underscore removed. +Ie. "struct _hb_buffer_t" is "struct hb_buffer_t" now. + + - All set_user_data() functions now take a "replace" boolean parameter. + + - hb_buffer_create() takes zero arguments now. +Use hb_buffer_pre_allocate() to pre-allocate. + + - hb_buffer_add_utf*() now accept -1 for length parameteres, +meaning "nul-terminated". + + - hb_direction_t enum values changed. + + - All *_from_string() APIs now take a length parameter to allow for +non-nul-terminated strings. A -1 length means "nul-terminated". + + - Typedef for hb_language_t changed. + + - hb_get_table_func_t renamed to hb_reference_table_func_t. + + - hb_ot_layout_table_choose_script() + + - Various renames in hb-unicode.h. + +o New API: + + - hb_buffer_guess_properties() +
[HarfBuzz] harfbuzz-ng: Branch 'master'
configure.ac |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit 6efe1200b97cefe019857b0b5951a4a87deeb02b Author: Behdad Esfahbod Date: Fri Aug 10 13:49:32 2012 -0400 Bump version to 0.9.1 diff --git a/configure.ac b/configure.ac index 3ca23ee..1adc84b 100644 --- a/configure.ac +++ b/configure.ac @@ -1,6 +1,6 @@ AC_PREREQ([2.64]) AC_INIT([HarfBuzz], -[0.9.0], +[0.9.1], [http://bugs.freedesktop.org/enter_bug.cgi?product=harfbuzz], [harfbuzz], [http://harfbuzz.org/]) ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Interaction between default and non default features
On 08/10/2012 12:12 PM, Khaled Hosny wrote: > This is is really meant to be a stylistic set, it shouldn't even be > enabled globally but only for words where a backward yeh looks better > (since unlike Urdu it is just an alternate form of yeh in Arabic). But > if this indeed Uniscribe behaviour, there is little benefit in > deviating from it since I’ll have to do it the hard way anyway. Ah sorry, I missed the Stylistic Set part. Yeah, I'm afraid you have to live with it. b ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Interaction between default and non default features
On Fri, Aug 10, 2012 at 11:39:39AM -0400, Behdad Esfahbod wrote: > On 08/10/2012 10:48 AM, Khaled Hosny wrote: > > So I’m asking if the current behaviour is “final” and no intentions to > > change it, and if anyone knows how other implementations deal with this > > (the Uniscribe backed seems to ignore the stylistic set completely, so I > > don’t know how to test this). > > Yeah, the Uniscribe backend doesn't have features wired up. You just gave me > perfect reason to hack that in today. > > Your best bet is 'locl' I'm afraid. If Uniscribe compatibility is not an > issue, I'm open to providing HarfBuzz-specific behavior. For example, to let > Arabic fonts opt in to have all features applied together. This is is really meant to be a stylistic set, it shouldn't even be enabled globally but only for words where a backward yeh looks better (since unlike Urdu it is just an alternate form of yeh in Arabic). But if this indeed Uniscribe behaviour, there is little benefit in deviating from it since I’ll have to do it the hard way anyway. Regards, Khaled ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Interaction between default and non default features
On 08/10/2012 10:48 AM, Khaled Hosny wrote: > While trying to added a stylistic set to an Arabic font, I found that > they are applied after all default features no matter how the lookups > are ordered in the font. > > I sort of understand why it is done this way, It's actually just to match Uniscribe. Otherwise I would have loved not to do it this way. > but it strikes me as it > renders stylistic sets near useless when any complex substitution is > needed. In my case I want to convert all regular yeh letters to yeh > barree form, but it have to be done before any other substitution to > allow for contextual substitution to take place, doing it after > contextual substitution will require much more complex rules. > > Here is the font for testing: > http://khaledhosny.org/files/tmp/hussaini-nastaleeq_ss01.ttf > > (with something like “ى ىى لى فى”) > > So I’m asking if the current behaviour is “final” and no intentions to > change it, and if anyone knows how other implementations deal with this > (the Uniscribe backed seems to ignore the stylistic set completely, so I > don’t know how to test this). Yeah, the Uniscribe backend doesn't have features wired up. You just gave me perfect reason to hack that in today. Your best bet is 'locl' I'm afraid. If Uniscribe compatibility is not an issue, I'm open to providing HarfBuzz-specific behavior. For example, to let Arabic fonts opt in to have all features applied together. Cheers, behdad > Regards, > Khaled ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] Interaction between default and non default features
While trying to added a stylistic set to an Arabic font, I found that they are applied after all default features no matter how the lookups are ordered in the font. I sort of understand why it is done this way, but it strikes me as it renders stylistic sets near useless when any complex substitution is needed. In my case I want to convert all regular yeh letters to yeh barree form, but it have to be done before any other substitution to allow for contextual substitution to take place, doing it after contextual substitution will require much more complex rules. Here is the font for testing: http://khaledhosny.org/files/tmp/hussaini-nastaleeq_ss01.ttf (with something like “ى ىى لى فى”) So I’m asking if the current behaviour is “final” and no intentions to change it, and if anyone knows how other implementations deal with this (the Uniscribe backed seems to ignore the stylistic set completely, so I don’t know how to test this). Regards, Khaled ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Urdu word lists
On 08/10/2012 08:39 AM, Khaled Hosny wrote: > This should be useful for testing HarfBuzz: > http://www.crulp.org/software/ling_resources.htm Thanks. I compared their wordlist to our Wikipedia wordlist for Urdu. They're quite surprisingly close in number of words and total size :). > (The valid ligatures files is the most interesting, especially with a > font like Nafees Nastaleeq). Yes, those are more interesting. I really should start putting a font collection together and associate them with specific test data. behdad > Regards, > Khaled ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] Urdu word lists
This should be useful for testing HarfBuzz: http://www.crulp.org/software/ling_resources.htm (The valid ligatures files is the most interesting, especially with a font like Nafees Nastaleeq). Regards, Khaled ___ 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-normalize.cc | 106 +--
src/hb-ot-shape.cc |2
2 files changed, 63 insertions(+), 45 deletions(-)
New commits:
commit f4cb4762986a28634fa7de9b706f9d37859b881e
Author: Behdad Esfahbod
Date: Fri Aug 10 03:51:44 2012 -0400
[OT] Slightly adjust normalizer
The change is very subtle. If we have a single-char cluster that
decomposes to three or more characters, then try recomposition, in
case the farther mark may compose with the base.
diff --git a/src/hb-ot-shape-normalize.cc b/src/hb-ot-shape-normalize.cc
index 23c28cc..93dd00c 100644
--- a/src/hb-ot-shape-normalize.cc
+++ b/src/hb-ot-shape-normalize.cc
@@ -286,41 +286,50 @@ skip_char (hb_buffer_t *buffer)
buffer->skip_glyph ();
}
-static bool
+/* Returns 0 if didn't decompose, number of resulting characters otherwise. */
+static inline unsigned int
decompose (hb_font_t *font, hb_buffer_t *buffer, bool shortest, hb_codepoint_t
ab)
{
hb_codepoint_t a, b, a_glyph, b_glyph;
if (!decompose_func (buffer->unicode, ab, &a, &b) ||
(b && !font->get_glyph (b, 0, &b_glyph)))
-return false;
+return 0;
bool has_a = font->get_glyph (a, 0, &a_glyph);
if (shortest && has_a) {
/* Output a and b */
output_char (buffer, a, a_glyph);
-if (b)
+if (likely (b)) {
output_char (buffer, b, b_glyph);
-return true;
+ return 2;
+}
+return 1;
}
- if (decompose (font, buffer, shortest, a)) {
-if (b)
+ unsigned int ret;
+ if ((ret = decompose (font, buffer, shortest, a))) {
+if (b) {
output_char (buffer, b, b_glyph);
-return true;
+ return ret + 1;
+}
+return ret;
}
if (has_a) {
output_char (buffer, a, a_glyph);
-if (b)
+if (likely (b)) {
output_char (buffer, b, b_glyph);
-return true;
+ return 2;
+}
+return 1;
}
- return false;
+ return 0;
}
-static bool
+/* Returns 0 if didn't decompose, number of resulting characters otherwise. */
+static inline bool
decompose_compatibility (hb_font_t *font, hb_buffer_t *buffer, hb_codepoint_t
u)
{
unsigned int len, i;
@@ -329,34 +338,42 @@ decompose_compatibility (hb_font_t *font, hb_buffer_t
*buffer, hb_codepoint_t u)
len = buffer->unicode->decompose_compatibility (u, decomposed);
if (!len)
-return false;
+return 0;
for (i = 0; i < len; i++)
if (!font->get_glyph (decomposed[i], 0, &glyphs[i]))
- return false;
+ return 0;
for (i = 0; i < len; i++)
output_char (buffer, decomposed[i], glyphs[i]);
- return true;
+ return len;
}
-static void
+/* Returns true if recomposition may be benefitial. */
+static inline bool
decompose_current_character (hb_font_t *font, hb_buffer_t *buffer, bool
shortest)
{
hb_codepoint_t glyph;
+ unsigned int len = 1;
/* Kind of a cute waterfall here... */
if (shortest && font->get_glyph (buffer->cur().codepoint, 0, &glyph))
next_char (buffer, glyph);
- else if (decompose (font, buffer, shortest, buffer->cur().codepoint))
+ else if ((len = decompose (font, buffer, shortest, buffer->cur().codepoint)))
skip_char (buffer);
else if (!shortest && font->get_glyph (buffer->cur().codepoint, 0, &glyph))
next_char (buffer, glyph);
- else if (decompose_compatibility (font, buffer, buffer->cur().codepoint))
+ else if ((len = decompose_compatibility (font, buffer,
buffer->cur().codepoint)))
skip_char (buffer);
else
next_char (buffer, glyph); /* glyph is initialized in earlier branches. */
+
+ /*
+ * A recomposition would only be useful if we decomposed into at least three
+ * characters...
+ */
+ return len > 2;
}
static inline void
@@ -378,20 +395,34 @@ handle_variation_selector_cluster (hb_font_t *font,
hb_buffer_t *buffer, unsigne
}
}
-static void
+/* Returns true if recomposition may be benefitial. */
+static inline bool
decompose_multi_char_cluster (hb_font_t *font, hb_buffer_t *buffer, unsigned
int end)
{
/* TODO Currently if there's a variation-selector we give-up, it's just too
hard. */
for (unsigned int i = buffer->idx; i < end; i++)
if (unlikely (buffer->unicode->is_variation_selector
(buffer->info[i].codepoint))) {
handle_variation_selector_cluster (font, buffer, end);
- return;
+ return false;
}
while (buffer->idx < end)
decompose_current_character (font, buffer, false);
+ /* We can be smarter here and only return true if there are at least two
ccc!=0 marks.
+ * But does not matter. */
+ return true;
+}
+
+static inline bool
+decompose_cluster (hb_font_t *font, hb_buffer_t *buffer, bool recompose,
unsigned int end)
+{
+ if (likely (buffer->idx + 1 == end))
+return decompose_current_character (font, buffer, recompose);
+ else
+return decompose_multi_char_cluster (font, buffer, end);
}
+
static int
compare_combining_class (const hb_glyph_info_t *pa, const hb_glyph_info
