François Pirsch

Hi @brawer ! From what I recall, the problem is that the main function `renderSVG()` in this file just concatenates `glyph.path.toSVG()` results on each glyph independently. This of course leaves...

I guess this is why @fdb did it this way in the first place. Maybe `Font.getPath` should be modified to output separate paths.

Could be nice, just be aware that putting a getter on a heavily used property on every glyph could affect performance.

I was just talking about simple property access vs a getter function call. Benchmarking the rendering of lots of glyphs with and without such a getter would be great.

What we are saying here is that there are two use cases for a font: - general font information, which should parse only parts of the file - glyph rendering,...

All fonts. Glyph.prototype.draw() calls Glyph.prototype.getPath() everytime, and a new Path object gets built every time. The consequence is not only loss of fill & stroke style, but also poor performance...

You're right, so maybe the problem here is to store stroke and fill style in the path object. Also note that the next layer `Font.prototype.draw(ctx, text, ...)` doesn't cache paths...

TL;DR : No way The font object is an in-memory javascript representation of the font. CSS @fontface loads files encoded in specific formats, preferably over the network. This would require...

:+1:

@njx's code can be pasted in the preference file. You can open it from within Brackets under the **Debug** menu.