Hi Behdad,

Thanks you for this reply! I looked into the code and it helped me find some 
leads.

- I have changed the function names so that it uses nui_hb_xxx instead of 
hb_nui_xxx
- 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.
- How should I create the hb_unicode_funcs_t? Create an empty one and fill the 
struct by hand? Create the default one and fill it by hand? Any other option? 
(sorry, looking at the official API made me think of a couple of ways this 
could work and gave me no idea of the best to try...).
- I removed hb_face, thanks for the "heads up" :-).
- 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.

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

Reply via email to