Why? 'true type 'text Does' html5 'target not support spacing?

.
That’s great! Can you explain in advance what “9.5.0” has done, such as whether there have been any optimizations or performance improvements?
.

.
I remember the last time “Bink” mentioned that “openfl” has not fully supported “html5” yet?
.

I don’t know English! I use software translation, there may be some differences.

I updated the CHANGELOG for both projects yesterday:

As I recall, there were some small performance improvements.

HTML5 is fully supported. I don’t recall exactly what Bink said, but you may have misunderstood.

I concur.

I don’t recall ever saying HTML5 was not fully supported. If I did, it was likely within a specific context, like my personal preference for using vector graphics (SVGs) with OpenFL when targeting HTML5, as opposed to Starling’s use of bitmaps for reasons of scaling across devices.

.
Bink
joshtynjala
.
Thank you very much. It depends on what “Bink” means, or it may be a translation difference It’s great that ‘html5’ fully supports it
.

Ah, I think I know what you’re referring to now @785597448. It just clicked: specifically, with respect to spacing in HTML5 targets.

To clarify @785597448, the lack of support for letter spacing wasn’t an OpenFL limitation, it was the web API limitation. Support for letter spacing was only added to the web API this year, and OpenFL’s development branch (9.6.0) has been updated to include that support.

In that context, I understand why you thought I’d said HTML5 wasn’t fully supported yet, in a manner of speaking, I had. But that’d be a very general way of putting it, and perhaps a bit confusing :wink:

.
From what I can garner, support was never fully implemented for HTML5
.
Sorry about that! That day, I remembered what you said ..
.

There was a context :wink:

Let me insert that here for clarity.

I understand working across translations is difficult @785597448. I’ve faced similar issues discussing technical ideas with German folk (I don’t speak German!).

With a bit of patience, we’ll get there though :wink::+1:

Okay, I understand now that you’re referring to ‘letter spacing’ ..

1 Like

Do you use the “openfl” version on “git”?
Is that considered a ‘beta version’?

Sometimes I have, but only really if there’s a specific reason, like a new feature I’m needing, or testing, or building.

If there’s no specific reason to use the git version, I’d suggest using the latest release.

I would consider the git version pre-release in terms of stability. That is, it may have bugs as a result of being a work in progress, but @joshtynjala, @Dimensionscape and @singmajesty would be in a far better position than I to comment on the stability you might expect as they are the ones shaping and managing those commits with their much appreciated efforts.

Thank you very much for your answer. I think we should wait for the official version to be released. I also like to pursue stability ..

A “Starling” enthusiast developer,
Looking forward to adding more new features to ‘Starling’,
And performance optimization.

Hey, friend.
May I ask how you set up the ‘viewPort’?

What is it you’re needing to do with it?

The example I provided in the past, is how I’ve typically used it, but that’s based on my needs (simple full-screen toggle, with the option to maintain aspect or stretch to fit):

.
After reading your code,
What you added is’ ResizeEvent. RESIZE ‘,
And what I added was’ Event. RESIZE ',
All of them are window change events, should the effect be the same?
.
private function stageResized(e:ResizeEvent):Void {
shapeScaler.width = e.width;
shapeScaler.height = e.height;

	// choose the larger scale property and match the other to it;
	(shapeScaler.scaleX < shapeScaler.scaleY) ? shapeScaler.scaleY = shapeScaler.scaleX : shapeScaler.scaleX = shapeScaler.scaleY;

	// choose the smaller scale property and match the other to it;
	(shapeScaler.scaleX > shapeScaler.scaleY) ? shapeScaler.scaleY = shapeScaler.scaleX : shapeScaler.scaleX = shapeScaler.scaleY;

	// Auto-fit any resolution maintaining aspect.
	Starling.current.viewPort = new Rectangle((e.width - shapeScaler.width) / 2, (e.height - shapeScaler.height) / 2, shapeScaler.width,
		shapeScaler.height);

	// Auto-fit any resolution with stretch.
	// Starling.current.viewPort = new Rectangle(0, 0, e.width, e.height);

	trace('Stage resized to:', e.width, e.height, ' and viewPort resized to', shapeScaler.width, shapeScaler.height);
}

}
.

above
“e.width
e.height”
Is it the size of an “openfl” stage?

Both would catch the event, because both equal the same String: "resize".

Strictly speaking though, the Stage class dispatches the event type ResizeEvent:

/** Dispatched when the Flash container is resized. */
@:meta(Event(name="resize", type="starling.events.ResizeEvent"))
 *  <p>When the Flash player is resized, the stage dispatches a <code>ResizeEvent</code>. The 
 *  event contains properties containing the updated width and height of the Flash player.</p>
 *
 *  @see starling.events.KeyboardEvent
 *  @see starling.events.ResizeEvent  

Using Event.RESIZE instead may mean you can’t retrieve the event.width and event.height data from it, as these are defined in ResizeEvent and not Event.


e.width and e.height there is the updated size of the application window, not the Starling view port. The Starling view port is the Starling.current.viewPort, which in my example, is adjusted to respond to the updated size of the application window.

See the doc comments here for some details: