It says ‘images’ in line 211 is null under Neko (Windows 10). It crashes under Android. It cannot generate some web font files under HTML5 (this is probably because I’m missing some tool I’m not aware of). I haven’t tested the other targets.
We’ve needed to refactor our support for text layout and rendering a bit in Lime in order to improve support in OpenFL. We’re using Harfbuzz for text layout, but currently use a different method for rendering than the TextRendering demo. I think that’s the one demo that’s known to be broken, but we should circle back and implement a better Lime API for generating font atlases.
If you test other samples, it should be fine, specifically “AddingText”, “PiratePig” and other OpenFL samples that use text. Are you trying to use Lime directly, or are you using OpenFL? The webfont generator we use (https://github.com/ananthakumaran/webify) doesn’t support certain fonts for certain formats, but we improved our output code so that we still generate CSS for the font types that did generate. Many times, this is good enough to still support most or all web browsers. Happy to consider another webfont generator, if we find one that’s better and works on the command-line
Sorry about the rough edges on this sample, if you do want to use Lime, I’d be happy to show you how we use Lime
TextLayout plus Cairo
showGlyphs to rendering in OpenFL
I’d like to use only Lime, not OpenFL. I’ll give Harfbuzz a go. I’ll also try webify, which is new to me.
Yes, I’ve tested the other samples, and they’re OK, but it’s not what I’m looking for. I’d like to render text in a Lime OpenGL context, as it appears in the TextRendering demo.
Can you show me how to use TextLayout and showGlyphs to render in a Lime OpenGL context (not OpenFL)? Is it possible to do this, or should I stick to Harfbuzz?
I realized that
Font.renderGlyphs was disabled because we moved from
haxe.io.Bytes and I was concerned about endianness. I had thought maybe it was fundamentally broken, but I realized that this was sort of an embarrassingly simple fix (again, now that we can trust the output from
I’ve done a couple things, first
Font.renderGlyphs is enabled again, and secondly I fixed the “TextRendering” sample. The
bitsPerSample property should check for
8 to use
1, and we need to ignore text positions with a glyph of zero.
As I discussed about
cairo.showGlyphs, I updated the sample to include Cairo rendering in addition to OpenGL, to illustrate both a software and a hardware approach to doing this.
Here is how you use Lime from source:
You can find the patched version of the “TextRendering” demo here:
Ok, thanks. I’ll give it a go. Before that, there is something else I’d like to ask (I haven’t yet seen the patch). Is there a way to use Lime to render text into an Image? I thought I could then use that image as a texture in OpenGL.
Yep, that’s totally possible.
We don’t have a formal API for it, but we use canvas on HTML5 or use Cairo on native platforms to do this for OpenFL’s
The updated “TextRendering” sample has a Cairo render path, which renders directly to one Cairo image surface, you could do something similar. Instead of using
cairo from the rendering context (since the context would be
gl) do something like this:
var surface = new CairoImageSurface (ARGB32, textureWidth, textureHeight); var cairo = new Cairo (surface); // execute Cairo draw commands
Then you can create a new GL texture, and use
surface.data as a pointer with
texImage2d, the Cairo image surface uses premultiplied BGRA, not RGBA, here’s what we do in OpenFL to check for the BGRA GL extension:
The alternative would be a framebuffer and render-to-texture. Using Cairo means you don’t have to
Font.renderGlyphs, it handles that part of the rendering for you
Ok, thanks. Sadly, I can’t at the moment build Lime from scratch, so I’ll have to wait until the next version is deployed in Haxelib to test all of this.
Released on Friday, sorry for the lack of announcement