Hi,
I pushed out a few commits that should address your problems. Please test.
Cheers,
behdad
On 08/03/11 21:46, Sebastien Metrot wrote:
> On Aug 4, 2011, at 2:46 AM, Behdad Esfahbod wrote:
>
>>
>> On 08/03/11 20:39, Sebastien Metrot wrote:
>>> Hi All,
>>>
>>> I have added harfbuzz-ng to my GUI framework and it now works fine on OSX
>>> and iOS. While compiling the code on windows, I had to make some changes to
>>> get harfbuzz to build and run:
>>> - USHORT, SHORT, ULONG and LONG are already defined by the Win32 SDK so I
>>> had to #define them in hb-opentype-private.hh:
>>
>> What a weird coincidence! I just did that yesterday. Try with master.
>
> Oh, cool will try.
>
>>> - I also had to disable the extern "C" { } declarations, all code now being
>>> in .cc files and some functions returning class object, the compiler
>>> refuses them. So I changed line 32 of hb_common.h to: # if (defined
>>> __cplusplus) && (!defined WIN32)
>>
>> Well, we need those in the public .h files at least. I'll give it a look
>> again. There was some weird reason I added them to .cc files.
>>
>> Which functions return class objects BTW?
>>
>
> I just checked and the errors comes from the inclusion of the intrisics
> headers for the atomic operations. The actual error from the compiler is:
> 1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\ivec.h(96) :
> warning C4190: '&' has C-linkage specified, but returns UDT 'M64' which is
> incompatible with C
> 1> C:\Program Files (x86)\Microsoft Visual Studio
> 9.0\VC\include\ivec.h(77) : see declaration of 'M64'
>
> There are TONS of similar errors for most functions in those headers. I'm
> pretty sure I saw the non POD error once but it seems I can't trigger it
> again now.
>
>
>>
>>> - Last but not least, I noticed what looks like a bug to me: the
>>> declaration of the hb_prealloced_array_t template lacks a constructor, so
>>> all its data is rubbish if the compiler doesn't blank it or if the memory
>>> is not already zeroed, which is the case with visual C++.
>>
>> Interesting. I'll take a look. Can you clarify: is the static global
>> instances you are talking about or any other ones? I assumed global ones get
>> zeroed like POD structs in C are.
>>
>
> If I remove the ctor I get an access violation in
>> TextEdit.exe!hb_ot_map_builder_t::feature_info_t::cmp(const
>> hb_ot_map_builder_t::feature_info_t * a=0x0018e744, const
>> hb_ot_map_builder_t::feature_info_t * b=0x8018e718) Line 171 + 0xc bytes C++
>
> depending on the font and the text I try to render, a or/and b seem to be
> pointing to wrong places in memory. I'm unsure about the rules about structs
> inits in c++ as I mostly don't use them (and I memset them when I do).
>
>>
>>> With all these changes I have been able to build harfbuzz and two of my
>>> test programs. The bad news is that the first program runs but displays
>>> mismatched glyphs (and that's for Latin1 text with the Vera Sans mono font,
>>> so I guess it should be pretty simple). The second program seems stuck in a
>>> loop in the method hb_ot_map_builder_t::compile(...) with the font Andalus
>>> and some arabian text.
>>
>> That's not what I expect...
>
> Ok, there was at least one bug that was mine, Latin1 now seems to work (I was
> feeding wchar_t to hb_buffer_add_utf32 but wchar_t on windows is actually
> UCS, I replaced the call with hb_buffer_add_utf16).
> Concerning the second problem, I have investigated a bit and It seems that
> the class ht_ot_map_builder_t also lacks a ctor to init current_state. If I
> add one and init current_state[] to 0, I can get passed the infinite loop and
> into a crash in MY code that I will look into now ;-).
>
> Thanks for your help :-)
>
> S.
>
>
> _______________________________________________
> HarfBuzz mailing list
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/harfbuzz
>
_______________________________________________
HarfBuzz mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
