Re: [HarfBuzz] harfbuzz: Branch 'master'

[Behdad Esfahbod]

Please file github issues if issue persists.

On Mon, Sep 10, 2018 at 11:44 AM, Behdad Esfahbod  wrote:

> On Fri, Sep 7, 2018 at 5:22 PM, John Emmas 
> wrote:
>
>> On 07/09/2018 15:24, Behdad Esfahbod wrote:
>>
>>>   src/hb-subset.cc |3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>>
>> Forgive me if this is unrelated - but when building with MSVC, should I
>> be building harfbuzz as a static library or as a DLL?
>>
>
> Up to you.
>
>
>> Currently I'm building as a static lib and up until a month ago that
>> always worked fine.  Then yesterday I downloaded again and tried to build
>> both harfbuzz and pango.  Unfortunately, pangoft2 is failing to link.  I
>> see a lot of errors about symbols being defined twice - i.e. pangoft2 has
>> them defined when they're already available in harfbuzz (so the linker
>> doesn't know which one to use).  The error messages are a bit long-winded
>> but they all seem to involve 'OT::Lookup::subset'
>>
>
> Don't compile hb-subset.cc.  I don't know how you are compiling.  But you
> shouldn't get duplicates anyway.
>
>
>> Am I right in thinking 'OT::Lookup::subset' Is something that's been
>> added recently?
>>
>
> It is new.  Not sure what's different about that though.
>
>
>> John
>>
>> ___
>> HarfBuzz mailing list
>> HarfBuzz@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/harfbuzz
>>
>
>
>
> --
> behdad
> http://behdad.org/
>



-- 
behdad
http://behdad.org/
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Behdad Esfahbod]

On Fri, Sep 7, 2018 at 5:22 PM, John Emmas  wrote:

> On 07/09/2018 15:24, Behdad Esfahbod wrote:
>
>>   src/hb-subset.cc |3 +++
>>   1 file changed, 3 insertions(+)
>>
>>
> Forgive me if this is unrelated - but when building with MSVC, should I be
> building harfbuzz as a static library or as a DLL?
>

Up to you.


> Currently I'm building as a static lib and up until a month ago that
> always worked fine.  Then yesterday I downloaded again and tried to build
> both harfbuzz and pango.  Unfortunately, pangoft2 is failing to link.  I
> see a lot of errors about symbols being defined twice - i.e. pangoft2 has
> them defined when they're already available in harfbuzz (so the linker
> doesn't know which one to use).  The error messages are a bit long-winded
> but they all seem to involve 'OT::Lookup::subset'
>

Don't compile hb-subset.cc.  I don't know how you are compiling.  But you
shouldn't get duplicates anyway.


> Am I right in thinking 'OT::Lookup::subset' Is something that's been added
> recently?
>

It is new.  Not sure what's different about that though.


> John
>
> ___
> HarfBuzz mailing list
> HarfBuzz@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/harfbuzz
>



-- 
behdad
http://behdad.org/
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[John Emmas]

On 07/09/2018 15:24, Behdad Esfahbod wrote:

  src/hb-subset.cc |3 +++
  1 file changed, 3 insertions(+)



Forgive me if this is unrelated - but when building with MSVC, should I 
be building harfbuzz as a static library or as a DLL?


Currently I'm building as a static lib and up until a month ago that 
always worked fine.  Then yesterday I downloaded again and tried to 
build both harfbuzz and pango.  Unfortunately, pangoft2 is failing to 
link.  I see a lot of errors about symbols being defined twice - i.e. 
pangoft2 has them defined when they're already available in harfbuzz (so 
the linker doesn't know which one to use).  The error messages are a bit 
long-winded but they all seem to involve 'OT::Lookup::subset'


Am I right in thinking 'OT::Lookup::subset' Is something that's been 
added recently?


John
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Behdad Esfahbod]

On Tue, Feb 20, 2018 at 6:24 PM, Richard Wordingham <
richard.wording...@ntlworld.com> wrote:

> On Tue, 20 Feb 2018 22:36:46 + (UTC)
> beh...@kemper.freedesktop.org (Behdad Esfahbod) wrote:
>
> > +++ b/src/hb-ot-shape-complex-indic-machine.hh
> ...
> > +static const short _indic_syllable_machine_indicies[] = {
>
> Have you been advised that the English word is spelt 'indices'?
>

That's generated code by Ragel. CC'ing Adrian.

-- 
behdad
http://behdad.org/
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Richard Wordingham]

On Tue, 20 Feb 2018 22:36:46 + (UTC)
beh...@kemper.freedesktop.org (Behdad Esfahbod) wrote:

> +++ b/src/hb-ot-shape-complex-indic-machine.hh
...
> +static const short _indic_syllable_machine_indicies[] = {

Have you been advised that the English word is spelt 'indices'?

Richard.
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Behdad Esfahbod]

On Thu, Sep 14, 2017 at 6:03 PM, Konstantin Ritt  wrote:

> What about MinGW, MSVC, WinCE? I don't think they'll be so nice to use
> autoconf ;)
>

They can define HAVE_...?

Or if you mean the cmake system, I don't maintain it.  Ebrahim, etc do.
They can adapt this.

Regards,
> Konstantin
>
> 2017-09-15 4:51 GMT+04:00 Behdad Esfahbod :
>
>>  configure.ac |4 ++--
>>  src/hb-common.cc |   53 ++
>> +--
>>  2 files changed, 53 insertions(+), 4 deletions(-)
>>
>> New commits:
>> commit 3ca69c8c32b8408dd9f8e6e866cd07e58c0d79b7
>> Author: Behdad Esfahbod 
>> Date:   Thu Sep 14 20:50:35 2017 -0400
>>
>> Use strtod_l() to correctly parse decimal numbers in French & other
>> locales
>>
>> Test with, eg.:
>> $ LC_ALL=fr_FR.utf-8 ./hb-view NotoSansArabic-VF.ttf بهداد
>> --variations wght=1.2
>>
>> diff --git a/configure.ac b/configure.ac
>> index 9151abc0..d65cae8c 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -69,8 +69,8 @@ GTK_DOC_CHECK([1.15],[--flavour no-tmpl])
>>  ])
>>
>>  # Functions and headers
>> -AC_CHECK_FUNCS(atexit mprotect sysconf getpagesize mmap isatty)
>> -AC_CHECK_HEADERS(unistd.h sys/mman.h)
>> +AC_CHECK_FUNCS(atexit mprotect sysconf getpagesize mmap isatty newlocale
>> strtod_l)
>> +AC_CHECK_HEADERS(unistd.h sys/mman.h xlocale.h)
>>
>>  # Compiler flags
>>  AC_CANONICAL_HOST
>> diff --git a/src/hb-common.cc b/src/hb-common.cc
>> index 0483816d..8e8e5565 100644
>> --- a/src/hb-common.cc
>> +++ b/src/hb-common.cc
>> @@ -32,6 +32,9 @@
>>  #include "hb-object-private.hh"
>>
>>  #include 
>> +#ifdef HAVE_XLOCALE_H
>> +#include 
>> +#endif
>>
>>
>>  /* hb_options_t */
>> @@ -246,8 +249,8 @@ struct hb_language_item_t {
>>  static hb_language_item_t *langs;
>>
>>  #ifdef HB_USE_ATEXIT
>> -static
>> -void free_langs (void)
>> +static void
>> +free_langs (void)
>>  {
>>while (langs) {
>>  hb_language_item_t *next = langs->next;
>> @@ -694,6 +697,48 @@ parse_uint32 (const char **pp, const char *end,
>> uint32_t *pv)
>>return true;
>>  }
>>
>> +#if defined (HAVE_NEWLOCALE) && defined (HAVE_STRTOD_L)
>> +#define USE_XLOCALE 1
>> +#endif
>> +
>> +#ifdef USE_XLOCALE
>> +
>> +static locale_t C_locale;
>> +
>> +#ifdef HB_USE_ATEXIT
>> +static void
>> +free_C_locale (void)
>> +{
>> +  if (C_locale)
>> +freelocale (C_locale);
>> +}
>> +#endif
>> +
>> +static locale_t
>> +get_C_locale (void)
>> +{
>> +retry:
>> +  locale_t C = (locale_t) hb_atomic_ptr_get (_locale);
>> +
>> +  if (unlikely (!C))
>> +  {
>> +C = newlocale (LC_ALL_MASK, "C", NULL);
>> +
>> +if (!hb_atomic_ptr_cmpexch (_locale, NULL, C))
>> +{
>> +  freelocale (C_locale);
>> +  goto retry;
>> +}
>> +
>> +#ifdef HB_USE_ATEXIT
>> +atexit (free_C_locale); /* First person registers atexit() callback.
>> */
>> +#endif
>> +  }
>> +
>> +  return C;
>> +}
>> +#endif
>> +
>>  static bool
>>  parse_float (const char **pp, const char *end, float *pv)
>>  {
>> @@ -707,7 +752,11 @@ parse_float (const char **pp, const char *end, float
>> *pv)
>>float v;
>>
>>errno = 0;
>> +#ifdef USE_XLOCALE
>> +  v = strtod_l (p, , get_C_locale ());
>> +#else
>>v = strtod (p, );
>> +#endif
>>if (errno || p == pend)
>>  return false;
>>
>>
>> ___
>> HarfBuzz mailing list
>> HarfBuzz@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/harfbuzz
>>
>>
>
> ___
> HarfBuzz mailing list
> HarfBuzz@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/harfbuzz
>
>


-- 
behdad
http://behdad.org/
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Konstantin Ritt]

What about MinGW, MSVC, WinCE? I don't think they'll be so nice to use
autoconf ;)

Regards,
Konstantin

2017-09-15 4:51 GMT+04:00 Behdad Esfahbod :

>  configure.ac |4 ++--
>  src/hb-common.cc |   53 ++
> +--
>  2 files changed, 53 insertions(+), 4 deletions(-)
>
> New commits:
> commit 3ca69c8c32b8408dd9f8e6e866cd07e58c0d79b7
> Author: Behdad Esfahbod 
> Date:   Thu Sep 14 20:50:35 2017 -0400
>
> Use strtod_l() to correctly parse decimal numbers in French & other
> locales
>
> Test with, eg.:
> $ LC_ALL=fr_FR.utf-8 ./hb-view NotoSansArabic-VF.ttf بهداد
> --variations wght=1.2
>
> diff --git a/configure.ac b/configure.ac
> index 9151abc0..d65cae8c 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -69,8 +69,8 @@ GTK_DOC_CHECK([1.15],[--flavour no-tmpl])
>  ])
>
>  # Functions and headers
> -AC_CHECK_FUNCS(atexit mprotect sysconf getpagesize mmap isatty)
> -AC_CHECK_HEADERS(unistd.h sys/mman.h)
> +AC_CHECK_FUNCS(atexit mprotect sysconf getpagesize mmap isatty newlocale
> strtod_l)
> +AC_CHECK_HEADERS(unistd.h sys/mman.h xlocale.h)
>
>  # Compiler flags
>  AC_CANONICAL_HOST
> diff --git a/src/hb-common.cc b/src/hb-common.cc
> index 0483816d..8e8e5565 100644
> --- a/src/hb-common.cc
> +++ b/src/hb-common.cc
> @@ -32,6 +32,9 @@
>  #include "hb-object-private.hh"
>
>  #include 
> +#ifdef HAVE_XLOCALE_H
> +#include 
> +#endif
>
>
>  /* hb_options_t */
> @@ -246,8 +249,8 @@ struct hb_language_item_t {
>  static hb_language_item_t *langs;
>
>  #ifdef HB_USE_ATEXIT
> -static
> -void free_langs (void)
> +static void
> +free_langs (void)
>  {
>while (langs) {
>  hb_language_item_t *next = langs->next;
> @@ -694,6 +697,48 @@ parse_uint32 (const char **pp, const char *end,
> uint32_t *pv)
>return true;
>  }
>
> +#if defined (HAVE_NEWLOCALE) && defined (HAVE_STRTOD_L)
> +#define USE_XLOCALE 1
> +#endif
> +
> +#ifdef USE_XLOCALE
> +
> +static locale_t C_locale;
> +
> +#ifdef HB_USE_ATEXIT
> +static void
> +free_C_locale (void)
> +{
> +  if (C_locale)
> +freelocale (C_locale);
> +}
> +#endif
> +
> +static locale_t
> +get_C_locale (void)
> +{
> +retry:
> +  locale_t C = (locale_t) hb_atomic_ptr_get (_locale);
> +
> +  if (unlikely (!C))
> +  {
> +C = newlocale (LC_ALL_MASK, "C", NULL);
> +
> +if (!hb_atomic_ptr_cmpexch (_locale, NULL, C))
> +{
> +  freelocale (C_locale);
> +  goto retry;
> +}
> +
> +#ifdef HB_USE_ATEXIT
> +atexit (free_C_locale); /* First person registers atexit() callback.
> */
> +#endif
> +  }
> +
> +  return C;
> +}
> +#endif
> +
>  static bool
>  parse_float (const char **pp, const char *end, float *pv)
>  {
> @@ -707,7 +752,11 @@ parse_float (const char **pp, const char *end, float
> *pv)
>float v;
>
>errno = 0;
> +#ifdef USE_XLOCALE
> +  v = strtod_l (p, , get_C_locale ());
> +#else
>v = strtod (p, );
> +#endif
>if (errno || p == pend)
>  return false;
>
>
> ___
> HarfBuzz mailing list
> HarfBuzz@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/harfbuzz
>
>
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Jonathan Kew]

On 10/08/2017 05:43, Martin Hosken wrote:

Dear Behdad,


-  if (buffer == NULL)
+  if (!buffer)


Always wanting to learn. How does this cause a divide by zero? Or what led you 
to make the change?


It doesn't, that's purely stylistic. The real change in this commit 
comes later on:


 const OT::IndexSubtableRecord *subtable_record = 
this->cblc->find_table(glyph, _ppem, _ppem);

-if (subtable_record == NULL)
+if (!subtable_record || !x_ppem || !y_ppem)
   return false;

with the addition of the zero-check for the x_ppem and y_ppem values.

___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Konstantin Ritt]

> -if (subtable_record == NULL)
> +if (!subtable_record || !x_ppem || !y_ppem)
> return false;

is the real fix. The other changes are no-op.


Regards,
Konstantin

2017-08-10 8:43 GMT+04:00 Martin Hosken :

> Dear Behdad,
>
> > -  if (buffer == NULL)
> > +  if (!buffer)
>
> Always wanting to learn. How does this cause a divide by zero? Or what led
> you to make the change?
>
> TIA,
> Martin
> ___
> HarfBuzz mailing list
> HarfBuzz@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/harfbuzz
>



Без
вирусов. www.avast.ru

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Martin Hosken]

