.osf characters are in conflict with uniF804 to uniF7FB

.osf characters are in conflict with uniF804 to uniF7FB “”.

When uniF804-uniF7FB exists in a font, typing zero.osf to nine.osf is impossible as nothing appears. Using cmd f to add the glyph to the edit window causes .notdef glyphs to appear instead.

Deleting uniF804-uniF7FB from the Glyphs file makes zero.osf to nine.osf to start working again.

If these glyphs were created by a filter, the filter will reports that all glyphs are present even after they have been deleted. If you open the create glyphs menu in the filter, an option to generate the glyphs will still appear.

Clicking generate missing glyphs on all of them, causes the following error message to appear.

Some glyphs were already present in the font.

uniF7FB (nine.osf: same unicode), uniF7FC (eight.osf: same unicode), uniF7FD (seven.osf: same unicode), uniF7FE (six.osf: same unicode), uniF7FF (five.osf: same unicode), uniF800 (four.osf: same unicode), uniF801 (three.osf: same unicode), uniF802 (two.osf: same unicode), uniF803 (one.osf: same unicode), uniF804 (zero.osf: same unicode)

The .osf glyphs has no unicode values if you check them manually with cmd alt I.

I added uniF804-uniF7FB, zero-nine and zero.osf-nine.osf to a font, opened a tab, pressed Cmd-F, typed “.osf”, tab, Cmd-A, Return. And all oldstyle figures appeared as expected.

Do I need to do anything else in order to reproduce it?

No, that should be it.












The issue might be caused by something else though, as trying to replicate the bug now works though somewhat differently.

Generating these glyphs caused it.
img7

The pua values above now conflict with an entirely different set of glyphs. All the ones it reports this time are once more components used by other glyphs without codepoints of their own.

So to reproduce this, I add the figures, the mark ligatures, and then the PUA glyphs?

Yes, but actually no. The bug seems to semi randomly associate the pua glyphs with other glyphs in the font file. I am therefore not sure if there is a sure fire way to replicate it from your side anymore.

You could possibly try it on a font with a large glyph size. Trying to generate all of the basic pua plane could possibly make it replicable.

The issue seems to only happen with those few codepoints though for some reason.

I did some more testing by generating some more glyphs (ztest1 and ztest2) to see if the conflicts changed. It did not. I then saved and restarted once more to see if the added glyphs would impact things after another reboot. It did.

The issue appeared to work fine for now, though I believed that rather than the bug being fixed, what glyphs and codepoints it confused had changed.

To test if this hypothesis was true, I tried generating the last 2000 codepoints of the pua block and received this error message.

img35

I think generating most if not all of the first pua block should help you replicate the issue.

Glyphs uses PUA values to display unencoded glyphs in the edit view. Your fonts uses quite a lot of them and that seems to produce collisions.

But why do you use them? That shouldn’t been done since 20 years ago.

Use what, pua codepoints?

I see so that’s the cause of that bug, makes sense.

Yes.