Can we have buffer messaging?

[simoncozens]

Any reason why not? Would help me to have trace functions in harfbuzzjs.

diff --git a/src/hb-config.hh b/src/hb-config.hh
index fc8d424..1e57ec6 100644
--- a/src/hb-config.hh
+++ b/src/hb-config.hh
@@ -53,7 +53,6 @@
 #define HB_DISABLE_DEPRECATED
 #define HB_NDEBUG
 #define HB_NO_ATEXIT
-#define HB_NO_BUFFER_MESSAGE
 #define HB_NO_BUFFER_SERIALIZE
 #define HB_NO_BITMAP
 #define HB_NO_CFF

[ebraminio]

you can just override it easily like https://github.com/harfbuzz/harfbuzzjs/blob/0ef0227/raqm.js/config-override.h in https://github.com/harfbuzz/harfbuzzjs/blob/0ef0227/raqm.js/build.sh#L51

[simoncozens]

Oh nice. I'm still working on how to get JS callbacks working from C - emscripten docs say "use addFunction" but I can't see how to get that function.

[ebraminio]

Oh, that isn't straightforward, you can of course use emscripten itself but I like to keep more clients on harfbuzzjs, callbacks should be provided as environment variable, what I suggest instead is to provide a C helper like this https://github.com/harfbuzz/harfbuzzjs/blob/0ef0227/hbjs.c#L110 get its address like this https://github.com/harfbuzz/harfbuzzjs/blob/c2b6703/libc/malloc.cc#L29 and oh of course we don't have vsnprintf implementation yet used in message buffer, I can work on this, you can also if you feel the value on current harfbuzzjs implementation like I am (size reduction, knowing how exactly thing works, pure and portable wasm), but you can also use emscripten version of harfbuzzjs https://github.com/harfbuzz/harfbuzzjs/commit/c23e767f3d3bbe9bf495be03aedeb6cf4ae6ae35 like what is done on https://alif-type.github.io/rana-kufi/

[simoncozens]

OK, sounds like the simplest way is to write a C function hbjs_shape_with_trace which takes a buffer and fills it with the tracing output, and expose that like you did with the hbjs_glyph_svg.

[ebraminio]

moved to harfbuzzjs repo, exactly, better than what I was thinking, thank you very much

[simoncozens]

OK, I know what I'm doing now! I've got vsnprintf, and a few other string functions, which also means I can parse features.

[ebraminio]

Let me know if anything needed, it should be not easy but possible to mimic, we have different things around like a simple itoa implementation.

[simoncozens]

Think I've got everything - do you want any PRs for what I'm doing? (Feature handling, etc.?)

[ebraminio]

Sure! Sharing it with others would be excellent, I gave you write permission [if you didn't have already] also so upload a PR or push directly anyway. Thanks!

[ebraminio]

Hey there, just am curious to know what has happened, thanks

[simoncozens]

I don't tend to work much on Sundays. :-)

I've got some changes from yesterday; I brought in glyph_to_svg, added sprintf and friends, and added tracing. Because I had sprintf/etc. I could also add feature parsing. But I've only added that to shape_with_trace so far, need to clean it up and add it to shape. I still need buffer serialization. When I've got it cleaned up and working I will push a separate branch.

[ebraminio]

Ooh, this sounds interesting! I just was worried something bothered you and you were in approach rethinking, let me know if any help is needed

[simoncozens]

Have a look in "tracing" branch. It's looking really nice:

$ node examples/tracing.node.js
[
  { g: 80, cl: 0, ax: 486, ay: 0, dx: 0, dy: 0 },
  { g: 234, cl: 1, ax: 558, ay: 0, dx: 0, dy: 0 }
]
[
  { m: 'start table GSUB', t: [ [Object], [Object], [Object] ] },
  { m: 'start lookup 24', t: [ [Object], [Object], [Object] ] },
  { m: 'end lookup 24', t: [ [Object], [Object] ] },
  { m: 'end table GSUB', t: [ [Object], [Object] ] },
  { m: 'start table GPOS', t: [ [Object], [Object] ] },
  { m: 'start lookup 1', t: [ [Object], [Object] ] },
  { m: 'end lookup 1', t: [ [Object], [Object] ] },
  { m: 'end table GPOS', t: [ [Object], [Object] ] }
]

[ebraminio]

wow, niiiiiiiice :)