Questions about asynchronous font loading about lib-font HOT 6 CLOSED

Nevermind, sorry! I was doing font.onload(callback) instead of font.onload = callback as I should have been doing. Onload is indeed called correctly for system fonts.

However, now I'll hijack this issue to ask a different question: Currently there is a 10ms wait before system fonts are processed. But the processing step itself also contains a 50ms timeout delay - which seems like it should obviate the need for the first delay. Are they both truly necessary or can the first 10ms delay be omitted? My limited testing in Chrome shows no problems with processing it immediately.

from lib-font.

And one more related question: The delayedValidate function is currently called with a setTimeout of 50ms in order to give the browser time to finish rendering/painting. This seems like it would a good use case for requestAnimationFrame which should be called when the repaint is finished.

I tried plugging it in and it seems to work fine in latest versions of Chrome, Firefox and Opera, though I haven't tested extensively. Would this be a good improvement, or are there good reasons not to use RAF here? I can submit a PR if you'd like.

from lib-font.

Hmm, honestly at this point you're probably going to get better mileage out of the opentype.js linked to from the README.md. It shouldn't have any artificial delays I had to use back when I made this library.

from lib-font.

Unfortunately, it seems that Opentype does not support system fonts, nor does it have a font.measureText equivalent.

I pretty much only have a single use case: get the bounding box of a string with a given (already loaded) font & size, before rendering to the DOM - this way you can do more interesting layout things faster. Otherwise you need to add to the DOM, measure, then remove, which is slow.

It seems like this is not a well-covered case by existing libraries. I may consider forking Font.js or Opentype.js to create a library that does only this.

from lib-font.

that's true, it won't do system font metrics since it shapes based on the actual font file. Both the 10ms and 50ms delays are mostly to move over to the next tick without immediately hijacking the thread again. Compared to the time necessary to do the canvas drawing and measuring, the combined 60ms (~4 frames if we're thinking in animation timing) is pretty much insignificant, but I didn't want to use 0ms or 1ms timeout values. Immediate processing will do terrible things if you're also loading other scripts at the same time, so you always want to bake in a few "breathing spaces" in long scripts to make sure it doesn't lock the page. I know requestAnimationFrame exists, but I don't use it for anything except literally that: animation draw loops.

from lib-font.

obsolete with the 2019 rewrite

from lib-font.