Dear Behdad,

> -  if (buffer == NULL)
> +  if (!buffer)

Always wanting to learn. How does this cause a divide by zero? Or what led you 
to make the change?

TIA,
Martin
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master' - 2 commits

[John Emmas]

Off-topic - but is anything happening about my recent report (regarding 
the introduction of strtof() in hb-common.cc):-


https://lists.freedesktop.org/archives/harfbuzz/2017-February/005885.html

I can fix it locally if this can't get fixed upstream for some reason?

John

On 17/02/2017 03:07, Behdad Esfahbod wrote:

  src/hb-ot-layout-gsubgpos-private.hh|
6 +++---
  src/hb-ot-shape-complex-indic-table.cc  |
7 +++
  test/shaping/fonts/sha1sum/3493e92eaded2661cadde752a39f9d58b11f0326.ttf 
|binary
  test/shaping/fonts/sha1sum/558661aa659912f4d30ecd27bd09835171a8e2b0.ttf 
|binary
  test/shaping/tests/fuzzed.tests |
1 +
  test/shaping/tests/indic-script-extensions.tests|
1 +
  6 files changed, 12 insertions(+), 3 deletions(-)

New commits:
commit 44f7d6ecde9bf7427a05cbe73ed5d668b8a72b2a
Author: jfkthame
Date:   Fri Feb 17 03:03:24 2017 +

 Guard against underflow when adjusting length (#421)
 
 * Guard against underflow when adjusting length
 
 With the fuzz-testcase in mozilla bug 1295299, we end up with a recursed lookup that removes 3 items, when `match_positions[idx]` is 0, which results in (unsigned) `end` wrapping to a huge value.
 
 Making `end` a signed int is probably the simplest route to a fix.
 
 Fixeshttps://bugzilla.mozilla.org/show_bug.cgi?id=1295299.
 
 * Add testcase for #421.


diff --git a/src/hb-ot-layout-gsubgpos-private.hh 
b/src/hb-ot-layout-gsubgpos-private.hh
index b7a0122..0c42352 100644
--- a/src/hb-ot-layout-gsubgpos-private.hh
+++ b/src/hb-ot-layout-gsubgpos-private.hh
@@ -959,7 +959,7 @@ static inline bool apply_lookup (hb_apply_context_t *c,
TRACE_APPLY (NULL);
  
hb_buffer_t *buffer = c->buffer;

-  unsigned int end;
+  int end;
  
/* All positions are distance from beginning of *output* buffer.

 * Adjust. */
@@ -998,8 +998,8 @@ static inline bool apply_lookup (hb_apply_context_t *c,
  
  /* Recursed lookup changed buffer len.  Adjust. */
  
-end = int (end) + delta;

-if (end <= match_positions[idx])
+end += delta;
+if (end <= int (match_positions[idx]))
  {
/* End might end up being smaller than match_positions[idx] if the 
recursed
 * lookup ended up removing many items, more than we have had matched.
diff --git 
a/test/shaping/fonts/sha1sum/558661aa659912f4d30ecd27bd09835171a8e2b0.ttf 
b/test/shaping/fonts/sha1sum/558661aa659912f4d30ecd27bd09835171a8e2b0.ttf
new file mode 100644
index 000..5d72fdf
Binary files /dev/null and 
b/test/shaping/fonts/sha1sum/558661aa659912f4d30ecd27bd09835171a8e2b0.ttf differ
diff --git a/test/shaping/tests/fuzzed.tests b/test/shaping/tests/fuzzed.tests
index 771ac2b..d9bace3 100644
--- a/test/shaping/tests/fuzzed.tests
+++ b/test/shaping/tests/fuzzed.tests
@@ -10,3 +10,4 @@ 
fonts/sha1sum/3511ff5c1647150595846ac414c595cccac34f18.ttf:--font-funcs=ot:U+004
  
fonts/sha1sum/fab39d60d758cb586db5a504f218442cd1395725.ttf:--font-funcs=ot:U+0041,U+0041:[gid0=0+1000|gid0=1+1000]
  
fonts/sha1sum/205edd09bd3d141cc9580f650109556cc28b22cb.ttf:--font-funcs=ot:U+0041:[gid0=0+1000]
  
fonts/sha1sum/217a934cfe15c548b572c203dceb2befdf026462.ttf:--font-funcs=ot:U+0061,U+0061,U+0061:[]
+fonts/sha1sum/558661aa659912f4d30ecd27bd09835171a8e2b0.ttf:--font-funcs=ot:U+FFFD,U+E0100,U+FFFD,U+E0010:[]
commit 45766b673f427bb791c9d5886cadedfac0447066
Author: jfkthame
Date:   Thu Feb 16 17:40:21 2017 +

 [indic] Add support for Grantha marks that may be used in Tamil to th… 
(#401)
 
 * [indic] Add support for Grantha marks that may be used in Tamil to the Indic table.
 
 Seehttps://bugzilla.mozilla.org/show_bug.cgi?id=1331339.
 
 Testcase: U+0BA4,U+0BC6,U+1133c,U+0BAA,U+1133c,U+0BC6,U+1133c
 
 * [indic] Add test for Grantha nukta that is allowed in Tamil by ScriptExtensions.txt


diff --git a/src/hb-ot-shape-complex-indic-table.cc 
b/src/hb-ot-shape-complex-indic-table.cc
index 80a6b25..e10a4d2 100644
--- a/src/hb-ot-shape-complex-indic-table.cc
+++ b/src/hb-ot-shape-complex-indic-table.cc
@@ -422,6 +422,13 @@ hb_indic_get_categories (hb_codepoint_t u)
if (hb_in_range (u, 0xAA60u, 0xAA7Fu)) return indic_table[u - 0xAA60u + 
indic_offset_0xaa60u];
break;
  
+case 0x11u:

+  // According to ScriptExtensions.txt, these Grantha marks may also be 
used in Tamil,
+  // so the Indic shaper needs to know their categories.
+  if (unlikely (u == 0x11303)) return _(Vs,R);
+  if (unlikely (u == 0x1133c)) return _(N,B);
+  break;
+
  default:
break;
}
diff --git 
a/test/shaping/fonts/sha1sum/3493e92eaded2661cadde752a39f9d58b11f0326.ttf 
b/test/shaping/fonts/sha1sum/3493e92eaded2661cadde752a39f9d58b11f0326.ttf
new file mode 100644
index 000..006adb6
Binary files /dev/null and 

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Behdad Esfahbod]

On 16-01-04 02:33 AM, Martin Hosken wrote:
> Dear Behdad,
> 
>>> So, I would add an enum to the debug message to give a debug message event 
>>> type.
>>
>> My current thinking is that everything is transferred as a text API in
>> one-line messages.  The client can transform that to an enum if desired.
> 
> That works only if the messages are constrained to be parsable. In effect the 
> string is being used as a way of passing an identifier and varargs. To make 
> life easy for the poor debugger, the messages should be structured in a way 
> that makes them parsable without knowing the context of the message.

You can think of it that way.  The nice thing about a message API is that it
will be trivial to pass the info to another process, or just write it to a file.


>>> One big question that always needs to be answered in the debugger is: where 
>>> are we? Where in the buffer are we now processing. This is the idx field of 
>>> the buffer. I don't think this is exposed in the public buffer interface. 
>>> So it either needs to be exposed or passed as part of the debug message.
>>
>> I'm unsure about this one.  We don't expose the out_buf pard of the buffer, 
>> so
>> calling client code in the middle of a pass of transformation is harmful
>> currently.  Exposing all of that, on the other hand, leaks a lot of the 
>> buffer
>> design, which I like to avoid right now.  Indeed, we might end up changing 
>> the
>> buffer internals to accommodate the lookup direction proposal.
>>
>> So, for now, no callbacks in the middle of a pass.  I understand that's far
>> from ideal, but at least we are now answering the big question: which lookup
>> did what.
> 
> It doesn't answer: which lookup did what *where*. It's the "where" I am 
> trying to answer. If you get given the buffer before the change and after, 
> it's asking a lot of the debugger to work out precisely where the change 
> occurred. Can we, therefore, please pass idx as part of the debug message?

As I tried to explain, we can't make a callback in the middle of the run.
Indeed.  Maybe you can explain or show screenshots or screenshoots of what
kind of debugger you have in mind.  You have one for Graphite, right?  I
wanted to get a live demo from you at the OpenType meeting, but we forgot.

For me, I've imagined that mostly the consumer of this is a human reading the
messages, not a GUI debugger per se...


>>> For GPOS we need to be passing parameters like the two points in an 
>>> attachment or the actual calculated offset in a pair or single adjustment. 
>>> When doing classed based activities, we should be passing the class values 
>>> involved or perhaps pointers (or offsets) to the data structures involved 
>>> so that a debugger can turn cross reference that back to source code.
>>
>> GPOS is more friendly since the buffer structure is fully exposed.  Though,
>> deferred attachments won't be exposed.
> 
> But even with the buffer, you don't know which AP was used and what the 
> relative positions were of the APs.

We are *not* going to expose the entire GSUB/GPOS details in any API.


>> I'm probably going to add shape_plan to list of arguments.  After that, if I
>> make a release, the API is here to stay...  So, speak very loudly if you 
>> think
>> for whatever reason this is not workable.  Ie, there are things that cannot 
>> be
>> done using a message.  I can't think of any.
> 
> Bear in mind that the structure of the message, at least at a high level, is 
> part of that API.

Yes, indeed.  And we need to document it.

As mentioned before, I even support a harfbuzz-support.so or
harfbuzz-debugger.so that parses the message into the kind of API you want.  I
just don't want to put that in harfbuzz.so.  However, I first want to see what
kind of uses you have in mind with that data.

Cheers,
b

> Yours,
> Martin
> 
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Martin Hosken]

Dear Behdad,

> > So, I would add an enum to the debug message to give a debug message event 
> > type.
> 
> My current thinking is that everything is transferred as a text API in
> one-line messages.  The client can transform that to an enum if desired.

That works only if the messages are constrained to be parsable. In effect the 
string is being used as a way of passing an identifier and varargs. To make 
life easy for the poor debugger, the messages should be structured in a way 
that makes them parsable without knowing the context of the message.

> > One big question that always needs to be answered in the debugger is: where 
> > are we? Where in the buffer are we now processing. This is the idx field of 
> > the buffer. I don't think this is exposed in the public buffer interface. 
> > So it either needs to be exposed or passed as part of the debug message.
> 
> I'm unsure about this one.  We don't expose the out_buf pard of the buffer, so
> calling client code in the middle of a pass of transformation is harmful
> currently.  Exposing all of that, on the other hand, leaks a lot of the buffer
> design, which I like to avoid right now.  Indeed, we might end up changing the
> buffer internals to accommodate the lookup direction proposal.
> 
> So, for now, no callbacks in the middle of a pass.  I understand that's far
> from ideal, but at least we are now answering the big question: which lookup
> did what.

It doesn't answer: which lookup did what *where*. It's the "where" I am trying 
to answer. If you get given the buffer before the change and after, it's asking 
a lot of the debugger to work out precisely where the change occurred. Can we, 
therefore, please pass idx as part of the debug message?

> > For GPOS we need to be passing parameters like the two points in an 
> > attachment or the actual calculated offset in a pair or single adjustment. 
> > When doing classed based activities, we should be passing the class values 
> > involved or perhaps pointers (or offsets) to the data structures involved 
> > so that a debugger can turn cross reference that back to source code.
> 
> GPOS is more friendly since the buffer structure is fully exposed.  Though,
> deferred attachments won't be exposed.

But even with the buffer, you don't know which AP was used and what the 
relative positions were of the APs.

> I'm probably going to add shape_plan to list of arguments.  After that, if I
> make a release, the API is here to stay...  So, speak very loudly if you think
> for whatever reason this is not workable.  Ie, there are things that cannot be
> done using a message.  I can't think of any.

Bear in mind that the structure of the message, at least at a high level, is 
part of that API.

Yours,
Martin
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Behdad Esfahbod]

Hi Martin, others,

On 15-12-21 01:59 AM, Martin Hosken wrote:
> Dear Behdad,
> 
>>  buf = hb.buffer_create ()
>> +class Debugger(object):
>> +def message (self, buf, font, msg, data, _x_what_is_this):
>> +print(msg)
>> +return True
>> +debugger = Debugger()
>> +hb.buffer_set_message_func (buf, debugger.message, 1, 0)
>>  hb.buffer_add_utf8 (buf, text.encode('utf-8'), 0, -1)
>>  hb.buffer_guess_segment_properties (buf)
> 
> Yippee. At last, a debug interface :) (Behdad reminds me that I have been 
> asking this once per year for the last 4 years!). Thank you.
> 
> OK. Now to make a great debug interface!
> 
> There are two ways of doing a debug interface: Event driven and One shot. 
> There are probably more, but those are the only two that come to mind now. 
> One shot sends all the information needed to give all the debug information 
> for a debug point in its message. This allows the debugger not to have to 
> keep state, but just record the results and pass them on. Event driven sends, 
> well, events to the debugger and requires the debugger to keep state.
> 
> While one shot seems more inviting and is more in line with what Graphite 
> does. I think for harfbuzz, I would recommend an event based debugger, where 
> you send debug events at the start and end of every lookup, at recursion, 
> during initial reordering and shaping, at dotted circle insertion, etc. and 
> have an enum of events and let the debugger work out what it wants to do with 
> that information.

Agreed about stateful.

> So, I would add an enum to the debug message to give a debug message event 
> type.

My current thinking is that everything is transferred as a text API in
one-line messages.  The client can transform that to an enum if desired.


> One big question that always needs to be answered in the debugger is: where 
> are we? Where in the buffer are we now processing. This is the idx field of 
> the buffer. I don't think this is exposed in the public buffer interface. So 
> it either needs to be exposed or passed as part of the debug message.

I'm unsure about this one.  We don't expose the out_buf pard of the buffer, so
calling client code in the middle of a pass of transformation is harmful
currently.  Exposing all of that, on the other hand, leaks a lot of the buffer
design, which I like to avoid right now.  Indeed, we might end up changing the
buffer internals to accommodate the lookup direction proposal.

So, for now, no callbacks in the middle of a pass.  I understand that's far
from ideal, but at least we are now answering the big question: which lookup
did what.


> I suggest that rather than relying on a message to give the lookup number, 
> that the lookup number be passed as a separate parameter (or in a struct or 
> whatever). The lookup number can be overloaded based on event type. So we 
> could have a starting high level phase event type and use the lookup to say 
> whether that is initial shaping, GSUB, GPOS, etc. for example. Or we could 
> have different event types for each one. That's up to you.

While for regular C APIs I fully agree with you, for this, I'd rather we keep
it as a simple string.  enums and tagged-union types are a headache for
language bindings and even serialization, whereas with 5 lines of code I could
get a debugger going on from Python.  We just need to document the message
syntax completely and it will include all the info that the enum-and-struct
approach does; and performance is definitely not a problem here.

Plus, with a message-based API, clients can handle unknown messages to a
certain degree (eg, printing them out).


> I think we need to send a message each shaper pause when the pause occurs.

Yes, one at the beginning, another at the end.


> For GPOS we need to be passing parameters like the two points in an 
> attachment or the actual calculated offset in a pair or single adjustment. 
> When doing classed based activities, we should be passing the class values 
> involved or perhaps pointers (or offsets) to the data structures involved so 
> that a debugger can turn cross reference that back to source code.

GPOS is more friendly since the buffer structure is fully exposed.  Though,
deferred attachments won't be exposed.


> What does that look like now:
> 
> debug_message(type, buf, idx, lkupidx, void *aptr, void *bptr, msg, ...)
> 
> where aptr and bptr are defined by type and lkupidx and may point to things 
> like an attachment point record or a lookup record in a class based 
> contextual lookup or somesuch. They may also point to debugger specific data 
> structures (perhaps for an attachment point one needs a pointer to the ap 
> record and 2 floats for the resolved x,y coordinates).

That's definitely one thing I *don't* want.


> You know, if we get this right, we should be able to drop the msg, ... since 
> debuggers really don't want to have to parse textual messages. Yes they are 
> easy for a quick trace, but not for a real 

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Martin Hosken]

Dear Behdad,

>  buf = hb.buffer_create ()
> +class Debugger(object):
> + def message (self, buf, font, msg, data, _x_what_is_this):
> + print(msg)
> + return True
> +debugger = Debugger()
> +hb.buffer_set_message_func (buf, debugger.message, 1, 0)
>  hb.buffer_add_utf8 (buf, text.encode('utf-8'), 0, -1)
>  hb.buffer_guess_segment_properties (buf)

Yippee. At last, a debug interface :) (Behdad reminds me that I have been 
asking this once per year for the last 4 years!). Thank you.

OK. Now to make a great debug interface!

There are two ways of doing a debug interface: Event driven and One shot. There 
are probably more, but those are the only two that come to mind now. One shot 
sends all the information needed to give all the debug information for a debug 
point in its message. This allows the debugger not to have to keep state, but 
just record the results and pass them on. Event driven sends, well, events to 
the debugger and requires the debugger to keep state.

While one shot seems more inviting and is more in line with what Graphite does. 
I think for harfbuzz, I would recommend an event based debugger, where you send 
debug events at the start and end of every lookup, at recursion, during initial 
reordering and shaping, at dotted circle insertion, etc. and have an enum of 
events and let the debugger work out what it wants to do with that information.

So, I would add an enum to the debug message to give a debug message event type.

One big question that always needs to be answered in the debugger is: where are 
we? Where in the buffer are we now processing. This is the idx field of the 
buffer. I don't think this is exposed in the public buffer interface. So it 
either needs to be exposed or passed as part of the debug message.

I suggest that rather than relying on a message to give the lookup number, that 
the lookup number be passed as a separate parameter (or in a struct or 
whatever). The lookup number can be overloaded based on event type. So we could 
have a starting high level phase event type and use the lookup to say whether 
that is initial shaping, GSUB, GPOS, etc. for example. Or we could have 
different event types for each one. That's up to you.

I think we need to send a message each shaper pause when the pause occurs.

For GPOS we need to be passing parameters like the two points in an attachment 
or the actual calculated offset in a pair or single adjustment. When doing 
classed based activities, we should be passing the class values involved or 
perhaps pointers (or offsets) to the data structures involved so that a 
debugger can turn cross reference that back to source code.

What does that look like now:

debug_message(type, buf, idx, lkupidx, void *aptr, void *bptr, uint32 aoffset, 
uint32 boffset, msg, ...)

where aoffset and boffset are defined by type and lkupidx and may point to 
things like an attachment point record or a lookup record in a class based 
contextual lookup or somesuch. aptr and bptr may also point to debugger 
specific data structures (perhaps for an attachment point one needs a pointer 
to the ap record and 2 floats for the resolved x,y coordinates). Of course this 
could all end up in a structure of some kind.

You know, if we get this right, we should be able to drop the msg, ... since 
debuggers really don't want to have to parse textual messages. Yes they are 
easy for a quick trace, but not for a real debugger. But it's welcome to stay 
to make such tracing programs' lives easier, but it shouldn't contain anything 
that isn't in the other parameters. If it does, then we need a way to pass it 
outside the message.

And yes, while I'm trying to define what the kitchen sink is, I'm also trying 
to keep this lightweight.

I know the moment I hit send, I'll think of things I've forgotten!

Yours,
Martin
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Martin Hosken]

Dear Behdad,

>  buf = hb.buffer_create ()
> +class Debugger(object):
> + def message (self, buf, font, msg, data, _x_what_is_this):
> + print(msg)
> + return True
> +debugger = Debugger()
> +hb.buffer_set_message_func (buf, debugger.message, 1, 0)
>  hb.buffer_add_utf8 (buf, text.encode('utf-8'), 0, -1)
>  hb.buffer_guess_segment_properties (buf)

Yippee. At last, a debug interface :) (Behdad reminds me that I have been 
asking this once per year for the last 4 years!). Thank you.

OK. Now to make a great debug interface!

There are two ways of doing a debug interface: Event driven and One shot. There 
are probably more, but those are the only two that come to mind now. One shot 
sends all the information needed to give all the debug information for a debug 
point in its message. This allows the debugger not to have to keep state, but 
just record the results and pass them on. Event driven sends, well, events to 
the debugger and requires the debugger to keep state.

While one shot seems more inviting and is more in line with what Graphite does. 
I think for harfbuzz, I would recommend an event based debugger, where you send 
debug events at the start and end of every lookup, at recursion, during initial 
reordering and shaping, at dotted circle insertion, etc. and have an enum of 
events and let the debugger work out what it wants to do with that information.

So, I would add an enum to the debug message to give a debug message event type.

One big question that always needs to be answered in the debugger is: where are 
we? Where in the buffer are we now processing. This is the idx field of the 
buffer. I don't think this is exposed in the public buffer interface. So it 
either needs to be exposed or passed as part of the debug message.

I suggest that rather than relying on a message to give the lookup number, that 
the lookup number be passed as a separate parameter (or in a struct or 
whatever). The lookup number can be overloaded based on event type. So we could 
have a starting high level phase event type and use the lookup to say whether 
that is initial shaping, GSUB, GPOS, etc. for example. Or we could have 
different event types for each one. That's up to you.

I think we need to send a message each shaper pause when the pause occurs.

For GPOS we need to be passing parameters like the two points in an attachment 
or the actual calculated offset in a pair or single adjustment. When doing 
classed based activities, we should be passing the class values involved or 
perhaps pointers (or offsets) to the data structures involved so that a 
debugger can turn cross reference that back to source code.

What does that look like now:

debug_message(type, buf, idx, lkupidx, void *aptr, void *bptr, msg, ...)

where aptr and bptr are defined by type and lkupidx and may point to things 
like an attachment point record or a lookup record in a class based contextual 
lookup or somesuch. They may also point to debugger specific data structures 
(perhaps for an attachment point one needs a pointer to the ap record and 2 
floats for the resolved x,y coordinates).

You know, if we get this right, we should be able to drop the msg, ... since 
debuggers really don't want to have to parse textual messages. Yes they are 
easy for a quick trace, but not for a real debugger. But it's welcome to stay 
to make such tracing programs' lives easier, but it shouldn't contain anything 
that isn't in the other parameters. If it does, then we need a way to pass it 
outside the message.

And yes, while I'm trying to define what the kitchen sink is, I'm also trying 
to keep this lightweight.

I know the moment I hit send, I'll think of things I've forgotten!

Yours,
Martin
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Behdad Esfahbod]

On 15-12-18 07:49 PM, Rajeesh K V wrote:
> Hi Behdad,
> 
> 
> On Thu, Dec 17, 2015 at 6:31 PM, Behdad Esfahbod
> > wrote:
> 
>  src/hb-ot-shape-complex-indic.cc |   11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> New commits:
> commit 508cc3d3cfcfb0383df0fe795cc28db4e0fd5729
> Author: Behdad Esfahbod >
> Date:   Thu Dec 17 17:31:17 2015 +
> 
> [indic] Allow context when matching for Malayalam new-spec
> 
> Test sequence:
> U+0995,U+09CD,U+09B0
> 
> 
> These code points are for Bengali, they don't make sense for Malayalam. Could
> you share more details about this specific test case?
> (I saw that subsequent commit 45b7ec365225109eb0854e6c417f48860b5f24af fixes
> regression introduced by this commit, that made me curious to look into this 
> one).

Err, you are right.  The sequence should have read:

  U+0D32, U+0D4D, U+0D32, U+0D3E

behdad



> With Nirmala shipped on Windows 10, this failed to form the below 
> form.
> Works now.
> 
> Reported by Sairus.
> 
> diff --git a/src/hb-ot-shape-complex-indic.cc
> b/src/hb-ot-shape-complex-indic.cc
> index 5354897..a630419 100644
> --- a/src/hb-ot-shape-complex-indic.cc
> +++ b/src/hb-ot-shape-complex-indic.cc
> @@ -557,8 +557,15 @@ data_create_indic (const hb_ot_shape_plan_t *plan)
>indic_plan->virama_glyph = (hb_codepoint_t) -1;
> 
>/* Use zero-context would_substitute() matching for new-spec of the 
> main
> -   * Indic scripts, and scripts with one spec only, but not for 
> old-specs. */
> -  bool zero_context = !indic_plan->is_old_spec;
> +   * Indic scripts, and scripts with one spec only, but not for 
> old-specs.
> +   * The new-spec for all dual-spec scripts says zero-context matching
> happens.
> +   *
> +   * However, testing with Malayalam shows that old and new spec both 
> allow
> +   * context.  Testing with Bengali new-spec however shows that it 
> doesn't.
> +   * So, the heuristic here is the way it is.  It should *only* be 
> changed,
> +   * as we discover more cases of what Windows does.  DON'T TOUCH 
> OTHERWISE.
> +   */
> +  bool zero_context = !indic_plan->is_old_spec && plan->props.script !=
> HB_SCRIPT_MALAYALAM;
>indic_plan->rphf.init (>map, HB_TAG('r','p','h','f'), 
> zero_context);
>indic_plan->pref.init (>map, HB_TAG('p','r','e','f'), 
> zero_context);
>indic_plan->blwf.init (>map, HB_TAG('b','l','w','f'), 
> zero_context);
> ___
> HarfBuzz mailing list
> HarfBuzz@lists.freedesktop.org 
> http://lists.freedesktop.org/mailman/listinfo/harfbuzz
> 
> 
> 
> 
> -- 
> Cheers,
> Rajeesh
> 
> 
> 
> ___
> HarfBuzz mailing list
> HarfBuzz@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/harfbuzz
> 
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Rajeesh K V]

Hi Behdad,


On Thu, Dec 17, 2015 at 6:31 PM, Behdad Esfahbod <
beh...@kemper.freedesktop.org> wrote:

>  src/hb-ot-shape-complex-indic.cc |   11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> New commits:
> commit 508cc3d3cfcfb0383df0fe795cc28db4e0fd5729
> Author: Behdad Esfahbod 
> Date:   Thu Dec 17 17:31:17 2015 +
>
> [indic] Allow context when matching for Malayalam new-spec
>
> Test sequence:
> U+0995,U+09CD,U+09B0
>

These code points are for Bengali, they don't make sense for Malayalam.
Could you share more details about this specific test case?
(I saw that subsequent commit 45b7ec365225109eb0854e6c417f48860b5f24af
fixes regression introduced by this commit, that made me curious to look
into this one).


>
> With Nirmala shipped on Windows 10, this failed to form the below form.
> Works now.
>
> Reported by Sairus.
>
> diff --git a/src/hb-ot-shape-complex-indic.cc
> b/src/hb-ot-shape-complex-indic.cc
> index 5354897..a630419 100644
> --- a/src/hb-ot-shape-complex-indic.cc
> +++ b/src/hb-ot-shape-complex-indic.cc
> @@ -557,8 +557,15 @@ data_create_indic (const hb_ot_shape_plan_t *plan)
>indic_plan->virama_glyph = (hb_codepoint_t) -1;
>
>/* Use zero-context would_substitute() matching for new-spec of the main
> -   * Indic scripts, and scripts with one spec only, but not for
> old-specs. */
> -  bool zero_context = !indic_plan->is_old_spec;
> +   * Indic scripts, and scripts with one spec only, but not for old-specs.
> +   * The new-spec for all dual-spec scripts says zero-context matching
> happens.
> +   *
> +   * However, testing with Malayalam shows that old and new spec both
> allow
> +   * context.  Testing with Bengali new-spec however shows that it
> doesn't.
> +   * So, the heuristic here is the way it is.  It should *only* be
> changed,
> +   * as we discover more cases of what Windows does.  DON'T TOUCH
> OTHERWISE.
> +   */
> +  bool zero_context = !indic_plan->is_old_spec && plan->props.script !=
> HB_SCRIPT_MALAYALAM;
>indic_plan->rphf.init (>map, HB_TAG('r','p','h','f'),
> zero_context);
>indic_plan->pref.init (>map, HB_TAG('p','r','e','f'),
> zero_context);
>indic_plan->blwf.init (>map, HB_TAG('b','l','w','f'),
> zero_context);
> ___
> HarfBuzz mailing list
> HarfBuzz@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/harfbuzz
>



-- 
Cheers,
Rajeesh
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Jonathan Kew]

On 6/11/15 07:45, Behdad Esfahbod wrote:


diff --git a/src/hb-buffer-private.hh b/src/hb-buffer-private.hh
index 721e718..8d9ae7c 100644
--- a/src/hb-buffer-private.hh
+++ b/src/hb-buffer-private.hh
@@ -35,6 +35,16 @@
  #include "hb-unicode-private.hh"


+#ifndef HB_BUFFER_MAX_EXPANSION_FACTOR
+#define HB_BUFFER_MAX_EXPANSION_FACTOR 32
+#endif
+#ifndef HB_BUFFER_MAX_LEN_MIN
+#define HB_BUFFER_MAX_LEN_MIN 8192
+#endif
+#ifndef HB_BUFFER_MAX_LEN_DEFAULT_


Oops -- there seems to be a stray underscore at the end here.


+#define HB_BUFFER_MAX_LEN_DEFAULT 0x3FFF /* Shaping more than a billion 
chars? Let us know! */
+#endif
+


___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Behdad Esfahbod]

On 15-11-06 02:17 AM, Jonathan Kew wrote:
>>
>> +#ifndef HB_BUFFER_MAX_LEN_DEFAULT_
> 
> Oops -- there seems to be a stray underscore at the end here.

Fixed.  Thanks for reviewing!

Any comments on the 'stch' code?  I wasn't sure if I should put it into a
release today or not; by the end, I was confident enough about it that decided
to push it to master.

behdad
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Behdad Esfahbod]

