FontFamily.cpp(184)] Could not get cmap table size!

[jamieastley]

I've had other team members reporting weird Flutter crashes on iOS simulator that I've been unable to reproduce, until now.

It looks like the culprit is the *.otf file I'm generating with Fontify, the exact page the app is crashing on consistently is using icons from the generated font file, and when commenting the IconData out and replacing with default Flutter icons, no more crashing.

[VERBOSE-2:FontFamily.cpp(184)] Could not get cmap table size!
[VERBOSE-3:FontCollection.cpp(95)] nTypefaces == 0

It can be reproduced reliably when running the app on iOS 11.4 simulator.

Related Flutter issues that have the same error have suggested spacing within the font family name and/or filename as the culprit, but I don't have either present in my font file or pubspec.yaml.

My fontify.yaml (if it helps)

fontify:
  input_svg_dir: "assets/svg/"
  output_font_file: "assets/fonts/my_icons.otf"

  output_class_file: "lib/src/my_icons.dart"
  class_name: "MyIcons"
  indent: 4
  package: "my_icons"

  font_name: "MyIcons"
  normalize: true
  ignore_shapes: false

  recursive: true
  verbose: false

Any ideas?

[westracer]

Hello, @jamie1192. This problem might be caused by many different things like a wrong filename or incorrect table encoding, so it's hard to tell for sure.

Could you, please, provide the Flutter SDK version and "fonts" key (with the custom font) from pubspec as well? Also, does the bug reproduce just with iOS, or with Android emulator too?

I'll look into it ASAP.

[jamieastley]

hey @westracer, i'm on Flutter 1.22.2.

Here's an example project with the generated .otf and source svg's to reproduce with- https://github.com/jamie1192/Font_cmap_example.

I can't fault it on Android, seems to only occur on iOS 11.x and 12.x, iOS 13 and above seems to be fine.

Thanks!

[westracer]

The bad news is, unfortunately, I don't have a macOS device, so I can't even reproduce this problem. I don't get this kind of crashes with the Android emulator.

But I also see a problem in the default "Windows Font Viewer" program as it can't open the font and says it's corrupted. FontLab can't read it too. Both of these programs are closed source, so I can't use them to debug.

On the other hand, I have tried using a few different open-sourced parsers and validators (written in JS and Python), and none of them reported anything unusual, they work with the font just fine. "fontbakery" reported some minor problems, but as I fixed them, nothing really changed. "fonttools ttx" dumps the info about the font without any problem as well.

I'm a bit stuck there, but, anyway, I'll do my best to identify the issue.

[jamieastley]

hmm that makes it tricky then. Is there anything I can do on my end on a MacOS device that can help at all?

[westracer]

@jamie1192 Thank you for offering help but I don't think it will help me.

I couldn't locate the issue. I tried many different things without any success so far.

I think I'll have to rewrite a font generator a bit, so it will generate the previous font format table (CFF instead of CFF2). I'll do it in the next couple of days.

[westracer]

So, before making significant changes, I tried even more stuff to identify the problem but still without any success. As I said, I rewrote the generator a bit, so it uses a different older format now. It shouldn't affect the newly generated glyphs in any way (i.e. glyphs' size and placement should stay the same).

I tested it pretty extensively and compared the newly generated fonts to the previously generated fonts, and they look the same, but new ones work in every program.

If it's possible for you to test it, it would be great. You can specify it in pubspec like this;

  fontify:
    git:
      url: https://github.com/westracer/fontify.git
      ref: CFF1

I'll wait for some feedback, including yours, and gonna release it the new version then.

[jamieastley]

The older format did the trick! Not sure if there's something here that can give any insight as to what could possibly be causing the issues with CFF2?.

Given that this issue seems to only affect iOS < 13.x, maybe it would be good to have this as a config option as to whether to use the CFF1 or CFF2 generator if there's any limitations on using the older format?

Thankyou so much for looking into and fixing this, greatly appreciated!

[westracer]

What you linked is actually Apple's docs for TrueType, so it's not really relevant when talking about OpenType fonts. I have re-read OpenType/CFF2 docs thrice trying to find if I missed something about the format, but with no success so far.

There's no need to choose between CFF1 and CFF2 because they are pretty similar. CFF2 is just a successor, but CFF1 is still more widely supported and it's not deprecated (and it won't be in the next few years). Considering that my CFF2 generator doesn't even work properly (some programs can't read it), it shouldn't be used in the first place, until I make it work in every font reading program.

CFF1 doesn't have any limitations compared to CFF2 (well, there are some in the interpreter internal implementations, but you won't see them, at least). CFF2 format's main feature is "variable fonts", but it is not used in the generator anyway.

Thank you for the feedback, I'm going to release the update shortly

[westracer]

Released in 0.2.0