Re: ftview segfault on ArefRuqaaInk-Regular.ttf (one of google web fonts)

[Ben Wagner]

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 <hintak_leung@yahoo.co.uk> 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 <htl10@users.sourceforge.net> 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 <htl10@users.sourceforge.net> 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 <htl10@users.sourceforge.net> wrote:

On Tuesday, 23 May 2023, 05:25:27 BST, Werner LEMBERG <wl@gnu.org> 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