Woa that's some heavy SVG lifting going on there!

If I get it right, every glyph used from the given font is rendered once as a SVG path (upside down! huh!), and then the whole page is a single huge SVG element in which every typed character is a <use> with a reference to that rendered glyph, translated with a CSS transform to the right place (i assume these coordinates come out of HarfBuzz?). Kinda mad that you had to redo 90% of the browser that way but the result is pretty impressive!

I'm curious why you render the glyphs to paths and not have the browser render those directly using eg svg <text> elements?

Was it hard to get this to work cross browser?

ps. srsly I love this about the web. You're doing this amazing engineering feat and I can just pop the trunk and learn all about it. Obviously feel free to not answer anything that's deemed a trade secret, I'm just geeking out hard on this thing :-) :-)

▲

rjsw 7 days ago | parent [-]

You can't size other SVG elements around text ones since you don't know how much space the text element will occupy.

▲

skrebbel 7 days ago | parent [-]

I don't mean HTML text nodes, I mean still the single big SVG like they do now, but with SVG <text> elements instead of <path> elements. They do know (I suppose) how much space that element would take since they're asking HarfBuzz to tell them.

▲

rjsw 7 days ago | parent [-]

You can't know the size of an SVG <text> element.

▲

skrebbel 6 days ago | parent [-]

why not? if you control the font and the font size then can't you have harfbuzz tell you how wide each glyph is going to be, and it'll fit precisely? (assuming the browser also uses harfbuzz for this, which it does)

	▲	rjsw 6 days ago \| parent [-]
		Because SVG isn't defined to call into harfbuzz. You don't control the font if the SVG fragment is embedded in HTML.