Fair enough, Qt could theoretically read a font from the body CSS and then use it for internal text rendering. Although, correct me if I'm wrong, but Qt probably isn't using `fillText` to render it's font. A few other people here have mentioned that they're doing their own rendering and spitting out raw pixels.
(As far as I know) there's no way for Qt to leverage user fonts if it keeps on using that strategy. And again, if they're already planning on abstracting text out to use native browser APIs, why not go all the way and put the text in a DOM element?
Also it is worth to point out, that there are really 2 GUI toolkits in Qt:
Qt Widgets - the more classical, desktop UI paradigm. Yes, this renders everything into a bitmap and therefore translates better to the Canvas model on the web.
QML / Qt Quick - more DOM like, declarative UI with modern animation, scripting and data binding features. This maps better to the HTML DOM model. In theory at least, however, the similarity is only superficial. Under the hood, the QML visual elements are rendered with WebGL.
One possible approach would be to create an invisible <canvas> (i.e. display:none or position:absolute;left:-15000), use fillText at the desired font size for the subset of characters that will be used, read the pixel data back in, and use the (now bitmapped) font to render text internally. Using bitmapped font data could require patching Qt's render pipeline at a low level -- I don't know enough to say.