![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder General » View Thread |
Messages 1 to 8 of 8 total |
![]() |
Mon, Oct 1 2018 9:15 AM | Permanent Link |
Mark Brooks Slikware | 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 AM | Permanent Link |
Mark Brooks Slikware | 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 AM | Permanent Link |
Mark Brooks Slikware | 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | 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 AM | Permanent Link |
Mark Brooks Slikware | 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | 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 AM | Permanent Link |
Mark Brooks Slikware | 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | 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 |
This web page was last updated on Tuesday, November 28, 2023 at 10:08 AM | Privacy Policy![]() © 2023 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |