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?
Hi again!
I realized that Font.renderGlyphs
was disabled because we moved from ByteArray
to 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 TextLayout
)
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 gl.ALPHA
, not 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:
https://github.com/openfl/lime-samples/tree/master/features/text/TextRendering
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 TextField
implementation.
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.
Thanks again!
Released on Friday, sorry for the lack of announcement