Hacker News Reader

Comment by danShumway | Hacker News Reader

> somehow

That being the required word. If Qt does all of its own rendering and ignores browser APIs, there's no way for it (just as an example) to defer to custom system fonts if a user is dyslexic.

Even assuming that the browser did expose everything necessary to re-implement its accessibility stack, screen readers and translators on the web are all using CSS and the DOM to figure out what to say. The only way to get real integration with browser accessibility tools and extensions would be for Qt to put wrappers around all of the entry points like DOM selectors.

And if that's the plan, why not save everyone a bunch of trouble and just use the DOM correctly to begin with?

View on HN

... But it is possible to write bridge code that uses browser APIs to provide custom user fonts to Qt for use in a <canvas>.

Oh crud, you are completely right about that. I forgot that canvas allows you to pass in a font family when it draws text.

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?

This release of Qt for WebAssembly is the first officially released prototype of this technology. Qt comes from the native desktop world where it relies and builds on top of the whole rich world of native OS APIs. There's nowhere near that API support on the web platform at the moment. Also Qt might not be using the full capabilities of the web platform in this first release. Naturally, the first results are crude. But Qt has a great platform abstraction mechanism, so I'm sure it will only improve over time, either making better use of existing web APIs or support new ones as they become available.

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.

> there's no way for Qt to leverage user fonts if it keeps on using that strategy.

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.

Reply on news.ycombinator.com