Is there a go-to guide on setting text formats? There’s a lot of (out-dated) information around and it’s not very clear what to do.
This works on non-html platforms:
var fontName:String = Assets.getFont("assets/pf_ronda_seven.ttf").fontName;
rightAlignFormat = new TextFormat();
rightAlignFormat.font = fontName;
Is there anything I’m supposed to do to make this work on html?
I have ttc and otf files that I’d like to use. Are they compatible? They’re not working.
It is working for me but I am using this settings (just tested now on HTML5 target, I see my textfield using the font)
var textFieldFormat:TextFormat = new TextFormat(Assets.getFont("assets/pf_ronda_seven.ttf").fontName, 20 , 0);
var textField = new TextField();
textFieldFormat.align = TextFormatAlign.LEFT;
textField.autoSize = TextFieldAutoSize.LEFT;
textField.antiAliasType = AntiAliasType.ADVANCED;
textField.defaultTextFormat = textFieldFormat;
textField.embedFonts = true;
textField.selectable = false;
textField.wordWrap = false;
textField.border = false;
I think the only one that could be it is embedFonts = true. Try to set it on your code.
Otherwise are you sure you are actually use the TextFormat on the TextField?
If it is still not working check you have openfl and lime updated (
sudo haxelib upgrade)
Last chance I would say are you using NEXT or V2? If you are using OpenFL NEXT it could be an issue, Joshua told me he’s working on the Text/Font renderer in these days.
Hope this helps.
Thanks! I’ve been switching between the release and the dev build. Is that NEXT?
compshx: git [dev:/usr/lib/haxe/lib/compshx/git]
hxcpp: 3.1.68 [3.2.27]
lime: 2.1.2 [2.1.3]
openfl: 2.2.7 [2.2.8]
when you do
lime test <target>
you use V2 (legacy), the production current version
when you do
lime test <target> -Dnext
you use NEXT, the new alpha version, lots of news and big changes, still in development
I’ve taken a step backwards now.
I updated my git repo of the dev build of openfl and it’s broken input text fields (which have been very finnicky) Most of the time I can only click it once and then once I’ve deselected the text field I cannot select or type into it again. Also the highlighting is offset and the wrong size and colour.
TextField(s) that were set to input text used to not really work (probably because they weren’t dom) so I was using the dev build, I suppose it was
b962bb2 because I just
git pull'ed the new one (I think) and it’s gone back to the old broken non-dom behaviour when I call
openfl test html5
remote: Counting objects: 153, done.
remote: Compressing objects: 100% (105/105), done.
remote: Total 153 (delta 57), reused 14 (delta 14), pack-reused 33
Receiving objects: 100% (153/153), 179.43 KiB | 45.00 KiB/s, done.
Resolving deltas: 100% (65/65), done.
b962bb2..7201f37 master -> origin/master
* [new branch] softKeyboardRect -> origin/softKeyboardRect
* [new tag] 2.2.8 -> 2.2.8
EDIT: I’m not sure if I just commented out the bit-five line at the same time.
and in html the highlighting and editing is all messed up.
and with bit-five the selection starts working, but the right-align text goes mental.
<set name="html5-backend" value="openfl-bitfive" />
That’s all the same code, it’s just with bit-five. So I suppose they didn’t implement right align.
as far as I can tell textWidth and Text Field Alignment are not implemented on bit-five. But if I don’t use bit-five then the text input is not DOM and hardly works at all.
As the official BITFIVE github page says:
Thanks, It’s probably not appropriate for this app, I was just checking it out because the standard backend had that issue I described and photographed above with input text.
if you are sure it was working before:
the best option is to clone the commit that was working (first step is find it then use haxelib git to install it) and after submit an issue on the openfl github page.
this way you can keep working and you will see the problem will be addressed quite fast and afterwards you could go back to the master.
Sorry, I’m not sure. I’ve gone through a handful of different configurations and code.
Does everyone else have reasonable Input Text in html with the standard back-end? mine is acting weird.
Have you tried
openfl test html5 -Ddom?
openfl test html5 gives an input text field that:
- is selectable but looks bad, opaque and doesn’t properly surround the text.
- Doesn’t scale well with the browser (obviously)
- Doesn’t let me type the
space character, but does let me copy/paste it
openfl test html5 -Ddom gives an input text field that:
- Properly scaled text when the browser is zoomed in.
- Shows the text-cursor when you move your mouse over it
- Does not let me select text
- Does not let me type text
Is there a specific version/combination of lime and openfl I should be using?
So it sounds as if input text was not enabled for -Ddom mode, that would be the simplest to support. Probably only a few CSS properties and getters for it to work
The input text under canvas is new, it was based on a pull request that (I feel) brings it closer to reality but isn’t there yet. I hope to see progress in this area soon, as this is a key feature
Yeah thanks singmajesty, It’s just too bad I have a deadline and might need to do this app ‘natively’.
Thanks for your help.
if it comes down to it, be aware that -Ddom mode is compatible with an
openfl.display.DOMSprite which should allow for you to specify your own HTML element, but mix it within the display list. However, making DOM mode work with input text may be easier done as a patch to the TextField class