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
different words: the difference reflects how they were made. Adobe/Mozilla
OT-SVG fonts were created natively on SVG-capable editors like Adobe
Illustrators, etc then assembled as such, so have all the conventional SVG
attributes expected of them from standalone SVG rendering libraries.
Google-origin OT-SVG fonts are programmatically converted from font outlines in
a different format, so have a more minimalistic nature, and also relies on some
other information kept in the rest of the font structures, to be "complete"
equivalent to standalone SVG graphics.
As I also mentioned, Skia / skia-python's SVG parser returns 0,0 for
width/height for SVG from Google-origin OT-SVG fonts. So it needs a "0,0 means
EM,EM "hint"" to be rendered as standalone SVG too. Ie. Skia also distinguishes
the two "types" of OT-SVG fonts as far as treating the SVG glyphs as SVG
graphics goes.
On Thursday, 6 July 2023 at 09:02:40 GMT+8, Rod Sheeter
<[email protected]> wrote:
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 <[email protected]>
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
<[email protected]> 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
<[email protected]> 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
<[email protected]> 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 <[email protected]>
wrote:
On Wednesday, 5 July 2023 at 20:49:42 GMT+8, Hin-Tak Leung
<[email protected]> wrote:
> On Wednesday, 5 July 2023 at 03:24:11 GMT+8, Cosimo Lupo
<[email protected]> 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
[email protected]
https://lists.aau.at/mailman/listinfo/mpeg-otspec
