On 07/08/11 18:52, Sebastien Metrot wrote: > Hi Behdad, Hi Sebastien,
> - ucdata is a simple unicode API that has two main uses: it can provide you > with many useful glyph infos (is a glyph printable? what is its class? etc.). > It also provides methods to decompose and compose code points and I have > added a simple method that can completely compose / decompose unicode > strings. It also comes with a companion lib named ucpgba for Pretty Good Bidi > Algorithm. It seems to work fine and I plan to use it in my code soon. > Mainly, ucdata permits me not to rely on an existing system API to compose > and decompse strings for me. There are probably more uses for ucdata that I > don't know about. Do you have a link? Where is the canonical source repository? > - How should I create the hb_unicode_funcs_t? Create an empty one and fill > the struct by hand? Create an empty one and populate using the _set functions, eg. hb_unicode_set_general_category_func(). Note, I had to change the type names for the callbacks a last week. I'll make a 0.8 release with those changes soon. > - Most importantly I think I have found the reason for the problem: my font > code uses the freetype2 cache API > (http://www.freetype.org/freetype2/docs/reference/ft2-cache_subsystem.html) > while harbuzz glue calls directly into the regular API. This means that when > I have more that one instance of the same face but with differing sizes, the > shaper will only know about one. Once I display then text I use the correctly > sized glyphs but they are layed out with the wrong metrics. There are two > solutions for me. The first one is to stop using the cache but I'm afraid to > slow my code too much at execution time. The second one is to create an new > set of freetype/harfbuzz glue functions that use the cache too. I will > probably try this second option (unless to see reasons not to ;-) ) and I'll > report back with the code I end up using once it works. Ok, glad you found it out. I never digged the FTC API. Taking a quick look, I imagine some hb-ft API to take a explicit FT_Size may be what you need? behdad > > Cheers! > > S. > > > On Jul 8, 2011, at 6:13 AM, Behdad Esfahbod wrote: > >> Hi Sebastien, >> >> Sorry for the late reply. Comments inline. >> >> On 07/04/11 06:05, Sebastien Metrot wrote: >>> Hi, >>> >>> I'm seeing strange bugs in my toolkit after converting my font layout engine >>> to harfbuzz-ng shaping. While most fonts work alright, some have wrong X >>> axis >>> density as you can see on this (rather big) >>> screenshot: http://meeloo.net/~meeloo/nui_harfbuzz.png >>> >>> At least two fonts have problems: Helvetica.dfont (from Mac OSX Snow >>> Leopard), >>> Meiryo.ttf (from OSX too) and the the open source Vera Sans Mono from >>> bitstream. >>> As you can see on the screenshot, all sizes of Vera Sans Mono don't show the >>> same problem, as the 8pt version looks alright. >>> >>> My toolkit uses harfbuzz + freetype2 with the harfbuzz provided freetype >>> glue >>> code. The unicode callbacks are implemented via a mix of custom code (for >>> script detection) and ucdata (for code point features). >> >> A general point: please don't use the hb_ namespace for your own code. Ie, >> hb_nui_get_unicode_funcs() would be better named >> nui_hb_get_unicode_funcs()... >> >> Also, what's ucdata exactly? I couldn't find a definitive answer. Seems >> like >> many projects include it. Maybe we can provide glue for it in hb itself. >> >> Also, please don't include hb-private.h. That's not a public header. You >> should allocate your hb_unicode_funcs_t at runtime and cache it. >> >> >>> You can have a look at the code >>> here https://github.com/meeloo/nui3/tree/utf8/src/Font . I call harfbuzz >>> only >>> in one >>> function: >>> https://github.com/meeloo/nui3/blob/utf8/src/Font/nuiFontBase.cpp#L2114 >> >> BTW, since I changed the hb_font to include a reference to the face, you are >> not using hb_face anymore, so you can remove that variable. >> >> >>> Before using harfbuzz I was using a very naive algorithm (that is just using >>> glyph advances) but I was not having these problems (but I couldn't handle >>> complex scripts either ;-) ). >>> >>> I would like to know if this is a bug on my part (most likely) or a problem >>> in >>> the shaping algorithm. >> >> I can't tell, from a quick look at the code. My main guess is that you are >> setting font size after shaping and before showing. But that's a wild guess. >> >> behdad >> >> >>> Thank you very much if you've read this far. >>> >>> >>> -- >>> Sébastien Métrot >>> libnui author >>> http://libnui.net > > _______________________________________________ > HarfBuzz mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/harfbuzz > _______________________________________________ HarfBuzz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/harfbuzz
