Glyphs 3: display problems in the font tab

I just opened the official Source Sans UFO in Glyhps 3 and removed the glyphOrder custom parameter.

• First, this had no effect on the glyph order shown in the font tab. It still says (and shows) the “Predefined Sorting”. Maybe that display needs to be updated after the user removes glyphOrder?

After saving the file as font.glyphs and re-opening, the font tab still looks funny (see screen shot below):

• The glyphs are generally displayed really large. I have to drag the size slider to the very left (see screen shot) and the glyph size is still not small enough for me.

• The glyph order is still funny. Is this a bug in Glyphs or are these glyphs really in different categories?

I fixed it.

1 Like

I just tried again with version 3062.

Deleted the glyphOrder from a freshly opened font, selected the Mac Roman filter, and it still shows the “Predefined Sorting”. Maybe it’s not quite fixed yet?

Ah, okay, seems like “Predefined Sorting” is part of the idea of looking at list filters? Good.

But I’m still confused, after opening the Andika OTF. The Mac Roman filter includes glyphs that

  • do not have any Unicode value,
  • and also Glyphs that have names which are not included in the list.

As a result, we have the a.SngStory (because it has the Unicode value of the a), as well as the glyph named a (although it does not have a Unicode value in this font), see screen shot. Something strange is going on there.

How are list filters supposed to work? Unicode-based or names-based?

In Glyphs 3 it is both, Name and Unicode based. That is more useful for CJK where the name are not very descriptive. And the filter somehow work with custom names, too.

Okay, makes sense.

But, as you can see from the screen shot, what the user currently sees does not make much sense.

Which ones?

The glyph named a (which does not have a Unicode value in Andika) and the corresponding accented ones.

Ah, I see. I thought there was a Unicode missing in the glyph data :sweat_smile: phew

So, to pick up o this.
@mekkablue @GeorgSeifert Do you really think the current behaviour (see above) makes sense?

The filters are mainly supposed to be name based. But character bases lookup is very handy in a lot situations, too. How often it will happen that name and unicode don’t match? What should it do? Stick to the names? Or force unicode match (what happens with unencoded glyphs)?