For testing SVG, Skia has an OT-SVG testing font. [0] This font is more or less a reconstruction from the examples in the Open type specification. However, it also does interesting things with the em and view box to ensure those are handled correctly.
[0] https://skia.googlesource.com/skia/+/69f7860093b4ec7971d1e3bee458847aa849c351/resources/fonts/SampleSVG.ttf On Tue, May 23, 2023, 4:39 PM Hin-Tak Leung <[email protected]> wrote: > I don't know why glyf and svg differs from about gid 119 onwards, but I > intend to add the color toggle flag to ftgrid to find out.... surprised it > is not in ftgrid yet! > > On Wednesday, 24 May 2023 at 00:22:17 GMT+8, Hin-Tak Leung < > [email protected]> wrote: > > > To not break the other SVG color fonts I have, this refinement (the > viewbox part) seems to work better: > > + if ((out_has_viewbox != TRUE) && > + (((int)out_width.length == 1) && ((int)out_height.length == 1))) { > + x_svg_to_out /= units_per_EM; > + y_svg_to_out /= units_per_EM; > + } > + > > Beside this sets of arabic fonts, I only have two other svg color fonts - > EmojiOne Color bundled with photoshop, and a work-in-progress svg font > shared privately from Adobe folks at the beginning of my adding basic SVG > support to FontVal. So both of those could be considered made with > Adobe-related tech. Both of those have viewbox TRUE. > > come to think of it, this font's sampler on google fonts looks a bit odd - > I think the horizontal metrices might be a bit buggy. (or freetype not > quite happy with laying them out horizontally). regarding toggling between > svg and glyf at for gids 300-470 at 72 ppem > On Tuesday, 23 May 2023, 16:57:52 BST, Hin-Tak Leung < > [email protected]> wrote: > > > After hacking scale factor of 1000 out, the first few pages of glpyhs are > identical, but toggling glyphs in the higher up (gid 300-470) at 72em, they > don't quite line up - horizontally moved. It seems to have color glyphs to > about 470, after that 470 to 1138 are just b/w. > > On Tuesday, 23 May 2023 at 23:40:29 GMT+8, Hin-Tak Leung < > [email protected]> wrote: > > > On Tuesday, 23 May 2023, 05:25:27 BST, Werner LEMBERG <[email protected]> wrote: > > > Please give more details, using valgrind options `--leak-check=full` > > and `--show-leak-kinds=all` together with setting environment variable > > `FT2_DEBUG=any:7`. > > Actually FT2_DEBUG=any:7 was enough to see what the problem is. The svg > code path is trying to do bitmaps > 1000x1000 bigger than the glyf code path (compare the same glyph - I only > get only about 7 glyphs for 400 ppem). > > If I insert into src/rsvg-port.c , around line 255, something like the > below, I can toggle between b/w and more or less correctly: > > ======================= > /* Scale factors from SVG coordinates to the needed output size. */ > x_svg_to_out = (double)metrics.x_ppem / dimension_svg.width; > y_svg_to_out = (double)metrics.y_ppem / dimension_svg.height; > > + if (((int)out_width.length == 1) && ((int)out_height.length == 1)) { > + x_svg_to_out /= units_per_EM; > + y_svg_to_out /= units_per_EM; > + } > + > /* > * Create a cairo recording surface. This is done for two reasons. > * Firstly, it is required to get the bounding box of the final drawing > ======================== > > I think I remember seeing somewhere that a width and height =1 is special, > in the opentype spec? what width and height do you get in this location? > > Hin-Tak > >