On 15-10-03 01:55 PM, Konstantin Ritt wrote:
> Can not one do this by defining his own malloc/../free in config.h + passing
> -DHAVE_CONFIG instead?

I thought that probably blows up inside stdlib.h...

> Regards,
> Konstantin
> 
> 2015-10-03 16:21 GMT+04:00 Behdad Esfahbod  >:
> 
>  src/hb-private.hh |   17 +
>  1 file changed, 17 insertions(+)
> 
> New commits:
> commit 52b418555b62a3b25399f202c1fa72ab7288c224
> Author: Behdad Esfahbod >
> Date:   Sat Oct 3 13:20:55 2015 +0100
> 
> Allow compiling with custom allocators
> 
> User can define hb_malloc_impl, etc, to name of custom allocator 
> functions
> that have the same signature as malloc.
> 
> diff --git a/src/hb-private.hh b/src/hb-private.hh
> index 07550cb..165cd0d 100644
> --- a/src/hb-private.hh
> +++ b/src/hb-private.hh
> @@ -54,6 +54,23 @@
>  #include 
> 
> 
> +/* Compile-time custom allocator support. */
> +
> +#if defined(hb_malloc_impl) \
> + && defined(hb_calloc_impl) \
> + && defined(hb_realloc_impl) \
> + && defined(hb_free_impl)
> +extern void* hb_malloc_impl(size_t size);
> +extern void* hb_calloc_impl(size_t nmemb, size_t size);
> +extern void* hb_realloc_impl(void *ptr, size_t size);
> +extern void  hb_free_impl(void *ptr);
> +#define malloc hb_malloc_impl
> +#define calloc hb_calloc_impl
> +#define realloc hb_realloc_impl
> +#define free hb_free_impl
> +#endif
> +
> +
>  /* Compiler attributes */
> 
> 
> ___
> HarfBuzz mailing list
> HarfBuzz@lists.freedesktop.org 
> http://lists.freedesktop.org/mailman/listinfo/harfbuzz
> 
> 
> 
> 
> ___
> HarfBuzz mailing list
> HarfBuzz@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/harfbuzz
> 
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master' - 2 commits

