If anyone's interested in text shaping/layouting/rendering, I started working on a little document containing some terminology but more importantly some information about how things fit together in a text rendering engine, which is stuff that I found hard to come by in a single document in my research. I'm writing this from the top of my head so if you find anything missing or confusing or too terse please let me know so I can expand/clarify, thanks.
Sorry I can't help you directly with your problem because you haven't presented a reproducible test case that I could look into. That being said, let me make a few observations.
tr uses harfbuzz for text shaping and that only supports unicode text as input so if you have fonts with other charset encodings and you try to pass text in anything other than unicode that won't work.
the tr and ui are being reimplemented in a combination of Terra and Lua (see my previous announcement) - when that will be finished, the current pure Lua implementations will be dropped, so you might wanna wait for that? dunno, it's up to you, but FYI.
why don't you want to modify the code? this code is written by someone who knows nothing about chinese and who just expects harfbuzz and freetype (and of course the fonts) to do the right thing, so you'd better be willing to roll up your sleeves and dig into the code if it doesn't work right (I'm thinking maybe it's time to make a dedicated post just on this topic, just to adjust some expectations)
I forgot to mention: if you want to try out the layers and see what they're capable of, the easiest way is to get the dev repo at https://github.com/capr/luapower-work and type in
./luajit layer_test.lua. If it doesn't work, revert the last commit until it does (because I might push a non-working version sometimes at the end of the day).
If it works, you should see a window that looks like this:
Almost a year have passed since the last status report so I thought I'd do an update on what I've been working on this year, a little background on some of the choices I've made, and also what I'll be doing in the the next few months so hopefully this gets you a better idea on what's usable, what's in-progress and where's it all going.
Since January I've started working with Terra which has been part of luapower since 2015 but I only started using it this year. The short story is that I was looking for a low-level language to reimplement tr, the unicode text shaping and rendering library and also parts of ui (but not the whole thing, I'll explain later). I had to choose between C, C++, Rust, Nim, Terra and Titan (are there others worth considering?).
All these languages have their problems but since Terra's implementation is orders of magnitude smaller than the others (except Titan's?), fixing its problems is within the grasp of a single programmer, even if that might mean reimplementing the language from scratch or making a new dialect (some language warts also need fixing).
Terra's meta-programming means that when code gets refactored for speed it doesn't have to get ugly, so with Terra you can keep your abstractions without losing control on how the code is generated. Turns out this is actually true in practice: the Terra implementation of tr is even smaller than the Lua prototype and just as readable, courtesy of all the syntax sugar and all the abstractions that you can build on top of the language.
There are two major problems with Terra though: one is the lack of debugging support on Windows and with LLVM > 3.5 (can't even get a stack trace on an assert, very painful). The other is lack of tracebacks on compilation errors (also very annoying). There's also two major language warts (frustratingly, both introduced in the latest version): one is eager type-checking and the other is not overloading a function automatically on multiple definitions.
There's a lot more to talk about this topic, I'll make another post if anyone's interested.
The UI stack
Since luapower is focused on desktop apps, the UI stack is where most of my efforts go into. The stack is composed of basically 3 libraries nw, tr and ui. The first one does cross-platform windows and input (like SDL), the second one does text rendering and the third one does layers (think html divs / box model) and widgets (which are made of layers).
This year I decided to reimplement tr in Terra because I couldn't get a smooth 60fps with the Lua implementation on a 1080p screen full of small text (think spreadsheets), and while I was on it, I decided to reimplement layers in Terra too. The result of this effort is terra-tr and terra-layer libraries. terra-layer uses terra-tr internally for text rendering, it is build as a C shared library and exposes a flat C API that can be used directly via LuaJIT's ffi or from any language that can talk C (one could also make a binding generator for the C Lua API pretty straightforwardly with Terra since all the type information is available to Lua at compile-time).
So the split between Terra and Lua is at the layer API level. All the drawing, layouting, hit-testing and invalidation of a tree of layers is implemented in Terra and you can use that as the foundation for any retained-mode GUI library. CSS, animations, event routing, active/hot state management etc. will remain in Lua so that widgets can be still implemented in Lua and benefit from dynamic binding, polymorphism, ability to animate any property, etc., i.e. all the stuff that comes natural in a dynamic language but hard to do in a static language (and also doesn't have to be very fast).
So the next step for me is to remove all the code in ui that is now implemented in Terra and replace it with calls to the layer lib, then test/fix all widget implementations. After that, the TODO list looks something like this:
- continue the work on the editable tree-grid widget (which has hundreds of features and must keep a clean 60fps at full-screen with millions of records in it).
- make a layout editor where you can place widgets but also with direct manipulation of css grid and flexbox layouts (a la Dreamweaver).
- add more features to terra-layer: margins
- add more features to terra-tr: text decorations, embedded widgets in text layout, partial re-layouting on text editing (use case: text editor on a large file).
That's it from the top of my head. Please note that development happens in https://github.com/capr/luapower-work which is a single repository that bundles all the above libraries and their dependencies to make coding easier for me. The changes will land in each lib's own repo once things settle.
Comments, suggestions welcome.
Filed a bug against luasec for the issue https://github.com/brunoos/luasec/issues/145
About trying to use dlls after bundle, do you mean to say that
ffi.load'foo'doesn't work on a bundled exe? Does it produce an error? Crash? Is it only some dlls that don't load or all of them? Is the dll in the same directory as the exe? In LuaJIT there are two ways to load dlls, one is via
requirefor loading Lua/C modules, one is via
ffi.loadfor C modules. Which type is your dll that doesn't load? How did you build the dll? Including information like this in your bug reports is important if you want someone to even attempt to reproduce the bug. Otherwise people will be like "I don't know what he's talking about, works for me" and move on.
Btw I just realized that you should be careful with
--allow-multiple-definitionbecause it depends on the order in which you specify the libraries. In this case, it will expose to Lua the part of LuaSocket that's bundle in LuaSec which is not what you want (if LuaSec modified LuaSocket in any way, which they probably did). The correct fix is to remove those duplicates from
Oh I see now, my bad. So
ssl.ais LuaSec actually I thought it was OpenSSL (nice for them to give it the same name as OpenSSL). So the problem is that LuaSec (
ssl.a) bundles/exports LuaSocket (
socket_core.a) which it shouldn't do. I need to fix the LuaSec build then. Thanks!
Not sure how you got
socket_core.a, these don't look like they are the ones from luapower (those are named
socket/core.arespectively). In any case, the problem is that you somehow bundled LuaSocket into
ssl.a. Fix your build (or use luapower's binaries) and you won't need the
Btw, on Windows there are many dll inspection tools (I use a Total Commander plugin called FileInfo but you can also use
nmfrom msys2, etc), use one of those to check the dependencies of .dll and .a files if you don't know them (in case you haven't built them yourself).
Email firstname.lastname@example.org Full Name Cosmin Apreutesei Website luapower.com/cosmin Location Bucharest Followers 0 Following 0 Joined Last Online