I don’t know if I’m doing something wrong here, or if this is expected behaviour, but it seems unexpected to me.
I’ve added some glyphs for enclosed numerals (open and closed circles), intended to be used in stylistic sets, but also usable as regular glyphs by their Unicode values. I added them as Unicode ranges, so they are currently ‘nice-named’ by their Unicode values, which is repeated in the Unicode and production names.
In order to use them in stylistic sets, I would of course like to rename them as zero.opencirc / zero.closedcirc, etc., but when I do this, the Unicode values and production names are deleted, and I then have to manually type in each Unicode value (or script it, which seems overkill for twenty glyphs).
Is there a way to avoid this?
Edit: Just realised that “Use custom names” was turned on in the font. Disabling this and doing “Update glyph info” on the selected glyphs gives me what I’m after (except that I’d prefer .opencirc and .closedcirc over .circled and .blackCircled) – but even so, it would be nice if changing the ‘nice name’ didn’t overwrite existing Unicode values even with custom names enabled.
The whole point of nice names is to govern the glyph’s attributes. You can write your own GlyphData.xml if you want to customize the name-glyph relationship. There’s a tutorial about it.
Just for readability. Currently, they’re set up like so:
sub zero by zero.circled;
sub one by one.circled;
sub two by two.circled;
sub three by three.circled;
sub four by four.circled;
sub five by five.circled;
sub six by six.circled;
sub seven by seven.circled;
sub eight by eight.circled;
sub nine by nine.circled;
(And similar for .blackCircled.)
Before disabling “Use custom names”, the substitutions were along the lines of sub zero by uni24EA, which tells you absolutely nothing useful about what’s being substituted.
Exactly what I said in the previous comment. This:
sub zero by zero.circled
– looks a lot nicer and more readable than this:
sub zero by uni24EA
In addition to being used in stylistic sets, circled numbers also have their own, separate Unicode values in the Enclosed Alphanumerics block, and they should be typable using those Unicode values. But when ‘Use custom names’ is enabled in the font, adding nice names in Glyphs completely removes the Unicode and production values from those glyphs, meaning that they cannot be typed by their Unicode values.
As mentioned in the edit to the question, turning off ‘Use custom names’ solves the issue (apart from forcing you to use specific nice name conventions, which is minor to me).
I added them as Unicode ranges, so they are currently nice-named by their Unicode values, which is repeated in the Unicode and production names.
So they were originally named with Unicode values.
When I changed the nice name from uni24EA to zero.opencirc (note: opencirc rather than circled, since at that point I didn’t yet know that Glyphs used circled), the Unicode value and production name were both immediately deleted from the glyph, leaving me with a glyph that had what to me was the correct nice name (zero.circled), but no Unicode or production values.
So the issue is this – if:
you have ‘Use custom names’ enabled
you have a glyph that already has correct Unicode and production values
you manually change the nice name of that glyph to whatever you would like it to be (even if that uses different conventions from what Glyphs uses, like using .opencirc and .closedcirc instead of .circled and .blackCircled)
– then Glyphs should not, in my opinion, delete the Unicode and production values already present for that glyph.
I may be thoroughly misunderstanding the purpose of the ‘Use custom names’ feature, but I thought this was the whole point of it: to let you use your own naming scheme without Glyph trying to be smart and match things up. But not automatically matching nice names with Unicode and production values doesn’t mean deleting the latter; it just means leaving them alone.
Yes, since the naming convention used by Glyphs is fine with me, I could just turn off ‘Use custom names’, which fixes it. If for some reason I had to keep ‘User custom names’ on and use my own custom naming scheme, the issue would presumably still be present.
I don’t think I’m trying to live in both worlds. The fact that Glyphs doesn’t use the name to infer properties from names to me means that Glyphs should leave those properties alone and let me handle them. To my mind, deleting the properties is more akin to inferring from names than it is to not inferring from names – it’s taking action based on the nice name.
If the definition of ‘Use custom names’ is “When enabled, Glyphs will not use glyph names to infer other glyph properties”, then – to me at least – the only logical and consistent implementation is that with this setting enabled, changing a glyph name has no effect on any other glyph properties. They should simply remain as they are.
Consider the similar case of automatic language detection features in word-processing software. If you set a paragraph style to English, turn on automatic language detection and then type a paragraph in French, the language of that paragraph will be set to French as a local override while you type. If you didn’t turn on automatic language detection, you would expect the paragraph to be set to English throughout. The current implementation of ‘Use custom names’ in Glyphs is akin to the word processor setting the paragraph’s language to None when you type, which I doubt anyone would consider expected behaviour.
(Did you switch ‘enabled’ and ‘disabled’? As far as I’m aware, Glyphs infers Unicode and production values when ‘Use custom names’ is disabled, not enabled.)
Sorry, I did indeed switch the terms. In the case of uni24EA, Glyphs can still infer the intended Unicode from the name and thus you get the code point from the name even when using custom names. But that property was only set because of the name, so once you change the name to a glyph name where no code point is known, the code point property is no longer inferred.
And that’s fine – since I’m changing the glyph name to something custom, I don’t want it to be inferred. That’s why I enabled ‘Use custom names’ in the first place (in this hypothetical scenario where the naming actually matters to me and I’m actively and deliberately enabling it).
But since my glyphs already have correct properties (whether those were inferred at creation or entered manually by me), I also don’t want Glyph to actively destroy existing data. ‘Not inferring’ is not the same as ‘destroy anything that may be there’.
If I set a custom name and then manually set the Unicode point, it works – until I change the custom name, at which point it once again deletes the Unicode point I’d previously set. I don’t think that’s reasonable behaviour for a setting that essentially boils down to ‘let me do it all myself’.
That’s what you do with glyph info (Cmd-Opt-I) or better yet, with your own GlyphData.xml.
These properties are otherwise entirely dependent on the glyph name, which does make a lot of sense, even though I understand that in this very case you would have preferred it differently. But it did help you a lot (unconsciously) with all the other glyphs you have in your font.
So the crux of the matter here really is that I had misunderstood what ‘Use custom names’ does. It doesn’t actually prevent Glyphs from inferring properties from glyph names so much as it prevents it from trying to generate glyph names from properties (Unicode points).
Now that I read it again, I see how section 7.6.2 in the handbook means (or at least can mean) that. I’d misread it as relating to inferring properties from names, not the other way around.