Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 8 of 8 total
Thread Ongoing Autosize Issues
Mon, Oct 1 2018 9:15 AMPermanent Link

Mark Brooks

Slikware

Avatar

Hi All

I have a suite of apps that all use Open Sans as an external font. I have a recurring issue whereby sometimes (in fact more recently most times) an EWB label using Autosize does not size correctly at runtime. I have attached an example for you to see where the labels are clipped by height and by width. In some cases it is possible to rectify by refreshing the app a few times, but certainly not always.

Is anybody else experiencing this issue?

I have tested in Windows and macOS with a range of browsers and the issue is still there. If I were a gambling man, it almost seems as if the label is sizing itself based on the "default" EWB label font, rather than the external one that's been selected.

Any help appreciated.

Mark



Attachments: Autosize Funny.png
Tue, Oct 2 2018 8:46 AMPermanent Link

Mark Brooks

Slikware

Avatar

Additionally, when the app first loads, I can sometimes see the various labels in Arial very briefly before they flip to Open Sans. Also makes me think the auto-size of Height and Width is taking place before the font has time to be changed. I wonder if there is a way to guarantee that the font is loaded .................
Tue, Oct 2 2018 9:19 AMPermanent Link

Mark Brooks

Slikware

Avatar

And finally a short video to show how a resize can sometimes "trigger" the auto-size of Height to kick-in



Attachments: Screen Recording 2018-10-02 at 14.17.17.mov
Tue, Oct 2 2018 4:00 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Mark,

<< I have a suite of apps that all use Open Sans as an external font.>>

This problem may be due to the way that EWB is including the external fonts in <style> block instead of linking them as a style sheet that forces the download before anything is rendered.

I'll have to check into this further and get back to you.

Tim Young
Elevate Software
www.elevatesoft.com
Wed, Oct 3 2018 11:14 AMPermanent Link

Mark Brooks

Slikware

Avatar

Tim Young [Elevate Software] wrote:

<< This problem may be due to the way that EWB is including the external fonts in <style> block instead of linking them as a style sheet that forces the download before anything is rendered.

I'll have to check into this further and get back to you. >>

Ok Tim.

That does make sense, in that what I see is a sort of "delayed" effect. I think you're spot on. Please let me know if I can assist in any way with tests / whatever.

Cheers
Mark
Wed, Oct 3 2018 12:44 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Mark,

<< That does make sense, in that what I see is a sort of "delayed" effect. I think you're spot on. Please let me know if I can assist in any way with tests / whatever. >>

Yeah, I did some more research yesterday and the issue is that IE/Edge *do* deal with the web fonts as part of the critical path, so you won't see any issues with them, but you *will* see issues in the other browsers based on WebKit/Chromium because they download the web fonts asynchronously and only when they see that there is rendered text that requires the font, which leads to the behavior that you're seeing.

I think what I'm going to have to do is include an option for external fonts to be embedded in the HTML loader like the icon font is in EWB - that will force them into the critical path and they will be dealt with before any text is measured/rendered.  However, you *will* need to be careful about the font sizes then, because they will balloon up the size of the HTML loader, especially fonts like Open Sans that are 200K+ in size.

Tim Young
Elevate Software
www.elevatesoft.com
Thu, Oct 4 2018 5:51 AMPermanent Link

Mark Brooks

Slikware

Avatar

Tim Young [Elevate Software] wrote:

<<Yeah, I did some more research yesterday and the issue is that IE/Edge *do* deal with the web fonts as part of the critical path, so you won't see any issues with them, but you *will* see issues in the other browsers based on WebKit/Chromium because they download the web fonts asynchronously and only when they see that there is rendered text that requires the font, which leads to the behavior that you're seeing.

I think what I'm going to have to do is include an option for external fonts to be embedded in the HTML loader like the icon font is in EWB - that will force them into the critical path and they will be dealt with before any text is measured/rendered.  However, you *will* need to be careful about the font sizes then, because they will balloon up the size of the HTML loader, especially fonts like Open Sans that are 200K+ in size.>>

That makes perfect sense to me. Is there a workaround in the meantime e.g showing a label with the external font and "waiting a bit"?
Thu, Oct 4 2018 12:46 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Mark,

<< That makes perfect sense to me. Is there a workaround in the meantime e.g showing a label with the external font and "waiting a bit"? >>

You could try that, but you're still going to have a race condition on the text getting displayed vs. the font getting downloaded/loaded/rendered, so it may help, but not completely.

The bottom line is that this type of browser behavior is bone-headed, at best.  IE and Edge handled it correctly - the text should simply not render until any dependent fonts are available.  It should be up to the developer to reduce the font size or use a smaller, more compact web font if delays are an issue.

I'm going to try some lesser workarounds besides embedding the fonts and see if they work before going the embedding route, but I'll probably go ahead and add the embedding, anyway.

Tim Young
Elevate Software
www.elevatesoft.com
Image