Overline (203E) should not be categorized as a mark

It looks like Glyphs 3 is categorizing the “overline” character (0x203E) as a non-spacing mark like “overlinecomb” when it is supposed to be spacing punctuation, per Unicode Character 'OVERLINE' (U+203E) and https://www.unicode.org/charts/PDF/U2000.pdf

It should be designated as punctuation by default. Where do you observe it to be treated as a non-spacing mark?

I have a .glyphsproject that included a “overlinecomb” glyph that was double-encoded with “203E”. Obviously this is not ideal as the combining mark will be set to non-spacing.

So I duplicated the glyph, and named it “overline” so that it would be separate. However, it appears that Glyphs didn’t update the metadata on it (only the unicode) so that it would be spacing as it should.

Here’s the individual glyph files to look at:

Overlinecomb

Overline

When I duplicate a double-encoded glyph overlinecomb with GlyphDuplicate (⌘D) and rename it to overline, the glyph gets assigned the code point U+203E and the category is set to Punctuation.

What method did you use to duplicate and rename the glyph?

Copy/paste (add copy), then rename. Very strange that it didn’t pick up the category change.

Copy-paste works for me, too. I’ll have a look at your specific font later, maybe I can find some details there that has caused this for you.

Thanks. BTW, I tried your method as well and got the same result.
I’m on 3337 currently. Not sure if that has any bearing on this.

By same result you mean the one you got before and not mine?

Hmm. You know, I think it might have to do with that Glyphs thinks the glyph has “manually set glyph info”, so it is not changing the data even when the glyph is renamed.

Do you know how to disable that?

Yeah, mine with the incorrect category

Thanks, just in case I misunderstood. I have now downloaded your source file and can reproduce the category not updating. You are right that is related to the manually set metadata. When such a value is set manually, it overrules the default value that Glyphs would otherwise associate with the given glyph name. You can undo this by selecting the overline glyph and editing its properties with EditInfo for Selection… (⌘⌥I). There, uncheck Category and Subcategory for the properties to assume their default value. Confirm with OK and the glyph metadata of those properties will be updated.

Thanks! I don’t think I’ve ever used that menu option before.
Wonder how / why the overline data was set manually in this case.

BTW, it appears that if any category / subcategory data is contained within the .glyph file, Glyphs will assume that data is set manually, even if it matches the info that Glyphs would set automatically.

Would it make sense to check for that and not assume these values should be maintained?

The way this works is that default values are not written to a file and any values that are written are understood as being manually set. That way, file sizes are smaller and no separate categoryIsManual/subCategoryIsManual/… infos need to be stored, further reducing file sizes.

While the category data of glyphs is not a significant contributor to the overall file size, the principle of not storing default values is applied to most values in the Glyphs file format. In total, that reduces the file size dramatically. And reduced file sizes are not just neat for disk space, but also a significant help to speed up reading and writing files.

I think you misunderstood Aaron’s point, Florian. What he was saying was, whenever Glyphs checks a glyph to see if there is manual data set, it could simultaneously also check whether any such data is actually different from what the default value would be.

If it is not (i.e., if there’s manually set data that’s identical to the default values), then the file can be optimised by removing the manually set data, which Glyphs could easily do automatically.

Glyph data that has been explicitly marked as manually set should not automatically be reverted to follow the default value in case the values are the same. That is because the default values can change when a user is using a custom GlyphData file to provide a custom naming scheme and property values. Setting values manually ensures that they are unaffected by the presence of such custom GlyphData files.

Both manually set values and custom GlyphData are more advanced features that most users don’t need or use, but the users that opt for this level of customization don’t want automatic processes to interfere with these values.

How old is the file? Perhaps we had it wrong in an old version of the GlyphData and corrected it at one point. Or it was overridden in the file at one point?

This particular file is not that old, but the Glyphs source it is based on is from 5 years ago.

1 Like