Invalid type flags in the Bungee fonts

[IvanUkhov]

Describe the bug
The fsType field in the OS/2 and Windows table is set to one in the following files:

• ofl/bungeecolor/BungeeColor-Regular.ttf and
• ofl/bungeespice/BungeeSpice-Regular.ttf.

This is not valid according to the specification:

Valid fonts must set at most one of bits 1, 2 or 3; bit 0 is permanently reserved and must be zero.

To Reproduce
Check bit 0 in OS/2. For instance, using fonttools:

from fontTools.ttLib import TTFont

font = TTFont("ofl/bungeespice/BungeeSpice-Regular.ttf")
font["OS/2"].fsType
# 1

Expected behavior
Bit 0 should not be set.

[anthrotype]

thanks. It looks like bit 0 of OS/2.fsType field was incorrectly set directly in the source files, see https://github.com/djrrb/Bungee/blob/fc391285f3a5eb0968f0171a61d09112bc83d0c8/sources/2-build/Bungee_Color/Bungee_Color-Regular.ufo/fontinfo.plist#L100-L103

    <key>openTypeOS2Type</key>
    <array>
      <integer>0</integer>
    </array>

I believe the intention was to define the font as "installable embdedding" which correspond to value 0 (not bit 0) with all the bits unset.

We could maybe file the same issue in the upstream repository so it gets fixed in the sources.

[chrissimpkins]

Assigned @vv-monsalve to address this at the source level

[vv-monsalve]

@anthrotype Inspecting Recursive as a reference and opening the .ufo file in Glyphs app, everything looks as expected in the source file.

[anthrotype]

The bug was about Bungee, not Recursive. As the OP said, the bit 0 is reserved and must be left unset. If the intention is to have "installable" embedding then all the bits must be left unset.
So the openTypeOS2Type array in the UFO fontinfo.plist must be left empty, without that 0. The array contains the indices of the bits that should be set.

[vv-monsalve]

Recursive as a reference

It is clear this issue is about Bungee fonts indeed.

What was not clear (since I'm not deeply familiarized .ufo sources), is how it should be set up in .ufo files. So I did two things when trying to validate how the 0 value must be set to have the "installable" configuration:

• Inspected another .ufo source to see how it was done (so I used Recursive as a reference). When doing so, I saw it is settled the same way (as in the above link)
• Opened the Bungee_Color-Regular.ufo file in Glyphs, and it is showing the "installable" option (that is the picture attached above).

After doing that, everything seemed to be as expected. This may not be conclusive, of course, but I was reporting it here to evaluate the situation.

I tried to use fonmatke with that Bungee_Color-Regular.ufo to confirm how the binary would end up, but it's reporting an error regarding an open contour, so it was not possible. The repository doesn't include build instructions, so no further build trials can be performed if there is a specific process for it.

So the openTypeOS2Type array in the UFO fontinfo.plist must be left empty, without that 0. The array contains the indices of the bits that should be set.

Now, what I understand from what you are saying here, is that it should be set up in one of the below options (could you confirm which one it should be?)

a.

    <key>openTypeOS2Type</key>
    <array>
    </array>

b

    <key>openTypeOS2Type</key>
    <array>
      <integer></integer>
    </array>

[anthrotype]

a

[davelab6]

Great work investigating this @vv-monsalve!

@justvanrossum do you have any suggestions how the sources got this way? :)

[vv-monsalve]

PR with a fix was made to Bungee's repo.

[vv-monsalve]

This issue was reported as already being addressed as part of a big update for the fonts.

[vv-monsalve]

Just addressed this in the sources at this commit of the Upstream repo

[chrissimpkins]

I spoke with @justvanrossum and there are plans to cut a new release in the next several weeks. These changes will be included in the next release.

[vv-monsalve]

@justvanrossum, do you have an estimated date for the next release?

[justvanrossum]

I just finished the last work and I will run a preview release later. Will post an update here.

[justvanrossum]

Here is a preview:

• https://github.com/djrrb/Bungee/releases/tag/v2.000-preview1

The fonts for GF are in Bungee_Basic and Bungee_Color.

We ran fontbakery on individual fonts, as it isn’t really a RIBBI family. Here is how we invoke it:

• https://github.com/djrrb/Bungee/blob/master/run_fontbakery.sh

[vv-monsalve]

Excellent! Thank you.

The fonts for GF are in Bungee_Basic and Bungee_Color.

I'll start assessing them in preparation for the update.

We ran fontbakery on individual fonts, as it isn’t really a RIBBI family. Here is how we invoke it:

I gues you are saying and using this to avoid some Fails reported for the fonts, so to better understand this I'll run the standard FB tests for GF and let you know from there. We'll need to be aware of which Fails are them.

[vv-monsalve]

I've confirmed the elided checks are valid and opened a new Issue with diffenator proofs for you to review/confirm on a few spotted issues.
I'll add more images for all the fonts that will be updated.

[davelab6]

@justvanrossum please could you give us a status update on this, as we are planning @vv-monsalve 's time for Q1 and would like to know if you think you'll be ready to hand off to her in this period :)

[justvanrossum]

Apologies, this somehow fell under my radar. Working on it now, should be completed soon.

[chrissimpkins]

Any updates here Just?

[justvanrossum]

This has been long resolved. I received a follow-up issue:

• Diffenator proofs djrrb/Bungee#108

To which I proposed a fix:

• Setup mark + mkmk GPOS features djrrb/Bungee#109

For which I haven't gotten any feedback.

[vv-monsalve]

Apologies. Bungee is on my project list, but I have yet to have the opportunity to return to it.

I'll update you as soon as I resume work on it. Confirming: Would you prefer I merge that PR as part of that process? If not, please feel free to merge it, and I'll work from the latest files on the master branch.

[justvanrossum]

Would you prefer I merge that PR as part of that process? If not, please feel free to merge it, and I'll work from the latest files on the master branch.

I would prefer if you could checkout the PR branch and confirm whether it fixes djrrb/Bungee#108 in a satisfactory way.

But if it's easier for you if I merge now, and we amend later with a new PR if new issues are found, we can do that, too.