[Behdad Esfahbod]

On 15-01-27 09:40 AM, Jonathan Kew wrote:
 Meaning basically an API that accepts 16-bit codepoints but does not handle
 surrogate pairs, so it would in effect support UCS-2 rather than UTF-16? I
 doubt there's much of a use-case for that.

Yes, in case you or anyone has a 16bit representation for when all chars are
= 0x.  But since no one has it right now, lets forget about that.  So,
happy to keep the latin1 name I guess.

-- 
behdad
http://behdad.org/
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master' - 2 commits

[Jonathan Kew]

On 26/1/15 22:33, Behdad Esfahbod wrote:

 This is by no ways to promote non-Unicode encodings.  This is an entry
 point that takes Unicode codepoints that happen to all be the first
 256 characters and hence fit in 8bit strings.  This is useful eg in Chrome
 where strings that can fit in 8bit are implemented that way, and this
 avoids copying into UTF-8 or UTF-16.


Seems reasonable. We might well adopt hb_buffer_add_latin1() in Gecko, 
too, as we have a similar 8-bit string type for strings where all 
characters are = U+00FF. Currently, we expand those strings to UTF-16 
before calling harfbuzz; this will allow us to avoid that.



 Perhaps we should rename this to hb_buffer_add_codepoints8().  I'm also
 curious if anyone would be really interested in 
