Re: [MPEG-OTSPEC] Skia-based ot-svg renderer hook to freetype

2023-07-08 Thread Hin-Tak Leung
On Saturday, 8 July 2023 at 12:36:45 GMT+8, Werner LEMBERG wrote: > > If the Freetype folks want to port to freetype2-demos, and add the > > missing renderNode() to support all OT-SVG (I mean Google OT-SVG > > fonts...) with a different svg rendering engine than rsvg, they can > >

Re: [MPEG-OTSPEC] Skia-based ot-svg renderer hook to freetype

2023-07-07 Thread Werner LEMBERG
> If the Freetype folks want to port to freetype2-demos, and add the > missing renderNode() to support all OT-SVG (I mean Google OT-SVG > fonts...) with a different svg rendering engine than rsvg, they can > fish it out of freetype-py/examples ... :-). Well, I don't think *we* want to port

The Google OT-SVG "quirk" (Re: [MPEG-OTSPEC] Skia-based ot-svg renderer hook to freetype)

2023-07-05 Thread Hin-Tak Leung
I think I am broadly in agreement with you. FWIW, I don't think this difference in Adobe/Mozilla-origin OT-SVG font versus Google-origin OT-SVG font is a bug in Google Fonts. That's why I never filed it as such. The difference as far as I guess, is as you described, though I'd put it in

Re: [MPEG-OTSPEC] Skia-based ot-svg renderer hook to freetype

2023-07-05 Thread Rod Sheeter
If I'm following correctly https://gitlab.freedesktop.org/freetype/freetype-demos/-/commit/626b43db566f907fa7b6926705e914259c54b9cf is working around a bug that results from rsvg taking an svg2 interpretation of width/height. That seems a bit odd as the opentype spec specifically references