Build with Graphite Support

[mimbrown]

I'm looking into what it would take to use this library with Graphite support enabled. I'm assuming this includes at least:

1. Adding the -DHave_Graphite2 flag to build.sh.
2. Adding the Graphite source files... somewhere.

If this is easy to do, can someone point me in the right direction? Also, this is purely shaping, correct? I'm assuming there is no bidi support or line-breaking.

[behdad]

All correct.

I don't think anyone built this with Graphite before, but that would be interesting indeed. @mhosken

[mimbrown]

It would nicely bypass the whole Firefox vs Chrome thing if developers had the option to bundle a small rendering engine with a web app. But I'm out of my depth here, I've never actually done anything with Wasm.

[ebraminio]

If this is easy to do, can someone point me in the right direction?

graphite uses C++'s STL so probably you better go with emscripten, have a look at https://github.com/emscripten-core/emscripten/blob/main/tools/ports/harfbuzz.py which I happened to add there in 2018, probably you can add a graphite2 one also right there even.

For bidi we have fribidi and a freetype-free libraqm port right in this repo but I'd say doing it with emscripten would be even easier to do.

[ebraminio]

All you need to use emscripten to build harfbuzz is,

➜  harfbuzz git:(master) ✗ emcc src/harfbuzz.cc -o hb.wasm -DHB_NO_MT -s ERROR_ON_UNDEFINED_SYMBOLS=0 -Wl,--export=hb_shape
➜  harfbuzz git:(master) ✗ wasm-dis hb.wasm | grep export
 (export "memory" (memory $0))
 (export "__errno_location" (func $5258))
 (export "hb_shape" (func $770))
 (export "__indirect_function_table" (table $0))
 (export "_start" (func $5257))
 (export "fflush" (func $5285))
 (export "stackSave" (func $5339))
 (export "stackRestore" (func $5340))
 (export "stackAlloc" (func $5341))
 (export "emscripten_stack_init" (func $5336))
 (export "emscripten_stack_get_free" (func $5337))
 (export "emscripten_stack_get_end" (func $5338))

And the rest is building components you like using emcc and providing a wrapper for them at the end.

[mimbrown]

Thanks, I'll have to mess with this a bit and see if I can get it working.

[mimbrown]

After a couple days fighting with this I'm going to just admit I'm out of my depth here. Here's where I'm at:

• I followed the directions to get the emcc tool up and running. Using that as a drop-in replacement for clang in the build.sh in this repo seemed to work perfectly fine.
• I added the -DHAVE_GRAPHITE2 flag.
• I pulled in the graphite repo and added the include and src directories: -I graphite/include -I graphite/src.
• I created a graphite.cc file which just #includes all the relevant graphite source files and appended graphite.cc to the emcc command.

Now, when I try to build, it can't find some of the (I think) standard C++ libraries used in some of the Graphite source files. I noticed the -nostdlib flag and tried stripping that out, but then it just throws a bunch of other errors. Any chance you've got some more pointers here?

[mhosken]

Feel free to raise an issue on https://github.com/silnrsi/graphite including the .cc file you created and the errors you received. Debugging is hard. Guessing the code and responses makes it that much more tricky. TIA.

[ebraminio]

There is even a emcmake provided with emscripten's helpers which you probably can use instead going for ruling your own build system script so my suggestion would be to go for a emscripten-ish way with the project instead considering the approach we've used here (it is probable using our approach would be just easier but emscripten one has easier resource for easier integration and etc).

[mimbrown]

When I strip those flags and files it throws a bunch of errors. Here's a couple of them:

1 warning generated.
In file included from graphite\src\graphite.cc:1:
In file included from graphite\src/call_machine.cpp:38:
In file included from graphite\src/inc/Machine.h:35:
In file included from emsdk\upstream\emscripten\cache\sysroot/include/c++/v1\limits:104:
emsdk\upstream\emscripten\cache\sysroot/include/c++/v1\__config:1134:6: error:
      "No thread API"
#    error "No thread API"
     ^

In file included from graphite\src\graphite.cc:1:
In file included from graphite\src/call_machine.cpp:38:
In file included from graphite\src/inc/Machine.h:35:
In file included from emsdk\upstream\emscripten\cache\sysroot/include/c++/v1\limits:105:
emsdk\upstream\emscripten\cache\sysroot/include/c++/v1\type_traits:720:49: error: use of
      undeclared identifier 'nullptr_t'; did you mean 'nullptr'?
template <>          struct __is_nullptr_t_impl<nullptr_t> : public true_type {};
                                                ^

In file included from graphite\src\graphite.cc:1:
In file included from graphite\src/call_machine.cpp:39:
In file included from graphite\src/inc/Segment.h:34:
In file included from graphite\src\inc/Face.h:34:
In file included from graphite\src\inc/FeatureMap.h:29:
In file included from graphite\src\inc/FeatureVal.h:31:
In file included from graphite\src\inc/List.h:35:
emsdk\upstream\emscripten\cache\sysroot/include/c++/v1\new:186:79: error: no type named
      'size_t' in namespace 'std'; did you mean simply 'size_t'?
_LIBCPP_NODISCARD_AFTER_CXX17 _LIBCPP_OVERRIDABLE_FUNC_VIS void* operator new(std::size_t __sz) _THROW_BAD_ALLOC;
                                                                              ^~~~~
./libc/include\stdlib.h:12:23: note: 'size_t' declared here
typedef __SIZE_TYPE__ size_t;
                      ^

Thanks for being willing to help me with this. Got any ideas?

[ebraminio]

The first one should be fixed with -pthread with emcc but not sure about the rest :/

[mimbrown]

Adding the -pthread flag didn't fix it, looks like the preprocessor is missing some definitions. This is what's throwing.

// Thread API
#if !defined(_LIBCPP_HAS_NO_THREADS) && \
    !defined(_LIBCPP_HAS_THREAD_API_PTHREAD) && \
    !defined(_LIBCPP_HAS_THREAD_API_WIN32) && \
    !defined(_LIBCPP_HAS_THREAD_API_EXTERNAL)
#  if defined(__FreeBSD__) || \
      defined(__wasi__) || \
      defined(__NetBSD__) || \
      defined(__linux__) || \
      defined(__GNU__) || \
      defined(__APPLE__) || \
      defined(__CloudABI__) || \
      defined(__sun__) || \
      defined(__EMSCRIPTEN__) || \
      (defined(__MINGW32__) && __has_include(<pthread.h>))
#    define _LIBCPP_HAS_THREAD_API_PTHREAD
#  elif defined(__Fuchsia__)
#    define _LIBCPP_HAS_THREAD_API_C11
#  elif defined(_LIBCPP_WIN32API)
#    define _LIBCPP_HAS_THREAD_API_WIN32
#  else
#    error "No thread API"
#  endif // _LIBCPP_HAS_THREAD_API
#endif // _LIBCPP_HAS_NO_THREADS

Is going back to clang a viable option? Is there hope for emscripten? Is this all dead in the water?

[ebraminio]

Oh, I'm not sure, setting up pthread with emscripten should be pretty straightforward, I believe you should go to an emscripten forum now and try to do it in emscripten way :) (even you should drop those -Wl,--export= symbols exporting list as emscripten has yet different way to achieve all those and the borrowed experiences from harfbuzzjs would be not the idiomatic way thus useful there)