hb_buffer_add_codepoints16().


Meaning basically an API that accepts 16-bit codepoints but does not 
handle surrogate pairs, so it would in effect support UCS-2 rather than 
UTF-16? I doubt there's much of a use-case for that.


JK

___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master' - 4 commits

[Behdad Esfahbod]

On 14-12-28 09:13 PM, Werner LEMBERG wrote:
 
 Originally I wanted to change hb_ft_face_create() and
 hb_ft_font_create() to reference the face if destroy==NULL was
 passed in.  That would improve pretty much all clients, with
 little undesired effects.  Except that FreeType itself, when
 compiled with HarfBuzz support, calls hb_ft_font_create() with
 destroy==NULL and saves the resulting hb-font on the ft-face
 (why does it not free it immediately?).
 
 Looks like a buglet in FreeType

Quite possibly it's working as intended.  I just didn't expect it to be that 
way.

The point was: if hb_font is only needed during face-wise autohinter setup,
would be better to destroy the font after that.  Currently the font is stored
in AF_FaceGlobals, which means it will be kept open for the duration of the
FT_Face.  Nothing wrong with it though.

-- 
behdad
http://behdad.org/
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master' - 4 commits

[Werner LEMBERG]

 Originally I wanted to change hb_ft_face_create() and
 hb_ft_font_create() to reference the face if destroy==NULL was
 passed in.  That would improve pretty much all clients, with
 little undesired effects.  Except that FreeType itself, when
 compiled with HarfBuzz support, calls hb_ft_font_create() with
 destroy==NULL and saves the resulting hb-font on the ft-face
 (why does it not free it immediately?).

Looks like a buglet in FreeType – always remember that HarfBuzz
documentation is zero, and my experience with your baby child is too
limited to write elegant code...  If you provide a patch I'll gladly
apply it :-)


Werner
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master' - 2 commits

[Behdad Esfahbod]

Ouch.  Thanks.

On 14-06-27 05:51 PM, Jonathan Kew wrote:
 This looks like a typo?
 
 @@ -311,6 +428,7 @@ struct CmapSubtable
   case 10: return TRACE_RETURN (u.format10.sanitize (c));
   case 12: return TRACE_RETURN (u.format12.sanitize (c));
   case 13: return TRACE_RETURN (u.format13.sanitize (c));
 +case 14: return TRACE_RETURN (u.format13.sanitize (c));
   default:return TRACE_RETURN (true);
   }
 }
 
 
 JK
 
 

-- 
behdad
http://behdad.org/
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master' - 2 commits

[Jonathan Kew]

On 15/5/14 01:19, Martin Hosken wrote:

Dear Behdad,


The previous grammar for medial group was allowing an Asat after
the medial group only if there was a medial Wa or Ha, but not if
there was only a medial Ya.  This doesn't make sense to me and
sounds reversed, as both medial Wa and Ha are below marks while
Asat is an above mark.  An Asat can come before the medial group
already (in fact, multiple ones can.  Why?!).  The medial Ya
however is a spacing mark and according to Roozbeh it's valid to
want an Asat on the medial Ya instead of the base, so it looks to
me like we want to allow an Asat after the medial group if there
*was* a Ya but not if there wasn't any.  Not wanting to produce
dotted-circle where Windows is not, this commit changes the grammar
to allow one Asat after the medial group no matter what comes in
the group.


Might be worth reading UTN#11 on this. If Roozbeh has documentary
evidence of languages where the asat really does go over the
medial-ya rather than the consonant, then I would love to see it. The
reasoning behind having the asat before the medial is because asat
marks reduplication in that context in Burmese. It makes no sense to
have an asat on a medial since people don't want to kill a sequence.
Try saying a word final kw, you might be able to wrap your tongue
around it, but it doesn't fit any languages around here.


But regardless of whether it makes sense for any known orthography, 
ISTM that provided the medial is a spacing glyph, there's a clear visual 
distinction between baseasatmedial and basemedialasat. So 
allowing both does not introduce a problematic spelling ambiguity, and 
it leaves users of the script free to produce whichever of the two 
written forms they wish.


Recalling that Unicode encodes (and OpenType renders) the graphical 
elements that make up scripts, and not the linguistic content of 
particular languages, I think it's correct, in general, for the grammar 
to allow a sequence like this.


JK



The aim of UTN#11 is to come up with a consistent ordering of
diacritics that balances the need for consistency with
appropriateness of spelling. For the most part it's OK, if a little
complex. But that was because of pressure to put linguistic purity
over technical expediency.

IOW, I think the change you have made is probably a wrong move :)

Yours, Martin ___
HarfBuzz mailing list HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz .



___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Khaled Hosny]

On Tue, Nov 12, 2013 at 02:23:06PM -0800, Behdad Esfahbod wrote:
 commit 16f175cb2e081e605fe7f9cd01bbe8c24380278a
 Author: Behdad Esfahbod beh...@behdad.org
 Date:   Tue Nov 12 17:22:49 2013 -0500
 
 Fix scratch-buffer alignment warnings

This broke Uniscribe shaper for me, I’m getting an assertion now:

Assertion failed: _consumed = scratch_size, file ../../src/hb-uniscribe.cc, 
line 791
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Behdad Esfahbod]

On 13-12-23 06:29 AM, Khaled Hosny wrote:
 On Tue, Nov 12, 2013 at 02:23:06PM -0800, Behdad Esfahbod wrote:
 commit 16f175cb2e081e605fe7f9cd01bbe8c24380278a
 Author: Behdad Esfahbod beh...@behdad.org
 Date:   Tue Nov 12 17:22:49 2013 -0500

 Fix scratch-buffer alignment warnings
 
 This broke Uniscribe shaper for me, I’m getting an assertion now:
 
 Assertion failed: _consumed = scratch_size, file ../../src/hb-uniscribe.cc, 
 line 791

