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 http://www.w3.org/TR/SVG11 and the svg documents in Google-origin ot-svg seem to explicitly indicate that they are in svg 1.1 (<svg ...xmlns... version="1.1">) and thus probably shouldn't be interpreted using svg 2 conventions.
For context, "Google-origin ot-svg" is likely built by https://github.com/googlefonts/nanoemoji. Based on a quick glance at some of our testdata, e.g. https://github.com/googlefonts/nanoemoji/blob/main/tests/rect_picosvg.ttx, it looks to me like we followed the examples given in https://learn.microsoft.com/en-us/typography/opentype/spec/svg#glyph-identifiers and do not include viewbox or width/height. We assume units to be interpreted as advised in https://learn.microsoft.com/en-us/typography/opentype/spec/svg#coordinate-systems-and-glyph-metrics . Cheers, Rod S. On Wed, Jul 5, 2023 at 4:10 PM Hin-Tak Leung <ht...@users.sourceforge.net> wrote: > Okay it says "out-of-memory condition" > https://gitlab.freedesktop.org/freetype/freetype-demos/-/commit/626b43db566f907fa7b6926705e914259c54b9cf > instead of "memory exhaustion" (I think that's my subject heading when I > posted to freetype-devel). > > It has my name on it, and is the 3rd most recent commit on freetype2-demos > (as of now). You didn't look. > > On Thursday, 6 July 2023 at 06:43:35 GMT+8, Hin-Tak Leung < > ht...@users.sourceforge.net> wrote: > > > Actually Adobe/Mozilla OT-SVG fonts do *not* return EM, EM but something > like a few hundred, a few hundred. > > The bug fix in freetype2-demos I submitted was that, if it comes out as > 1,1, it means EM, EM (1024, 2048 or there abouts). > > Search for "memory exhaustion" in the freetype2-demos commit log, as I > suggested. It isn't that hard to find. > > On Thursday, 6 July 2023 at 06:36:49 GMT+8, Hin-Tak Leung < > ht...@users.sourceforge.net> wrote: > > > It is the result from the "intrinsic dimensions" routine - (there is a > routine of that sort of name in both rsvg and skia). It returns some larger > numbers, EM,EM I think for Adobe/Mozilla OT-SVG fonts, but 1,1 from rsvg > and 0,0 from skia for Google-origin OT-SVG fonts. > > Clear enough? > > On Wednesday, 5 July 2023 at 22:00:54 GMT+8, Cosimo Lupo < > cos...@anthrotype.com> wrote: > > > I have no idea what you're talking about. Please, clarify what this > difference is supposed to be, otherwise this is just spreading rumors. > > On Wed, Jul 5, 2023 at 2:33 PM Hin-Tak Leung <ht...@users.sourceforge.net> > wrote: > > > > On Wednesday, 5 July 2023 at 20:49:42 GMT+8, Hin-Tak Leung < > ht...@users.sourceforge.net> wrote: > > > > On Wednesday, 5 July 2023 at 03:24:11 GMT+8, Cosimo Lupo < > cos...@anthrotype.com> wrote: > > > > Hin-Tak, what do you mean by "Google OT-SVG fonts"? They're only one > OT-SVG format. > > > Yes and no. I don't have that many OT-SVG fonts - 3 from Adobe/Mozilla > sources, and the rest (more than 2 and less than 10) from Google Fonts. The > two sets behave differently, and get processed by two different code paths > in freetype2-demos. The Google set triggers the memory exhaustion bug I > fixed in freetype2-demos about a month ago; the Adobe/Mozilla set does not. > > > That was all part of the activities around the time with the Google font > SVG subsetting bug. Look at the freetype2-demo log around the same time you > investigated and fixed the subletting bug. > > Actually having looked at Skia and skia-python's SVG related functionality > last night, Skia also follows two slightly different code paths for the two > "types" of OT-SVG fonts. There will be a small "if x else ..." clause > separating the two in Skia related code, if /when I finish. > > > _______________________________________________ > mpeg-otspec mailing list > mpeg-ots...@lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec >
