Multiface fonts supported in load but not range

[springmeyer]

Fonts with multiple faces are supported by looping over each face and accessing the number of faces once a valid FT_Face object is available. Like we do here:

• looping:

  node-fontnik/src/glyphs.cpp

  Line 197 in 35feb88

  for ( int i = 0; ft_face == 0 || i < num_faces; ++i )

• accessing ft_face->num_faces:

  node-fontnik/src/glyphs.cpp

  Lines 205 to 206 in 35feb88

  	if (num_faces == 0)
  	num_faces = ft_face->num_faces;

But the num_faces = ft_face->num_faces; is only done in LoadAsync and not RangeAsync

/cc @mikemorris

[springmeyer]

Testing with a multiface font (ttc): current node-fontnik master goes into an infinite loop in RenderSDF in RangeAsync.

[mikemorris]

We've never properly supported multiface fonts, IIRC because we couldn't find a suitable test fixture when originally writing this. There's a catch in the fontmachine downstream implementation to prevent calling RangeAsync so I don't think we would ever hit this case in production.

That said, yes, this is likely a copy/paste error for an edge case we haven't properly tested/supported. I'm not clear on why it would infinite loop inside RenderSDF though, is there anything else different about this test fixture aside from multiple faces? Can you tell where inside RenderSDF its looping?

[springmeyer]

There's a catch in the fontmachine downstream implementation to prevent calling RangeAsync so I don't think we would ever hit this case in production.

Great. If downstream users have been throwing on multiface fonts then we've been isolated from the bug (of not reading them all) in RangeAsync.

Testing with a multiface font (ttc): current node-fontnik master goes into an infinite loop in RenderSDF in RangeAsync.

False alarm. Further profiling shows that it is actually not an infinite loop, but rather just extremely slow execution. I was running in debug mode. Processing this ttc takes over 3 minutes with bin/build-glyphs, which is crazy. This font seems to have more data, but such slow processing is still worrysome.

I good, freely available, ttc testcase is https://github.com/googlei18n/noto-fonts/blob/master/hinted/NotoSans-Regular.ttc which just takes 5s to process (still in Debug mode).