Ouch, with any input, or can you pass me the font / text combo?  Will fix
tomorrow.

-- 
behdad
http://behdad.org/
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Khaled Hosny]

On Mon, Dec 23, 2013 at 07:33:26AM -0500, Behdad Esfahbod wrote:
 On 13-12-23 06:29 AM, Khaled Hosny wrote:
  On Tue, Nov 12, 2013 at 02:23:06PM -0800, Behdad Esfahbod wrote:
  commit 16f175cb2e081e605fe7f9cd01bbe8c24380278a
  Author: Behdad Esfahbod beh...@behdad.org
  Date:   Tue Nov 12 17:22:49 2013 -0500
 
  Fix scratch-buffer alignment warnings
  
  This broke Uniscribe shaper for me, I’m getting an assertion now:
  
  Assertion failed: _consumed = scratch_size, file 
  ../../src/hb-uniscribe.cc, line 791
 
 Ouch, with any input, or can you pass me the font / text combo?  Will fix
 tomorrow.

With any input.

Regards,
Khaled
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Behdad Esfahbod]

On 13-12-23 08:22 AM, Khaled Hosny wrote:
 On Mon, Dec 23, 2013 at 07:33:26AM -0500, Behdad Esfahbod wrote:
 On 13-12-23 06:29 AM, Khaled Hosny wrote:
 On Tue, Nov 12, 2013 at 02:23:06PM -0800, Behdad Esfahbod wrote:
 commit 16f175cb2e081e605fe7f9cd01bbe8c24380278a
 Author: Behdad Esfahbod beh...@behdad.org
 Date:   Tue Nov 12 17:22:49 2013 -0500

 Fix scratch-buffer alignment warnings

 This broke Uniscribe shaper for me, I’m getting an assertion now:

 Assertion failed: _consumed = scratch_size, file 
 ../../src/hb-uniscribe.cc, line 791

 Ouch, with any input, or can you pass me the font / text combo?  Will fix
 tomorrow.
 
 With any input.

Fixed.  Thanks.  I'm really surprised that I didn't test it when changing.

behdad
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master' - 3 commits

[Jonathan Kew]

On 22/12/13 21:21, Behdad Esfahbod wrote:


+   if (!(frac_mask | numr_mask | dnom_mask))
+ return;


Maybe it would be better to require *both* numr and dnom to be present 
if they're to be used. Something more like


  if (!frac_mask  (!numr_mask  !dnom_mask))
return;

perhaps?

JK

___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master' - 3 commits

[Behdad Esfahbod]

On 13-12-22 04:43 PM, Jonathan Kew wrote:
 On 22/12/13 21:21, Behdad Esfahbod wrote:
 
 +if (!(frac_mask | numr_mask | dnom_mask))
 +  return;
 
 Maybe it would be better to require *both* numr and dnom to be present if
 they're to be used. Something more like
 
   if (!frac_mask  (!numr_mask  !dnom_mask))
 return;
 
 perhaps?

Yes, I was actually thinking about doing that.  And caching the result of
these on the plan so it's quicker to reject fonts that don't have any of
these.  Working on these.

-- 
behdad
http://behdad.org/
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master' - 5 commits

[Behdad Esfahbod]

On 13-09-02 06:41 AM, Khaled Hosny wrote:
 On Fri, Aug 09, 2013 at 06:42:20AM -0700, Behdad Esfahbod wrote:
 commit 10f964623f003c70f6bdd33423420abda3820ce0
 Author: Behdad Esfahbod beh...@behdad.org
 Date:   Fri Aug 9 09:40:01 2013 -0400

 Round when scaling values
 
 Doesn't matter for most users since they should be working in a
 fixed sub-pixel scale anyway (ie. 22.10, 26.6, 16.16, etc).
 
 With this commit, I’m seeing one pixel differences in my test suit,
 things like (with Amiri):
 
 expected:  
 [uni06DD+2620|one.small@-2210,0+0|two.small@-1610,0+0|three.small@-1010,0+0]
 result:
 [uni06DD+2620|one.small@-2209,0+1|two.small@-1609,0+1|three.small@-1009,0+1]
 
 Looks harmless, but wanted to double check before updating the expected
 output.

Are you shaping at upem size?  If yes, then the change may be a bug.  I don't
have sortsmill so can't test.  If Uniscribe returns the old value then this is
definitely a bug.  Feel free to suggest a patch.  Or we can just revert.

BTW, is Amiri still on SF, or github?  If it's on github, may be a good idea
to set it up on travis-ci.org, then add a hook from harfbuzz github to trigger
amiri tests on travis, and send failure reports to harfbuzz list.

Same about any other font projects that test against harfbuzz BTW!

 Regards,
 Khaled
 

-- 
behdad
http://behdad.org/
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master' - 5 commits

[Khaled Hosny]

On Tue, Sep 03, 2013 at 04:21:12PM -0400, Behdad Esfahbod wrote:
 Are you shaping at upem size?

That is just the output of hb-shape, so I guess yes.

 If Uniscribe returns the old value then this is definitely a bug.

Seems so:

  $ cat test | hb-shape.exe amiri-regular.ttf --shapers=uniscribe
  
[uni06DD=0+2620|one.small=1@-2210,0+0|two.small=2@-1610,0+0|three.small=3@-1010,0+0]

  $ cat test | hb-shape.exe amiri-regular.ttf --shapers=ot
  
[uni06DD=0+2620|one.small=1@-2209,0+1|two.small=2@-1609,0+1|three.small=3@-1009,0+1]

 Feel free to suggest a patch.  Or we can just revert.

I’m not sure I understand the math behind that commit, so I can’t
suggest a fix.

 BTW, is Amiri still on SF, or github?  If it's on github, may be a good idea
 to set it up on travis-ci.org, then add a hook from harfbuzz github to trigger
 amiri tests on travis, and send failure reports to harfbuzz list.

There is a github mirror, that would be nice if it can be done, but I
need to check how to setup travis.

Regards,
Khaled
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master' - 5 commits

[Khaled Hosny]

On Tue, Sep 03, 2013 at 06:16:37PM -0400, Behdad Esfahbod wrote:
 On 13-09-03 06:08 PM, Khaled Hosny wrote:
  On Tue, Sep 03, 2013 at 04:21:12PM -0400, Behdad Esfahbod wrote:
  Are you shaping at upem size?
  
  That is just the output of hb-shape, so I guess yes.
  
  If Uniscribe returns the old value then this is definitely a bug.
  
  Seems so:
  
$ cat test | hb-shape.exe amiri-regular.ttf --shapers=uniscribe

  [uni06DD=0+2620|one.small=1@-2210,0+0|two.small=2@-1610,0+0|three.small=3@-1010,0+0]
  
$ cat test | hb-shape.exe amiri-regular.ttf --shapers=ot

  [uni06DD=0+2620|one.small=1@-2209,0+1|two.small=2@-1609,0+1|three.small=3@-1009,0+1]
  
  Feel free to suggest a patch.  Or we can just revert.
  
  I’m not sure I understand the math behind that commit, so I can’t
  suggest a fix.
 
 It's simply adding .5, supposedly to get round instead of floor behavior.  I
 probably screwed up.  Will check.

I figured that out, but it looked like it was subtracting .5 for me,
which was puzzling. I guess I know why now, the affected values are
negative, so it ends up with something like:

  (-2210.0 * 2048 + 1024) / 2048

which is -2209.5, not -2210.5 as probably expected.

Regards,
Khaled
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master' - 5 commits

[Behdad Esfahbod]

On 13-03-24 08:28 AM, Khaled Hosny wrote:
 On Tue, Feb 12, 2013 at 06:49:01AM -0800, Behdad Esfahbod wrote:
 commit 568000274c8edb5f41bc4f876ce21fcc8bdaeed8
 Author: Behdad Esfahbod beh...@behdad.org
 Date:   Tue Feb 12 09:44:57 2013 -0500

 Adjust mark advance-width zeroing logic for Myanmar
 
 Before, we were zeroing advance width of attached marks for
 non-Indic scripts, and not doing it for Indic.
 
 We have now three different behaviors, which seem to better
 reflect what Uniscribe is doing:
 
   - For Indic, no explicit zeroing happens whatsoever, which
 is the same as before,
 
   - For Myanmar, zero advance width of glyphs marked as marks
 *in GDEF*, and do that *before* applying GPOS.  This seems
 to be what the new Win8 Myanmar shaper does,
 
   - For everything else, zero advance width of glyphs that are
 from General_Category=Mn Unicode characters, and do so
 before applying GPOS.  This seems to be what Uniscribe does
 for Latin at least.
 
 With these changes, positioning of all tests matches for Myanmar,
 except for the glitch in Uniscribe not applying 'mark'.  See preivous
 commit.
 
 This commit is causing a regression with Amiri, the string “هَٰذ” with
 Uniscribe and HarfBuzz before this commit, gives:
 
   
 [uni0630.fina=3+965|uni0670.medi=0+600|uni064E=0@-256,0+0|uni0647.init=0+926]
 
 But now it gives:
 
   
 [uni0630.fina=3+965|uni0670.medi=0+0|uni064E=0@-256,0+0|uni0647.init=0+926]
 
 i.e. uni0670.medi is zeroed though it has a base glyph GDEF class.

Ugh.  I'm looking into this.  Will hopefully get it resolved today.


 Regards,
 Khaled
 

-- 
behdad
http://behdad.org/
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master' - 5 commits

[Khaled Hosny]

On Tue, Feb 12, 2013 at 06:49:01AM -0800, Behdad Esfahbod wrote:
 commit 568000274c8edb5f41bc4f876ce21fcc8bdaeed8
 Author: Behdad Esfahbod beh...@behdad.org
 Date:   Tue Feb 12 09:44:57 2013 -0500
 
 Adjust mark advance-width zeroing logic for Myanmar
 
 Before, we were zeroing advance width of attached marks for
 non-Indic scripts, and not doing it for Indic.
 
 We have now three different behaviors, which seem to better
 reflect what Uniscribe is doing:
 
   - For Indic, no explicit zeroing happens whatsoever, which
 is the same as before,
 
   - For Myanmar, zero advance width of glyphs marked as marks
 *in GDEF*, and do that *before* applying GPOS.  This seems
 to be what the new Win8 Myanmar shaper does,
 
   - For everything else, zero advance width of glyphs that are
 from General_Category=Mn Unicode characters, and do so
 before applying GPOS.  This seems to be what Uniscribe does
 for Latin at least.
 
 With these changes, positioning of all tests matches for Myanmar,
 except for the glitch in Uniscribe not applying 'mark'.  See preivous
 commit.

This commit is causing a regression with Amiri, the string “هَٰذ” with
Uniscribe and HarfBuzz before this commit, gives:


