I initially thought that this was to prevent an infinite recursion of
contextual lookups.
I'm working with OpenType myself (not harfbuzz) and this is something that
I think is not clarified in the specification. Can a contextual
substitution invoke another contextual substitution and recurse? Is
regards
Petr Kobalicek
On Mon, Jan 16, 2012 at 5:22 PM, Behdad Esfahbod beh...@behdad.org wrote:
On 01/16/2012 10:16 AM, Behdad Esfahbod wrote:
On 01/16/2012 02:03 AM, Petr Kobalíček wrote:
Hi Behdad,
yes, I saw these errors when compiling file hb-tt-font.cc. I removed
it and harfbuzz compiled
Hi list,
While porting harfbuzz to be used with Fog I encountered that the
static initialization of some C++ classes (global mutex and langs
list) happened before Fog and this caused runtime error which I'm
unable to fix without making changes to harfbuzz. Static
initialization is unpredictable
Hi Behdad,
On Thu, Jan 5, 2012 at 7:49 PM, Behdad Esfahbod beh...@behdad.org wrote:
On 01/05/2012 11:43 AM, Petr Kobalíček wrote:
Another solution can be to maintain my private version of patched
harfbuzz, but personally I don't like this idea.
People have successfully compiled HarfBuzz
/software/chromium/notes/2011/08/static-initializers.html
discusses more of the reasons why.
On Sat, Jan 7, 2012 at 9:40 AM, Petr Kobalíček kobalicek.p...@gmail.com
wrote:
Hi list,
While porting harfbuzz to be used with Fog I encountered that the
static initialization of some C++ classes
Hello list,
I'm trying to compile harfbuzz using MSVS2010. I just added important
files into the project and added bridge between Fog-Framework and
harfbuzz. But I encountered a problem that harfbuzz defines types
which conflicts with types which are part of Win32/64 API.
The error starts here:
Hello list,
I'd like to ask what is real purpose/advantage to have hb_unicode_funcs_t?
I know that this is a wrapper to the real implementation, but is there
another use-case to switch unicode functions on the fly and per
hb_buffer?
Thanks!
Petr Kobalicek
