Calculating text bounding box programmatically - without flash api, canvas etc?

[Cambiata]

Hi!

Are there any solutions around for programmatically calculating the bounding box of a text string with a given system font (name, size, attributes)?
I can do this on OpenFL targets by using the flash api, and also on html5 targets by creating a canvas and using its methods,
but I want to be able to do this completely "headless" - for example through neko on a web server.

Are there any ways of doing this in Haxe?

I guess that you have to either go for some kind of OS font handling solution, or read the font files and do some quasi rendering (including kerning stuff etc.)...

Jonas

[Simon Krajewski]

If you want to do this completely cross-platform you'll likely have to
write your own renderer minus the draw commands.

Our ttflib can parse the required TTF tables as well as kerning, so you
could use that as a starting point. Right now it only outputs the glyph
coordinates. See https://github.com/HaxeFoundation/haxe/issues/2723 for
some information.

Simon

[Cambiata]

Thank you, Simon!

Is there a Haxe implementation of it somewhere or will I have to deal with OCaml?
(Can't find it as a part of Haxe api or on Haxelib...)

[JLM]

hxswfml, but the ocaml one is much faster at processing the font tables.

[JLM]

One aspect that is tricky is that curves are often slightly larger that the points defining them so you can't just take max and min values of the plotted points and be sure of no clipping, likely some trial and error would be needed.

[David Elahee]

This is an overly difficult problem. The ttf lib will do only it is really well mastered and all the parameters are calculated...

Much simpler : 

-Use bmfont and reimplement the boxing

- load freetype as a C stub and doit with it ( openfl already use it so the stub must exist..

gl pal !

2014-04-18 15:45 GMT+02:00 JLM <j...@justinfront.net>:

One aspect that is tricky is that curves are often slightly larger that the points defining them so you can't just take max and min values of the plotted points and be sure of no clipping, likely some trial and error would be needed.

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

--
David Elahee

[Cambiata]

Thank you, guys!

Justin, is this the hxswfml version, or is there another newer one?
https://github.com/b0beR/hxswfml
https://github.com/b0beR/hxswfml/tree/master/src/format/ttf

[Justin L Mills]

Not sure what that is, look at Jan's lib, specifically here:
https://code.google.com/p/hxswfml/source/browse/trunk/src/be/haxer/hxswfml/FontWriter.hx

He is often on IRC but feel free to ping me questions privately as I
used it quite a bit on a project and might have some memories.

The TTF stuff as part of git haxe is not hard to use just make haxe
first then explore into the sub directory I think kern needs more
processing for the tool to be more useful outside the swf/openfl arena.

The Java target lets you get directly at font metrics see here:
http://haxe.org/doc/java/graphics2d#font

Maybe haxe Java running non visually is the simplest approach.

Cambiata:

[Cambiata]

Thank you, Justin! That's a fresher one.

Maybe haxe Java running non visually is the simplest approach.

I can run NME though neko in "headless" mode, with no visible window, and get acces to the flash api from there.
Maybe I will stick with that for now.

Btw, I had some fun playing with your Letters lib yesterday, successfully doing some graphics stuff in Haxe Java :-)
Do you have some ideas about converting SVG files to Graphics2D paths?
Do you think it would be possible to integrate something like Flamingo SVG transcoder (http://ebourg.github.com/flamingo-svg-transcoder) into a Haxe Java solution for SVG -> Graphics2D?

[Jason O'Neil]

Hi Jonas

I'm pretty sure I remember Tom Rhodes talking about a project where he used NME on a server running through mod_neko to process video frames or something similar.  If you know how to calculate the bounding box in OpenFL perhaps using OpenFL's Neko target through mod_neko is a bizarre option.

I have no idea if there are any special requirements to get NME or OpenFL to work in a server environment, but you could try get in touch with Tom and find out if that's an option...

Jason

[Dion Whitehead Amago]

I forked flambe to use node.js and wired it up to node-canvas: https://github.com/dionjwa/flambe/tree/node_canvas

This means you can run games (for me game simulations and quick UI tests) totally headless and e.g. get a single frame.

You don't need this whole shebang if you want font information from a headless program, you just need the node canvas bit.  It's a direct implementation of the HTML5 canvas API.

[Cambiata]

@Jason: That's how I'm doing it right now - A plain neko headless app with NME library added. Not tested on server, but I can't see any reason why it shouldn't work.

@Dion: I haven't done any Haxe Node stuff yet, but that's an option, for sure. Maybe also a bit more accurate than the OpenFL roundtrip when it comes to displaying the end result on the web page.

[tom rhodes]

Hey,

It didn't need anything special to run on the server, it was a while ago though, before OpenFL happened. I'd recommend it for anything where you need a display list but can't have one on the client for whatever reason, you can do everything you want on the diplay list and push out an image.

On 19 April 2014 12:17, Cambiata <jona...@gmail.com> wrote:

@Jason: That's how I'm doing it right now - A plain neko headless app with NME library added. Not tested on server, but I can't see any reason why it shouldn't work.

@Dion: I haven't done any Haxe Node stuff yet, but that's an option, for sure. Maybe also a bit more accurate than the OpenFL roundtrip when it comes to displaying the end result on the web page.

[Joshua Granick]

lime-tools uses OpenFL in order to perform certain types of processing. It's a good example of a command-line application (and we use it on our server for builds, etc) that leverages API features. That should be simpler than trying to do your own Freetype mapping. I believe there is already a function for getting font information out, which used with openfl-html5-dom, before we switched to webfonts in openfl-html5

--

Using Opera's mail client: http://www.opera.com/mail/