[uni0630.fina=3+965|uni0670.medi=0+600|uni064E=0@-256,0+0|uni0647.init=0+926]

But now it gives:


[uni0630.fina=3+965|uni0670.medi=0+0|uni064E=0@-256,0+0|uni0647.init=0+926]

i.e. uni0670.medi is zeroed though it has a base glyph GDEF class.

Regards,
Khaled
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Khaled Hosny]

On Thu, Jan 31, 2013 at 03:18:35PM -0800, Behdad Esfahbod wrote:

 --- a/util/options.cc
 +++ b/util/options.cc
 @@ -414,7 +414,7 @@ font_options_t::get_font (void) const
GString *gs = g_string_new (NULL);
char buf[BUFSIZ];
  #ifdef HAVE__SETMODE
 -  _setmode (fileno (stdin), _O_BINARY);
 +  setmode (fileno (stdin), _O_BINARY);
  #endif

Shouldn’t this be HAVE_SETMODE now?

Regards,
Khaled
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Behdad Esfahbod]

On 13-01-31 06:33 PM, Khaled Hosny wrote:
 On Thu, Jan 31, 2013 at 03:18:35PM -0800, Behdad Esfahbod wrote:

 --- a/util/options.cc
 +++ b/util/options.cc
 @@ -414,7 +414,7 @@ font_options_t::get_font (void) const
GString *gs = g_string_new (NULL);
char buf[BUFSIZ];
  #ifdef HAVE__SETMODE
 -  _setmode (fileno (stdin), _O_BINARY);
 +  setmode (fileno (stdin), _O_BINARY);
  #endif
 
 Shouldn’t this be HAVE_SETMODE now?

Oops.  Thanks for the catch!

 Regards,
 Khaled
 

-- 
behdad
http://behdad.org/
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master' - 2 commits

[Behdad Esfahbod]

On 12-12-24 12:59 AM, Pravin Satpute wrote:
 
 Reordering is still not happening. Am i missing anything?
 ./hb-shape /usr/share/fonts/lohit-malayalam/Lohit-Malayalam.ttf ൎക
 [uni0D4E=0|U0D15=1+1015]

Really?  This is what I get with Lohit-Malayalam 2.5.2:

$ ./hb-unicode-encode d4e,d15 | build/util/hb-shape
indic-fonts-lohit/malayalam.ttf
[U0D15=0+1015|uni0D4E=0@-971,-41+0]


-- 
behdad
http://behdad.org/
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master' - 2 commits

[Pravin Satpute]

On ?? 23 ??? 2012 10:08 ?.??., Rajeesh K Nambiar wrote:

 On Sun, Dec 23, 2012 at 7:25 AM, Behdad Esfahbod beh...@behdad.org
 mailto:beh...@behdad.org wrote:

 On 12-12-22 09:08 AM, Rajeesh K Nambiar wrote:
  commit 8b217f5ac54aa0dcbba2dd6d59aa89dde33e56c2
  Author: Behdad Esfahbod beh...@behdad.org
 mailto:beh...@behdad.org
  Date:   Fri Dec 21 15:48:32 2012 -0500
 
  [Indic] Reorder Malayalam dot-reph to after base
 
  Test sequence is simple: U+0D4E,U+0D15.  The doth-reph
 should be
  reordered to after the Ka.
 
  https://bugzilla.redhat.com/show_bug.cgi?id=799565
 
  This seems to have regressed test case 2 (???) under
 
 
 test/shaping/texts/in-tree/shaper-indic/indic/script-malayalam/misc/misc.txt

 With *what* font?!


 With Meera, Rachana as well as Lohit.

1. Rachana does not have U+0D4E character
2. For Meera  Lohit rendering same as it was before this commit

  


  with rendering of sub-base Va being incorrect on ??? (Va+Virama+Va).

 Works as expected with Kartika for me.

Same for lohit, meera and rachana as well.


  Rendering dot reph with Rachana font also regressed, but I guess
 that
  is due to the font implementation - Santhosh Thottingal would be
 able
  to clarify.

 Right.  I don't mind limiting this reordering to the 'mlm2' fonts,
 which would
 unbreak Rachana.  Jonathan, what do you think?  This is reordering
 that was
 introduced only in Windows 8, for a character introduced in
 Unicode 6.0.


If its break something in that case we can limit. Since it is just
introduced in 6.0 most of the fonts are still adopting it. So if we
handle it properly font developers can change accordingly.

Since presently reordering of U+0D4E is not happening, For Meera
upstream has added around 50 ligature for single u+0d4e character. If we
can allow it for mlym and mlm2 Meera can get rid of these 50 ligatures.

Reordering is still not happening. Am i missing anything?
./hb-shape /usr/share/fonts/lohit-malayalam/Lohit-Malayalam.ttf ??
[uni0D4E=0|U0D15=1+1015]


Thanks  Regards,
Pravin Satpute
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master' - 2 commits

[Rajeesh K Nambiar]

On Sun, Dec 23, 2012 at 7:25 AM, Behdad Esfahbod beh...@behdad.org wrote:

 On 12-12-22 09:08 AM, Rajeesh K Nambiar wrote:
  commit 8b217f5ac54aa0dcbba2dd6d59aa89dde33e56c2
  Author: Behdad Esfahbod beh...@behdad.org
  Date:   Fri Dec 21 15:48:32 2012 -0500
 
  [Indic] Reorder Malayalam dot-reph to after base
 
  Test sequence is simple: U+0D4E,U+0D15.  The doth-reph should be
  reordered to after the Ka.
 
  https://bugzilla.redhat.com/show_bug.cgi?id=799565
 
  This seems to have regressed test case 2 (അഥൎവ്വം) under
 
 test/shaping/texts/in-tree/shaper-indic/indic/script-malayalam/misc/misc.txt

 With *what* font?!


With Meera, Rachana as well as Lohit.



  with rendering of sub-base Va being incorrect on വ്വ (Va+Virama+Va).

 Works as expected with Kartika for me.

  Rendering dot reph with Rachana font also regressed, but I guess that
  is due to the font implementation - Santhosh Thottingal would be able
  to clarify.

 Right.  I don't mind limiting this reordering to the 'mlm2' fonts, which
 would
 unbreak Rachana.  Jonathan, what do you think?  This is reordering that was
 introduced only in Windows 8, for a character introduced in Unicode 6.0.

 --
 behdad
 http://behdad.org/




-- 
Cheers,
Rajeesh
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master' - 6 commits

[Behdad Esfahbod]

On 12-12-12 09:00 PM, Khaled Hosny wrote:
 On Wed, Dec 12, 2012 at 08:39:26AM -0800, Behdad Esfahbod wrote:
 We still don't look for the old incorrect place of the featureParams.
 I'll wait till someone actually complains about it...
 
 Actually the first font I tested was an old-AFDKO broken one, so I’m
 already complaining :)

I see.  Send font my way please.

b
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master' - 6 commits

[Khaled Hosny]

On Wed, Dec 12, 2012 at 08:39:26AM -0800, Behdad Esfahbod wrote:
 We still don't look for the old incorrect place of the featureParams.
 I'll wait till someone actually complains about it...

Actually the first font I tested was an old-AFDKO broken one, so I’m
already complaining :)

Regards,
Khaled
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Behdad Esfahbod]

On 12-12-10 10:14 AM, Jiang Jiang wrote:
 On Mon, Dec 10, 2012 at 6:58 AM, Behdad Esfahbod
 beh...@kemper.freedesktop.org wrote:
 commit 071d5b831e6de5f3b24160dc77b139cb040ab886
 Author: Behdad Esfahbod beh...@behdad.org
 Date:   Mon Dec 10 00:57:00 2012 -0500

 Work around missing OSAtomicCompareAndSwapPtrBarrier() on OS X 10.4

 Not sure how to handle iOS.
 
 There is Availability.h available on OS X 10.6 and iOS for checking
 __IPHONE_OS_VERSION_MAX_ALLOWED and so on.

Thanks.  From reading the headers themselves, my understanding was that
Availability.h is for system headers to include only, and not to be used by
client code.  So, what would a ifdef block look like?  IIUC, I have to figure
out first whether Availability.h itself can be included...  Also, does iOS
define __APPLE__ also?

I think I'll wait till someone who has a iOS SDK set up to send me a patch.

behdad
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Kenichi Ishibashi]

Hi Behdad,

Thank you for the change, but it seems that we need to do it for
hb_apply_context_t(), not hb_would_apply_context_t() to fix the crash :)



On Tue, Sep 4, 2012 at 9:19 AM, Behdad Esfahbod 
beh...@kemper.freedesktop.org wrote:

  src/hb-ot-layout-gsubgpos-private.hh |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 New commits:
 commit f8fa2b5cf67b02d74514dec7885d03de73ec7349
 Author: Behdad Esfahbod beh...@behdad.org
 Date:   Mon Sep 3 20:19:46 2012 -0400

 Fix possible NULL dereference

 As reported by Kenichi Ishibashi.

 diff --git a/src/hb-ot-layout-gsubgpos-private.hh
 b/src/hb-ot-layout-gsubgpos-private.hh
 index 00bc563..40d5c57 100644
 --- a/src/hb-ot-layout-gsubgpos-private.hh
 +++ b/src/hb-ot-layout-gsubgpos-private.hh
 @@ -92,7 +92,7 @@ struct hb_would_apply_context_t
   glyphs (glyphs_),
   len (len_),
   zero_context (zero_context_),
 - digest (*digest_),
 + digest (digest_ ? *digest_ :
 hb_set_digest_t()),
   debug_depth (0) {};
  };

 ___
 HarfBuzz mailing list
 HarfBuzz@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/harfbuzz

___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Behdad Esfahbod]

Ah, my bad.  It really bothers me that GCC doesn't crash on it.  So I
reorganized code to make sure the same mistake won't happen again.  I'm
planning on removing the code in Arabic shape fallback soon though.

behdad

On 09/04/2012 02:31 AM, Kenichi Ishibashi wrote:
 Hi Behdad,
 
 Thank you for the change, but it seems that we need to do it for
 hb_apply_context_t(), not hb_would_apply_context_t() to fix the crash :)
 
 
 
 On Tue, Sep 4, 2012 at 9:19 AM, Behdad Esfahbod beh...@kemper.freedesktop.org
 mailto:beh...@kemper.freedesktop.org wrote:
 
  src/hb-ot-layout-gsubgpos-private.hh |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 New commits:
 commit f8fa2b5cf67b02d74514dec7885d03de73ec7349
 Author: Behdad Esfahbod beh...@behdad.org mailto:beh...@behdad.org
 Date:   Mon Sep 3 20:19:46 2012 -0400
 
 Fix possible NULL dereference
 
 As reported by Kenichi Ishibashi.
 
 diff --git a/src/hb-ot-layout-gsubgpos-private.hh
 b/src/hb-ot-layout-gsubgpos-private.hh
 index 00bc563..40d5c57 100644
 --- a/src/hb-ot-layout-gsubgpos-private.hh
 +++ b/src/hb-ot-layout-gsubgpos-private.hh
 @@ -92,7 +92,7 @@ struct hb_would_apply_context_t
   glyphs (glyphs_),
   len (len_),
   zero_context (zero_context_),
 - digest (*digest_),
 + digest (digest_ ? *digest_ : 
 hb_set_digest_t()),
   debug_depth (0) {};
  };
 
 ___
 HarfBuzz mailing list
 HarfBuzz@lists.freedesktop.org mailto:HarfBuzz@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/harfbuzz
 
 
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Tom Hacohen]

