[HarfBuzz] Helvetica.dfont & BitStream Vera Sans Mono problems

[Sebastien Metrot]

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