Thanks for the commit, have been waiting for this one.

As for the first issue: there's only so much you can do to workaround 
broken fonts.


--
Tom.

On 02/09/12 03:40, Behdad Esfahbod wrote:

  src/hb-ot-shape.cc |   32 
  1 file changed, 32 insertions(+)

New commits:
commit 6912e476dd92639c3ddf07ca51c8d4a262c8b3a5
Author: Behdad Esfahbod beh...@behdad.org
Date:   Sat Sep 1 20:38:45 2012 -0400

 [OT] Insert dotted-circle for run-initial marks

 Unfortunately if the font has GPOS and 'mark' feature does
 not position mark on dotted-circle, our inserted dotted-circle
 will not get the mark repositioned to itself.  Uniscribe cheats
 here.

 If there is no GPOS however, the fallback positioning kicks in
 and sorts this out.

 I'm not willing to address the first case.

diff --git a/src/hb-ot-shape.cc b/src/hb-ot-shape.cc
index 26b21ce..a19c8b2 100644
--- a/src/hb-ot-shape.cc
+++ b/src/hb-ot-shape.cc
@@ -235,6 +235,37 @@ hb_set_unicode_props (hb_buffer_t *buffer)
  }

  static void
+hb_insert_dotted_circle (hb_buffer_t *buffer, hb_font_t *font)
+{
+  /* TODO One day, when we keep _before_ text for the buffer, take
+   * that into consideration.  For now, insert dotted-circle if the
+   * very first character is a non-spacing mark. */
+  if (_hb_glyph_info_get_general_category (buffer-info[0]) !=
+  HB_UNICODE_GENERAL_CATEGORY_NON_SPACING_MARK)
+return;
+
+  hb_codepoint_t dottedcircle_glyph;
+  if (!font-get_glyph (0x25CC, 0, dottedcircle_glyph))
+return;
+
+  hb_glyph_info_t dottedcircle;
+  dottedcircle.codepoint = 0x25CC;
+  _hb_glyph_info_set_unicode_props (dottedcircle, buffer-unicode);
+
+  buffer-clear_output ();
+
+  buffer-idx = 0;
+  hb_glyph_info_t info = dottedcircle;
+  info.cluster = buffer-cur().cluster;
+  info.mask = buffer-cur().mask;
+  buffer-output_info (info);
+  while (buffer-idx  buffer-len)
+buffer-next_glyph ();
+
+  buffer-swap_buffers ();
+}
+
+static void
  hb_form_clusters (hb_buffer_t *buffer)
  {
unsigned int count = buffer-len;
@@ -526,6 +557,7 @@ hb_ot_shape_internal (hb_ot_shape_context_t *c)
c-buffer-clear_output ();

hb_set_unicode_props (c-buffer);
+  hb_insert_dotted_circle (c-buffer, c-font);
hb_form_clusters (c-buffer);

hb_ensure_native_direction (c-buffer);
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz



___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Khaled Hosny]

On Thu, Aug 16, 2012 at 05:11:37AM -0700, Behdad Esfahbod wrote:
  configure.ac |   21 +
  1 file changed, 1 insertion(+), 20 deletions(-)
 
 New commits:
 commit b161bfc4f6f2db0edea780b95b798ff7b559cf33
 Author: Behdad Esfahbod beh...@behdad.org
 Date:   Thu Aug 16 08:09:44 2012 -0400
 
 [configure] Cleanup check for ICU
 
 Check for upstream-provided 'icu-uc' pkgconfig package.

Ubuntu does not ship pkconfig files for icu, so I can't build with icu
support anymore.

Regards,
 Khaled
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Behdad Esfahbod]

On 08/16/2012 09:25 AM, Khaled Hosny wrote:
 On Thu, Aug 16, 2012 at 05:11:37AM -0700, Behdad Esfahbod wrote:
  configure.ac |   21 +
  1 file changed, 1 insertion(+), 20 deletions(-)

 New commits:
 commit b161bfc4f6f2db0edea780b95b798ff7b559cf33
 Author: Behdad Esfahbod beh...@behdad.org
 Date:   Thu Aug 16 08:09:44 2012 -0400

 [configure] Cleanup check for ICU
 
 Check for upstream-provided 'icu-uc' pkgconfig package.
 
 Ubuntu does not ship pkconfig files for icu, so I can't build with icu
 support anymore.

How old of an Ubuntu?  I don't have it on my ancient Lucid either, but decided
that Lucid is not interesting.

I can add back the old logic.  But it sucks having to do that...  Is there a
bug filed with Ubuntu?

b


 Regards,
  Khaled
 
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Khaled Hosny]

On Thu, Aug 16, 2012 at 09:27:30AM -0400, Behdad Esfahbod wrote:
 On 08/16/2012 09:25 AM, Khaled Hosny wrote:
  On Thu, Aug 16, 2012 at 05:11:37AM -0700, Behdad Esfahbod wrote:
   configure.ac |   21 +
   1 file changed, 1 insertion(+), 20 deletions(-)
 
  New commits:
  commit b161bfc4f6f2db0edea780b95b798ff7b559cf33
  Author: Behdad Esfahbod beh...@behdad.org
  Date:   Thu Aug 16 08:09:44 2012 -0400
 
  [configure] Cleanup check for ICU
  
  Check for upstream-provided 'icu-uc' pkgconfig package.
  
  Ubuntu does not ship pkconfig files for icu, so I can't build with icu
  support anymore.
 
 How old of an Ubuntu?  I don't have it on my ancient Lucid either, but decided
 that Lucid is not interesting.

12.04, the latest :)

 I can add back the old logic.  But it sucks having to do that...  Is there a
 bug filed with Ubuntu?

I didn't find any (nor against Debian package), I guess I'll submit one.

Regards,
 Khaled
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Khaled Hosny]

On Thu, Aug 16, 2012 at 03:54:06PM +0200, Khaled Hosny wrote:
 
 I didn't find any (nor against Debian package), I guess I'll submit one.

https://bugs.launchpad.net/ubuntu/+source/icu/+bug/1037588

Regards,
 Khaled
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master' - 2 commits

[Lars Knoll]

On Wednesday 28 October 2009 05:51:16 am Behdad Esfahbod wrote:
  contrib/harfbuzz-unicode.c |   27 ---
  src/harfbuzz-hebrew.c  |3 ++-
  2 files changed, 26 insertions(+), 4 deletions(-)
 
 New commits:
 commit b90ffbace5536786eafe23e28ec3eee74c7c4e27
 Author: Adam Langley a...@chromium.org
 Date:   Tue Oct 27 16:13:20 2009 -0700
 
 Initialize Hebrew shaper_item even when HB_SelectScript fails
 

This commit unfortunately made it into Qt 4.6 and causes crashes in 
applications.

See http://bugreports.qt.nokia.com/browse/QTBUG-6436

You can not call HB_HeuristicSetGlyphAttributes, before calling 
HB_ConvertStringToGlyphIndices.

Can you please provide a test case of what this submit was meant to fix?

Lars


 diff --git a/src/harfbuzz-hebrew.c b/src/harfbuzz-hebrew.c
 index 533a063..2bda386 100644
 --- a/src/harfbuzz-hebrew.c
 +++ b/src/harfbuzz-hebrew.c
 @@ -56,6 +56,8 @@ HB_Bool HB_HebrewShape(HB_ShaperItem *shaper_item)
 
  assert(shaper_item-item.script == HB_Script_Hebrew);
 
 +HB_HeuristicSetGlyphAttributes(shaper_item);
 +
  #ifndef NO_OPENTYPE
  if (HB_SelectScript(shaper_item, hebrew_features)) {
 
 @@ -64,7 +66,6 @@ HB_Bool HB_HebrewShape(HB_ShaperItem *shaper_item)
  return FALSE;
 
 
 -HB_HeuristicSetGlyphAttributes(shaper_item);
  HB_OpenTypeShape(shaper_item, /*properties*/0);
  return HB_OpenTypePosition(shaper_item, availableGlyphs,
  /*doLogClusters*/TRUE); }
 commit 620f1d90a7c7207492ff3eabf0f6185e8b78f9dc
 Author: Adam Langley a...@chromium.org
 Date:   Tue Oct 27 16:08:38 2009 -0700
 
 Implement HB_GetMirroredChar under contrib/
 
 diff --git a/contrib/harfbuzz-unicode.c b/contrib/harfbuzz-unicode.c
 index 9b3c43e..51dd4ea 100644
 --- a/contrib/harfbuzz-unicode.c
 +++ b/contrib/harfbuzz-unicode.c
 @@ -6,8 +6,9 @@
  #include harfbuzz-shaper.h
  #include harfbuzz-unicode.h
 
 -#include tables/script-properties.h
  #include tables/grapheme-break-properties.h
 +#include tables/mirroring-properties.h
 +#include tables/script-properties.h
 
  uint32_t
  utf16_to_code_point(const uint16_t *chars, size_t len, ssize_t *iter) {
 @@ -234,10 +235,30 @@ HB_GetGraphemeAndLineBreakClass(HB_UChar32 ch,
  HB_GraphemeClass *gclass, HB_Line *breakclass = HB_GetLineBreakClass(ch);
  }
 
 +static int
 +mirroring_property_cmp(const void *vkey, const void *vcandidate) {
 +  const uint32_t key = (uint32_t) (intptr_t) vkey;
 +  const struct mirroring_property *candidate = vcandidate;
 +
 +  if (key  candidate-a) {
 +return -1;
 +  } else if (key  candidate-a) {
 +return 1;
 +  } else {
 +return 0;
 +  }
 +}
 +
  HB_UChar16
  HB_GetMirroredChar(HB_UChar16 ch) {
 -  abort();
 -  return 0;
 +  const void *mprop = bsearch((void *) (intptr_t) ch,
  mirroring_properties, + 
  mirroring_properties_count,
 +  sizeof(struct mirroring_property),
 +  mirroring_property_cmp);
 +  if (!mprop)
 +return ch;
 +
 +  return ((const struct mirroring_property *) mprop)-b;
  }
 
  void *
 ___
 HarfBuzz mailing list
 HarfBuzz@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/harfbuzz
 
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz